path: root/ec/60bb84480a6d22d15c645c5b5e74711a98ad5e

Return-Path: <AdamISZ@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7B24FC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 22:12:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4BCB24031E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 22:12:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4BCB24031E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=OGcthQW1
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.601
X-Spam-Level: *
X-Spam-Status: No, score=1.601 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wSSYvxSenw0b
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 22:12:33 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
 [51.77.79.158])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6BE02402B1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 22:12:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6BE02402B1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1698790343; x=1699049543;
 bh=iu12kYxCq4ROFXMLAXhiFgVsvqg+roC3YvluTWeTLdk=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=OGcthQW1J4nMpSUPDV6wa0+vAHKyDFRTdud3AhW3gtGgyVnq73OivU9djjLYqlLYJ
 yvn0t9GqeA8h5IzrnKfu5GqR3EVAAzYozqw8RSfgDQAstXd+n55ZCCFNolyKUeYddo
 Xrbl4ta/x5g+RjoOhasy6j2IV3iXCFuGKijtPcT4wet70B15gguPa8szsoQ0Q9nffQ
 q9y0V/Jwo9iUp/a/bUkwy+arrzkNnLNt4rQNtb7OLPnbMkhQkc+M47dJ43xg7k3TUT
 Gl/nTM/Ja1A7xHGzKyyRMYLn9aC719Ye0UC8WwKVJnu6MoFJW1kYjCnPt0/4la/m7p
 I8YQJe+cfQdKg==
Date: Tue, 31 Oct 2023 22:12:20 +0000
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <kUmZIImH6VJ8pd1WdqSJiWtNIIuKAI7ZxvUUH2_DPHOZofN1zcZK_mJXBSGlKQ2OoSevQIVBWcZkH1m1oFCrBDPdzkIE9UjxZLbQ-RvUJcU=@protonmail.com>
In-Reply-To: <CALZpt+FN4XeGD2Yh7pEUhuFtgMtNgbVKThFgF-fU9pD3sPnc2A@mail.gmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
 <CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
 <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.com>
 <CALZpt+FN4XeGD2Yh7pEUhuFtgMtNgbVKThFgF-fU9pD3sPnc2A@mail.gmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 31 Oct 2023 22:53:01 +0000
Subject: Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In
	N-of-N (N > 2) Multiparticipant Offchain Mechanisms
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2023 22:12:35 -0000

Hi Antoine, Zman and list,

The whole line of thinking here is interesting but indeed my first question=
 was "who does the penalty of the actuary go to?" and yeah, it seems we're =
still fairly stuck there.

re:

> However, the amount of satoshis that should be locked in such fidelity bo=
nds must be equal to the counterparty initial balance multiplied by the rem=
aining counterparties, as one can cheat against every other party (assuming=
 there is no shared communication channel where equivocation can be observe=
d). E.g if your factory has 1000 participants and your balance is 10 000 sa=
toshis, you *must* lock up 10 000 000 in fidelity bonds while only 1 / 1000=
th of the amount can be leveraged as off-chain contract or payment.

.. just wanted to point out that I was able to address this in PathCoin [1]=
. I found a way to avoid the linear dependence of total fidelity bond on nu=
mber of participants, but only under severe restriction: using CTV/covenant=
 (not so severe), but also, fixing order of transfer (ultra severe!). i.e. =
a coin of 10k sats only needs a lock up of 10k + delta sats from each parti=
cipant that spends it (if you don't spend it then of course you don't stric=
tly need to lock up anything).

the mechanism is, whimsically, similar to a series of airlocks: each script=
PubKey looks like [(A and CLTV) OR (T_A and CTV)] -> [(B and CLTV) OR (H(B)=
 and T_A and CTV)] -> [(C and CLTV) OR (H(C) and T_A and CTV)] -> ...

The arrows -> indicate what the CTV points to; T_A is a point corresponding=
 to an adaptor t_A, so that a spend of the pathcoin to A reveals t_A, the p=
rivkey of T_A, and the H() terms are locks, so that, when B transfers the p=
athcoin to C, he also transfers the preimage of H(B), so that the second sc=
riptPubKey above can be spent to the third immediately, because C knows the=
 preimage of H(B) as well as t_A as per previous.

Clearly, in a more flexible design, this might not be super interesting, bu=
t perhaps it gives a clue on a direction forward.

I tried to look for "reuse pathcoin fidelity bonds/penalty bonds across dif=
ferent pathcoins in parallel or in series" ideas but I continually hit agai=
nst the same character of problems as you describe here, either double spen=
d problems, or collusion problems. Only the above ultra-simple fixed-path s=
eems to be stable.

