path: root/98/bf6701d7a414c15409b07d1c7fb0e4c84e67d9

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0CFD3C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  5 Oct 2023 02:12:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C7E3B42029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  5 Oct 2023 02:12:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C7E3B42029
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=SHMQ3a9P
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level: 
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GcnSAhM9731V
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  5 Oct 2023 02:12:45 +0000 (UTC)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com
 [IPv6:2607:f8b0:4864:20::136])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 4680041FF4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  5 Oct 2023 02:12:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4680041FF4
Received: by mail-il1-x136.google.com with SMTP id
 e9e14a558f8ab-352a3a95271so2172035ab.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 04 Oct 2023 19:12:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1696471964; x=1697076764;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=c/7lsm5rbWwDyVGAVP4uYt+f4KFj4JmvAIMPN+egB40=;
 b=SHMQ3a9PU/AoyI2Mae3mX4hi0nMGGw2MmrDTfNr5L81aC2v/JmLzn187LDg+3ulLXd
 loqs2RZRd3cweEUJzU+qW8P76wp7c6ZSIbvgwybLkHpDaE60M91i5cvlJvygnxdJzYJt
 eH+R3QMzyNzDn3O1HMNPuFKHt+YvHfx3DgbSP/wxmbgV3XdQT1oO+qJm869jZZNLdImi
 zfwlm6gaU4Nh9CT9C8rfrf0jMlM2ENrniwn896GdmXjyLo0amkfZzRaUwrJhQ/weVWbq
 uPVT2kdoVmXaRrlVKgAIX/eV4KJoOjcaIJfZ7LxblJTDM/JegyKgx3TNiMxOtGJtCZIv
 Xl7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1696471964; x=1697076764;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=c/7lsm5rbWwDyVGAVP4uYt+f4KFj4JmvAIMPN+egB40=;
 b=gpZxYXSKHEftgqnpGE1m7KwX1ASBhg8zX6XgNdzM+2FFhx0o4zgZxbZdx8nWEwly80
 OhwjeNICqLzI6O6vK8LdwsZgJLI8Eoefn8tM4VZY/6JD9LcndKUjtyri+mig8y0e8oP4
 DS5tjve8N6nls7jeo/8PDrUoxTu+sVyRT5Bz23IgroaZ7W//ONDU6f4cxe9ic9IR9ic/
 R5qZTFr+rzk3CeclhfRLMvMK/IoPPVQCY2blwVyJ8EVGzvR3Q7HGUOaYsrspGIkvlWuh
 mWDvgGIeG7kJnMJ5eHVgh8v0H9CyeQth4HD0EfnqArgzx+0V5w6WYymKGKF+QgpX3Q7l
 FjuA==
X-Gm-Message-State: AOJu0YzztW1QS9pV89WjtU4UW8Q8Jnp4JovAUbdFTVAnxc/BOzKsgVvw
 7MZPQobDE8CHqxWJozj432vm6DXrB5K9Jg/dL7P+ssHiLmjUkJkO
X-Google-Smtp-Source: AGHT+IFVV29biqlD0tJ1wSex3H9dDARQlDnc/qoTeYenOA6Tkxi2bJ5p4F2OkdOYGG+aCSV27/jKpayvybC2/Q+qtyc=
X-Received: by 2002:a05:6e02:216c:b0:352:a73a:16f1 with SMTP id
 s12-20020a056e02216c00b00352a73a16f1mr3608584ilv.14.1696471964216; Wed, 04
 Oct 2023 19:12:44 -0700 (PDT)
MIME-Version: 1.0
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
 <CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
 <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.com>
In-Reply-To: <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 5 Oct 2023 03:12:33 +0100
Message-ID: <CALZpt+FN4XeGD2Yh7pEUhuFtgMtNgbVKThFgF-fU9pD3sPnc2A@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000cc72930606eea8c5"
X-Mailman-Approved-At: Thu, 05 Oct 2023 02:36:24 +0000
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
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: Thu, 05 Oct 2023 02:12:47 -0000

--000000000000cc72930606eea8c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Zeeman,

> Basically, the big issue is that the actuary needs to bond a significant
amount 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?

As explained in the other post, if you wish to ensure lack of equivocation
of an off-chain state I think you're left between updating dynamically the
subgroup of balance keys *on-chain* (i.e use the blockchain as an
anti-double spend oracle) or ensure any equivocation can be punished as
soon as one party gains knowledge of two commitment signatures.

I think you can design a fraud proof system encumbering each channel
factory or pool balance by leveraging OP_CHECKSIGFROMSTACK and the spent
outpoint committed as a partial transaction template. However, the amount
of satoshis that should be locked in such fidelity bonds must be equal to
the counterparty initial balance multiplied by the remaining
counterparties, as one can cheat against every other party (assuming there
is no shared communication channel where equivocation can be observed).

E.g if your factory has 1000 participants and your balance is 10 000
satoshis, 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.

Of course pre-nominated coordinator reduces the burden from the full *flat*
fidelity bond, though it has to be weighed with coordinator unavailability
occurence where each participant has to withdraw his balance on-chain, and
bears the fee cost.

Best,
Antoine

Le mar. 12 sept. 2023 =C3=A0 10:41, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =
=C3=A9crit :

> Good morning Antoine,
>
>
> > 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 group
> 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
> output is 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 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 the 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 subgroups 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 to=
p
> of the next state might spend either the actual next state (if the next
> state is successfully signed), or the current state plus additional
> transactions (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 give up on the next state getting signed).
>
> > More fundamentally, I think this actuarial system does not solve the
> "multi-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 guard=
ed
> by users' pubkeys, there is no guarantee that the user will cooperate aft=
er
> the actuary equivocation is committed to sign a "fair" slashing transacti=
on.
>
> Indeed.
>
> One can consider that the participants other than the actuary would
> generate a single public key known by the participants.
> But then only one sockpuppet of the actuary is needed to add to the
> participant set.
>
> Basically, the big issue is that the actuary needs to bond a significant
> amount 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
>

--000000000000cc72930606eea8c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Zeeman,<div><br></div><div>&gt; Basically, the big issu=
e is that the actuary needs to bond a significant amount of funds to each p=
articipant, and that bond is not part of the funding of the construction.<b=
r>&gt;=C2=A0<br>&gt; Other ways of ensuring single-use can be replaced, if =
that is possible.<br>&gt; Do you know of any?<br></div><div><br></div><div>=
As explained in the other post, if you wish to ensure lack of equivocation =
of an off-chain state I think you&#39;re left between updating dynamically =
the subgroup of balance keys *on-chain* (i.e use the blockchain as an anti-=
double spend oracle) or ensure any equivocation can be punished as soon as =
one party gains knowledge of two commitment signatures.</div><div><br></div=
><div>I think you can design a fraud proof system encumbering each channel =
factory or pool balance by leveraging OP_CHECKSIGFROMSTACK and the spent ou=
tpoint committed as a partial transaction template. However, the amount of =
satoshis that should be locked in such fidelity bonds must be equal to the =
counterparty initial balance multiplied by the remaining counterparties, as=
 one can cheat against every other party (assuming there is no shared commu=
nication channel where equivocation can be observed).</div><div><br></div><=
div>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.</div><d=
iv><br></div><div>Of course pre-nominated coordinator reduces the burden fr=
om the full *flat* fidelity bond, though it has to be weighed with coordina=
tor unavailability occurence where each participant has to withdraw his bal=
ance on-chain, and bears the fee cost.</div><div><br></div><div>Best,</div>=
<div>Antoine</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">Le=C2=A0mar. 12 sept. 2023 =C3=A0=C2=A010:41, ZmnSCPxj &l=
t;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt=
; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex">Good morning Antoine,<br>
<br>
<br>
&gt; Hi Zeeman<br>
&gt; <br>
&gt; &gt; What we can do is to add the actuary to the contract that<br>
&gt; &gt; controls the funds, but with the condition that the<br>
&gt; &gt; actuary signature has a specific `R`.<br>
&gt; <br>
&gt; &gt; As we know, `R` reuse --- creating a new signature for a<br>
&gt; &gt; different message but the same `R` --- will leak the<br>
&gt; &gt; private key.<br>
&gt; <br>
&gt; &gt; The actuary can be forced to put up an onchain bond.<br>
&gt; &gt; The bond can be spent using the private key of the actuary.<br>
&gt; &gt; If the actuary signs a transaction once, with a fixed `R`,<br>
&gt; &gt; then its private key is still safe.<br>
&gt; <br>
&gt; &gt; However, if the actuary signs one transaction that spends<br>
&gt; &gt; some transaction output, and then signs a different<br>
&gt; &gt; transaction that spends the same transaction output, both<br>
&gt; &gt; signatures need to use the same fixed `R`.<br>
&gt; &gt; Because of the `R` reuse, this lets anyone who expected<br>
&gt; &gt; one transaction to be confirmed, but finds that the other<br>
&gt; &gt; one was confirmed, to derive the secret key of the<br>
&gt; &gt; actuary from the two signatures, and then slash the bond<br>
&gt; &gt; of the actuary.<br>
&gt; <br>
&gt; From my understanding, if an off-chain state N1 with a negotiated grou=
p of 40 is halted in the middle of the actuary&#39;s R reveals due to the 4=
0th participant non-interactivity, there is no guarantee than a new off-cha=
in state N1&#39; with a new negotiated group of 39 (from which evicted 40th=
&#39;s output is 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 p=
articipants have revealed their own signature. It sounds like some loose in=
teractivity is still assumed, i.e all the non-actuary participants must be =
online at the same time, and lack of contribution is to blame as you have a=
 &quot;flat&quot; off-chain construction (i.e no layering of the promised o=
ff-chain outputs in subgroups to lower novation interactivity).<br>
<br>
Yes, there is some loose interactivity assumed.<br>
<br>
However:<br>
<br>
* 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.<br>
=C2=A0 * 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 nex=
t state is successfully signed), or the current state plus additional trans=
actions (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 =
give up on the next state getting signed).<br>
<br>
&gt; More fundamentally, I think this actuarial system does not solve the &=
quot;multi-party off-chain state correction&quot; problem as there is no gu=
arantee that the actuary does not slash the bond itself. And if the bond is=
 guarded by users&#39; pubkeys, there is no guarantee that the user will co=
operate after the actuary equivocation is committed to sign a &quot;fair&qu=
ot; slashing transaction.<br>
<br>
Indeed.<br>
<br>
One can consider that the participants other than the actuary would generat=
e a single public key known by the participants.<br>
But then only one sockpuppet of the actuary is needed to add to the partici=
pant set.<br>
<br>
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.<br>
<br>
Other ways of ensuring single-use can be replaced, if that is possible.<br>
Do you know of any?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000cc72930606eea8c5--