Good morning Dave,
Sent with Proton Mail secure email. ------- Original Message ------- On Monday, September 18th, 2023 at 12:12 AM, David A. Harding <d...@dtrt.org> wrote: > > 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. Indeed, the fidelity bond of M would need to be separately locked to `(M && B) || (M && CSV(1 year))`, and the actuary would need to lock new funds before the end of the time period or else the participants would be justified in closing the mechanism with the latest state. And of course the bond would have to be replicated for each participant `A`, `B`, `C`.... as well, reducing scalability. If possible, I would like to point attention at developing alternatives to the "sign-only-once" mechanism. Basically: the point is that we want a mechanism that allows the always-online party (the "actuary") to *only* select transactions, and not move coins otherwise. This is the nearest I have managed to get, without dropping down to a proof-of-work blockchain. As noted, in a proof-of-work blockchain, the miners (the always-online party of the blockchain) can only select transactions, and cannot authorize moves without consent of the owners. That is what we would want to replicate somehow, to reduce interactivity requirements. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