I do have a suspicion that APO can indeed be a big part of any solution to =
this thorny problem (haven't thought about it for a while).

[1] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da

Cheers,
waxwing/AdamISZ



Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, 4 October 2023 at 20:12, Antoine Riard via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:


> Hi Zeeman,
> > Basically, the big issue is that the actuary needs to bond a significan=
t amount of funds to each participant, and that bond is not part of the fun=
ding of the construction.
> >
> > Other ways of ensuring single-use can be replaced, if that is possible.
> > Do you know of any?
>=20
> As explained in the other post, if you wish to ensure lack of equivocatio=
n of an off-chain state I think you're left between updating dynamically th=
e subgroup of balance keys *on-chain* (i.e use the blockchain as an anti-do=
uble spend oracle) or ensure any equivocation can be punished as soon as on=
e party gains knowledge of two commitment signatures.
>=20
> I think you can design a fraud proof system encumbering each channel fact=
ory or pool balance by leveraging OP_CHECKSIGFROMSTACK and the spent outpoi=
nt committed as a partial transaction template. However, the amount of sato=
shis that should be locked in such fidelity bonds must be equal to the coun=
terparty initial balance multiplied by the remaining counterparties, as one=
 can cheat against every other party (assuming there is no shared communica=
tion channel where equivocation can be observed).
>=20
> E.g if your factory has 1000 participants and your balance is 10 000 sato=
shis, you *must* lock up 10 000 000 in fidelity bonds while only 1 / 1000th=
 of the amount can be leveraged as off-chain contract or payment.
>=20
> Of course pre-nominated coordinator reduces the burden from the full *fla=
t* fidelity bond, though it has to be weighed with coordinator unavailabili=
ty occurence where each participant has to withdraw his balance on-chain, a=
nd bears the fee cost.
>=20
> Best,
> Antoine
>=20
> Le mar. 12 sept. 2023 =C3=A0 10:41, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =
=C3=A9crit :
>=20
> > Good morning Antoine,
> >=20
> >=20
> > > Hi Zeeman
> > >
> > > > 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`.
> > >
> > > > As we know, `R` reuse --- creating a new signature for a
> > > > different message but the same `R` --- will leak the
> > > > private key.
> > >
> > > > 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.
> > >
> > > > 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.
> > >
> > > From my understanding, if an off-chain state N1 with a negotiated gro=
up of 40 is halted in the middle of the actuary's R reveals due to the 40th=
 participant non-interactivity, there is no guarantee than a new off-chain =
state N1' with a new negotiated group of 39 (from which evicted 40th's outp=
ut is absent) do not re-use R reveals on N1. So for the actuary bond securi=
ty, I think the R reveal should only happen once all the group participants=
 have revealed their own signature. It sounds like some loose interactivity=
 is still assumed, i.e all the non-actuary participants must be online at t=
he same time, and lack of contribution is to blame as you have a "flat" off=
-chain construction (i.e no layering of the promised off-chain outputs in s=
ubgroups to lower novation interactivity).
> >=20
> > Yes, there is some loose interactivity assumed.
> >=20
> > However:
> >=20
> > * The actuary is always online and can gather signatures for the next s=
tate in parallel with signing new transactions on top of the next state.
> > * This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on to=
p of the next state might spend either the actual next state (if the next s=
tate is successfully signed), or the current state plus additional transact=
ions (i.e. the transaction that move from current state to next state) (if =
the next state fails to get fully signed and the participants decide to giv=
e up on the next state getting signed).
> >=20
> > > More fundamentally, I think this actuarial system does not solve the =
"multi-party off-chain state correction" problem as there is no guarantee t=
hat the actuary does not slash the bond itself. And if the bond is guarded =
by users' pubkeys, there is no guarantee that the user will cooperate after=
 the actuary equivocation is committed to sign a "fair" slashing transactio=
n.
> >=20
> > Indeed.
> >=20
> > One can consider that the participants other than the actuary would gen=
erate a single public key known by the participants.
> > But then only one sockpuppet of the actuary is needed to add to the par=
ticipant set.
> >=20
> > Basically, the big issue is that the actuary needs to bond a significan=
t amount of funds to each participant, and that bond is not part of the fun=
ding of the construction.
> >=20
> > Other ways of ensuring single-use can be replaced, if that is possible.
> > Do you know of any?
> >=20
> > Regards,
> > ZmnSCPxj