Date: Sun, 15 Oct 2023 13:36:00 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6I7jG9PNNaWUZ8OnqAAQg0TJQ9PwGvD05iXYSOuN0XiezIJCChGlsxKZ30RwYfpeKlJyj7gB_rq1kPSR8UX6tOm-X7zanL_MXVrGEon3txc=@protonmail.com>
In-Reply-To: <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
 <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
 <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In
	N-of-N (N	> 2) Multiparticipant Offchain Mechanisms
Precedence: list

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 thi=
s idea.

What we want is to be able to restrict the actuary to only signing for a pa=
rticular 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 ma=
ke changes in the offchain mechanism state asynchronously with the particip=
ants and actuary signing off on new transactions; we can "lock" the next st=
ate 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 transa=
ction 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 prog=
ram cannot be used as-is.
Honest execution of the program leads to the BitVM contract resolving via t=
imeout.
I have tried to figure out some way to change the "polarity" of the logic s=
o that the actuary is punished, but it requires that the actuary act as val=
idator instead of prover (and the aggrieved participant who was expecting t=
he actuary to not violate the sign-only-once is the prover, which makes lit=
tle 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 ti=
meout 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 mes=
sages but the same public key is to show that there does not exist any othe=
r signatures with a different message but same public key.
If such a program were written, then it would be trivial to make that progr=
am pass by simply denying it an input of any other signature, and an actuar=
y in prover position can always commit to an input that lacks the second si=
gnature it made.

The actuary can run a program *outside* of BitVM, so it is also pointless t=
o have the signing algorithm be written in BitVM.

Finally, in the actuarial system, the actuary is supposed to provide *somet=
hing* 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 tran=
saction immediately confirmable is to provide a dishonest execution of a Bi=
tVM program; it is the timeout that is the honest execution of the BitVM pr=
ogram.
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 o=
ne, 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 ac=
tuary commits.


Regards,
ZmnSCPxj