On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>Now, suppose that participant A wants B to be assured that
>A will not double-spend the transaction.
>Then A solicits a single-spend signature from the actuary,
>getting a signature M:
>
>    current state                  +--------+----------------+
>    ---------+-------------+       |        | (M||CSV) && A2 |
>             |(M||CSV) && A| ----> |  M,A   +----------------+
>             +-------------+       |        | (M||CSV) && B2 |
>             |(M||CSV) && B|       +--------+----------------+
>             +-------------+
>             |(M||CSV) && C|
>    ---------+-------------+
>
>The above is now a confirmed transaction.

Good morning, ZmnSCPxj.

What happens if A and M are both members of a group of thieves that control a 
moderate amount of hash rate?  Can A provide the "confirmed transaction" 
containing M's sign-only-once signature to B and then, sometime[1] before the 
CSV expiry, generate a block that contains A's and M's signature over a 
different transaction that does not pay B?  Either the same transaction or a 
different transaction in the block also spends M's fidelity bond to a new 
address exclusively controlled by M, preventing it from being spent by another 
party unless they reorg the block chain.

If the CSV is a significant amount of time in the future, as we would probably 
want it to be for efficiency, then the thieving group A and M are part of would 
not need to control a large amount of hash rate to have a high probability of 
being successful (and, if they were unsuccessful at the attempted theft, they 
might not even lose anything and their theft attempt would be invisible to 
anyone outside of their group).

If A is able to double spend back to herself funds that were previously 
intended to B, and if cut through transactions were created where B allocated 
those same funds to C, I think that the double spend invalidates the 
cut-through even if APO is used, so I think the entire mechanism collapses into 
reputational trust in M similar to the historic GreenAddress.it co-signing 
mechanim.

Thanks,

-Dave

[1] Including in the past, via a Finney attack or an extended Finney attack 
supported by selfish mining.  
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to