From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: 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, 15 Oct 2023 13:36:00 +0000 [thread overview]
Message-ID: <6I7jG9PNNaWUZ8OnqAAQg0TJQ9PwGvD05iXYSOuN0XiezIJCChGlsxKZ30RwYfpeKlJyj7gB_rq1kPSR8UX6tOm-X7zanL_MXVrGEon3txc=@protonmail.com> (raw)
In-Reply-To: <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
Good morning list,
I have been thinking further on this with regards to BitVM.
By my initial analyses, it seems that BitVM *cannot* be used to improve this idea.
What we want is to be able to restrict the actuary to only signing for a particular spend exactly once.
The mechanism proposed in the original post is to force `R` reuse by fixing `R`.
This requires a change in Bitcoin consensus on top of `SIGHASH_ANYPREVOUT` (which is desirable not only for its enablement of Decker-Russell-Osuntokun, which is multiparticipant, but also makes it more convenient as we can make changes in the offchain mechanism state asynchronously with the participants and actuary signing off on new transactions; we can "lock" the next state to some set of transactions occurring, then have the actuary "confirm" new transactions by signing them, then have the signature still be valid on the new state due to `SIGHASH_ANYPREVOUT` ignoring the actual input transaction ID).
The best I have been able to come up with is to have a program that checks if two signatures sign different things but have the same public key.
If this program validates, then the actuary is known to have cheated and we can arrange for the actuary to lose funds if this program validates.
However, BitVM triggers on DIShonest execution of the program, so that program cannot be used as-is.
Honest execution of the program leads to the BitVM contract resolving via timeout.
I have tried to figure out some way to change the "polarity" of the logic so that the actuary is punished, but it requires that the actuary act as validator instead of prover (and the aggrieved participant who was expecting the actuary to not violate the sign-only-once is the prover, which makes little sense, as the participant can challenge the actuary and force it to put up funds, then neglect to actually prove anything and enter the default timeout case where the prover gets the funds --- it has to be the actuary in the prover position, only getting back its funds after a timeout).
The opposite of showing that there exists two signatures with different messages but the same public key is to show that there does not exist any other signatures with a different message but same public key.
If such a program were written, then it would be trivial to make that program pass by simply denying it an input of any other signature, and an actuary in prover position can always commit to an input that lacks the second signature it made.
The actuary can run a program *outside* of BitVM, so it is also pointless to have the signing algorithm be written in BitVM.
Finally, in the actuarial system, the actuary is supposed to provide *something* that would make a transaction be immediately confirmable, instead of after a timeout.
But in BitVM, the *something* that the prover provides that makes some transaction immediately confirmable is to provide a dishonest execution of a BitVM program; it is the timeout that is the honest execution of the BitVM program.
In addition, the actuary should be restricted so that it can only show this for *one* transaction, and not for any other transactions.
There are more possible dishonest executions of a BitVM program than just one, but only one honest execution, which is the opposite of what we want.
So, so far, I have not been able to figure out how to use BitVM to replace the current forced `R` reuse mechanism for preventing multiple times the actuary commits.
Regards,
ZmnSCPxj
prev parent reply other threads:[~2023-10-15 13:36 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
2023-09-18 3:37 ` ZmnSCPxj
2023-10-15 13:36 ` ZmnSCPxj [this message]
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='6I7jG9PNNaWUZ8OnqAAQg0TJQ9PwGvD05iXYSOuN0XiezIJCChGlsxKZ30RwYfpeKlJyj7gB_rq1kPSR8UX6tOm-X7zanL_MXVrGEon3txc=@protonmail.com' \
--to=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