Date: Tue, 12 Sep 2023 09:41:18 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.com>
In-Reply-To: <CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
 <CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
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 Antoine,


> Hi Zeeman
>=20
> > What we can do is to add the actuary to the contract that
> > controls the funds, but with the condition that the
> > actuary signature has a specific `R`.
>=20
> > As we know, `R` reuse --- creating a new signature for a
> > different message but the same `R` --- will leak the
> > private key.
>=20
> > The actuary can be forced to put up an onchain bond.
> > The bond can be spent using the private key of the actuary.
> > If the actuary signs a transaction once, with a fixed `R`,
> > then its private key is still safe.
>=20
> > However, if the actuary signs one transaction that spends
> > some transaction output, and then signs a different
> > transaction that spends the same transaction output, both
> > signatures need to use the same fixed `R`.
> > Because of the `R` reuse, this lets anyone who expected
> > one transaction to be confirmed, but finds that the other
> > one was confirmed, to derive the secret key of the
> > actuary from the two signatures, and then slash the bond
> > of the actuary.
>=20
> From my understanding, if an off-chain state N1 with a negotiated group o=
f 40 is halted in the middle of the actuary's R reveals due to the 40th par=
ticipant non-interactivity, there is no guarantee than a new off-chain stat=
e N1' with a new negotiated group of 39 (from which evicted 40th's output i=
s absent) do not re-use R reveals on N1. So for the actuary bond security, =
I think the R reveal should only happen once all the group participants hav=
e revealed their own signature. It sounds like some loose interactivity is =
still assumed, i.e all the non-actuary participants must be online at the s=
ame time, and lack of contribution is to blame as you have a "flat" off-cha=
in construction (i.e no layering of the promised off-chain outputs in subgr=
oups to lower novation interactivity).

Yes, there is some loose interactivity assumed.

However:

* The actuary is always online and can gather signatures for the next state=
 in parallel with signing new transactions on top of the next state.
  * This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top =
of the next state might spend either the actual next state (if the next sta=
te is successfully signed), or the current state plus additional transactio=
ns (i.e. the transaction that move from current state to next state) (if th=
e next state fails to get fully signed and the participants decide to give =
up on the next state getting signed).

> More fundamentally, I think this actuarial system does not solve the "mul=
ti-party off-chain state correction" problem as there is no guarantee that =
the actuary does not slash the bond itself. And if the bond is guarded by u=
sers' pubkeys, there is no guarantee that the user will cooperate after the=
 actuary equivocation is committed to sign a "fair" slashing transaction.

Indeed.

One can consider that the participants other than the actuary would generat=
e a single public key known by the participants.
But then only one sockpuppet of the actuary is needed to add to the partici=
pant set.

Basically, the big issue is that the actuary needs to bond a significant am=
ount of funds to each participant, and that bond is not part of the funding=
 of the construction.

Other ways of ensuring single-use can be replaced, if that is possible.
Do you know of any?

Regards,
ZmnSCPxj