From: "David A. Harding" <dave@dtrt•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms
Date: Sun, 17 Sep 2023 14:12:45 -1000 [thread overview]
Message-ID: <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org> (raw)
In-Reply-To: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
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.
next prev parent reply other threads:[~2023-09-18 0:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 1:27 ZmnSCPxj
2023-09-11 6:02 ` Antoine Riard
2023-09-12 9:41 ` ZmnSCPxj
2023-10-05 2:12 ` Antoine Riard
2023-10-31 22:12 ` AdamISZ
2023-09-18 0:12 ` David A. Harding [this message]
2023-09-18 3:37 ` ZmnSCPxj
2023-10-15 13:36 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox