Date: Mon, 18 Sep 2023 03:37:46 +0000
To: "David A. Harding" <dave@dtrt.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
In-Reply-To: <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
 <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: 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
Precedence: list


Good morning Dave,



Sent with Proton Mail secure email.

------- Original Message -------
On Monday, September 18th, 2023 at 12:12 AM, David A. Harding <dave@dtrt.or=
g> wrote:


>=20
> On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev bitcoin-dev=
@lists.linuxfoundation.org wrote:
>=20
> > 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:
> >=20
> > current state +--------+----------------+
> > ---------+-------------+ | | (M||CSV) && A2 |
> > |(M||CSV) && A| ----> | M,A +----------------+
> > +-------------+ | | (M||CSV) && B2 |
> > |(M||CSV) && B| +--------+----------------+
> > +-------------+
> > |(M||CSV) && C|
> > ---------+-------------+
> >=20
> > The above is now a confirmed transaction.
>=20
>=20
> Good morning, ZmnSCPxj.
>=20
> What happens if A and M are both members of a group of thieves that contr=
ol 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 ne=
w address exclusively controlled by M, preventing it from being spent by an=
other 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 be=
fore 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-onl=
ine 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 part=
y of the blockchain) can only select transactions, and cannot authorize mov=
es without consent of the owners.
That is what we would want to replicate somehow, to reduce interactivity re=
quirements.

Regards,
ZmnSCPxj