From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7B24FC0032 for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: AdamISZ Message-ID: In-Reply-To: References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com> <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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