path: root/94/71ee2e84d165935c288f57d7dc725a9e8ccf4a

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 6B87DC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 03:39:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2F71D41523
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 03:39:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2F71D41523
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=kF5sWt5M
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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=ham 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 LeFPC3_Mjh0v
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 03:39:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8DCF141511
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com
 [IPv6:2607:f8b0:4864:20::d29])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8DCF141511
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Apr 2023 03:39:09 +0000 (UTC)
Received: by mail-io1-xd29.google.com with SMTP id
 ca18e2360f4ac-7606d6b0db3so227797139f.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Apr 2023 20:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1681789148; x=1684381148;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=+gygJiDqtAB62mGpV7aJE/+2UPFECvEUunRWtb2KM4I=;
 b=kF5sWt5MSu0wQyJy5PkPmLtIN+ee/J8gPdHF9zEqHr9/Nmyl1INHQfn5X0ecgtpwW3
 6I3pwICEDuVrG8XntkSt2/i/qj6vjxlLpDkwIVfRMTzsu4Mxm7GvgpSy2bzyrIIyWwO6
 7Suw0VTXAP4nLYZIR0NfcDxoZ28V7YwOh2z6fXvYORrOr9CGASs4HLxKRiuuxUmh/+P4
 aOgFpUhLAQH9hr34C6WpQ166Bf77/sdnH7cSBKerD60CVvl8RVdqAEUvtOaJmYBeAtpS
 kN4J/2lz18gVZctdG8FpRi0GaQ+rkeSjQcUkc/XjHY/Jh/LkQmPq1L+n3aI5p4oEzc1D
 d/eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1681789148; x=1684381148;
 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=+gygJiDqtAB62mGpV7aJE/+2UPFECvEUunRWtb2KM4I=;
 b=FIHohctRRTVjeOasgBjHJP4K8fCSQ3uEhNogHxWmn6qA7CVVilvxNxcv2e5ZJAh7No
 4oMzuFqbN9SVFFSrgsw0IAczlYho+3BaGD24JlsRAJNWbIyHpR/7Ng+bYB0EYFfRLpmh
 1iNXVDLZ2qRiM1yV7U9qf5/4QA4bHUX2nu9+G/q+ckyxckgEPyZOYVWCRnExuT8fRcMF
 U8EbSl+xN/cHBHD1aW5mjJcdtrKcPD2T8VhxMI8DLlHUpCrS13mbCoMy3pD8Z9tzkhJ+
 wC2JQo7mfT7OfBz+WxmAAUd9yDdoki9E2JmrOz7afXpeFKXpaZV30R5hCP6WtJeArmqB
 PdFg==
X-Gm-Message-State: AAQBX9diQuZJBbbaF4J4QMQYL1YDNwexgnAhYRunvpuKXnfOOypUzzla
 zQIaaUXEzzbizXP6gfcyN+dVA9z6frKQi0U8tKs=
X-Google-Smtp-Source: AKy350biHFOa6I8uWsjy7q7jNUU7wfy7zTsUV3tkOtp1GHN2u56bSS1zMXBhFziHuH5cXMG7dWH7rVXCwpMWAd0cNt4=
X-Received: by 2002:a5d:9502:0:b0:763:5ead:f212 with SMTP id
 d2-20020a5d9502000000b007635eadf212mr619620iom.21.1681789148220; Mon, 17 Apr
 2023 20:39:08 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GNoRdbtfeBtpnitiAZ4jGwSsRpSRXOyX7mzrhwewmBcw@mail.gmail.com>
 <HJ2_OH4FKFmPnfms-7QajxORYiNw-Fo8p72auDWL1n_ES6kyw1WYedxKYrZOHQL3DbY6yRb6XvNeneZbd6ZjwgNjtHPST4Fe_bmc0MRWA7Q=@protonmail.com>
In-Reply-To: <HJ2_OH4FKFmPnfms-7QajxORYiNw-Fo8p72auDWL1n_ES6kyw1WYedxKYrZOHQL3DbY6yRb6XvNeneZbd6ZjwgNjtHPST4Fe_bmc0MRWA7Q=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 18 Apr 2023 04:38:57 +0100
Message-ID: <CALZpt+HQxfo_tEWZADG47-_TmjKP8YJXu5oC2emwgw++PGgDNw@mail.gmail.com>
To: jlspc <jlspc@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000c453d405f9940cf7"
X-Mailman-Approved-At: Tue, 18 Apr 2023 10:10:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Conjectures on solving the high interactivity
 issue in payment pools and channel factories
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, 18 Apr 2023 03:39:12 -0000

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

Hi John,

Thanks for the read!

> Agreed that signing updates and monitoring the blockchain both create
always-online requirements that are not compatible with casual users'
desires. I think
> it's helpful to separate these two cases, as they affect different
parties and their solutions differ.
> In particular, limited availability to sign updates affects one's
partners and can be addressed by having fewer partners, not partnering with
casual users, evicting > unresponsive users, etc.
> Limited availability to monitor the blockchain affects the security of
one's own funds and can be addressed by increasing one's safety parameters
(such as the > to_self_delay parameter in Lightning).

Yes, I think effectively the logical coordination of the signed off-chain
updates and the chain monitoring is defining the problem space. Of course,
there is the solution of
having less off-chain partners and bumping safety timelocks.

Though here I think it comes at the downside of more UTXO storage
requirements for base-layer nodes and an average increase in the price of
liquidity for LN users due to more extensive timevalue.

I think an intermediary solution can be to make the signing updates (and
the fraud proofs or "partition statements" in the post) a structure
enforceable by Bitcoin Script in a way than all the "revoked" on-chain
partitions can be punished, like with some
OP_MERKLE_ADD/TAPROOT_LEAF_UPDATE_VERIFY to ensure the cheater cannot
escape the clawback ?

> I would argue that we want a completely trust-free solution, if at all
possible, while respecting users' actual availability.
> We should only consider solutions that require trust if we can't find a
trust-free solution that meets all other requirements.

I would love to find a completely trust-free solution. One of the hard
things is defining trust :)

Note, as soon as you start to consider off-chain Bitcoin trust models you
have a multi-dimensional risks model to solve e.g miners incentives,
network connectivity, mempools congestion, proactive security of your
threshold signing shares in face of your counterparty liveliness, consensus
upgrades
altering network-wide transaction-relay rules, ...

> Actually, there's a third class of solutions that are possible, namely
ones that use separate control transactions and value transactions (where
the value > transactions "spend", and therefore depend on, the control
transactions).
> If an invalid control transaction is put on-chain, it can be blocked by
another user by spending its output(s) before the output(s) can affect the
value transaction.
> Thus, control transactions can be viewed as proposals for state updates,
and those proposals are blocked if they aren't valid.
> These solutions differ from prophylactic solutions, as they allow
incorrect transactions to be put on-chain and require another user to block
them.
> They also differ from your definition of a corrective security model, as
they never allow the state update to be applied to the value in the channel
or pool, so
> there's nothing to be corrected.
> An example of this third class of solutions is the Tunable-Penalty
Factory protocol [1].
> Of course, this example was not available when you noted that solutions
are either prophylactic or corrective.

FYI, I think the idea of separating control transactions and value
transactions (as done in electronic engineering between control signal and
actual voltage) has been explored in the past [0].

I still believe this family of solutions can be fitted in the corrective
class, as you have an invalid control transaction that can be corrected by
another *valid* control transaction, and I still think it's incentive-based
as there is a risk of the valid control transaction never confirming ? Or
the funds getting frozen due to a miscellaneous broadcast?

> On the other hand, protocols that use separate control and value
transactions do not have this limitation.
> For example, the Tunable-Penalty Factory protocol is a multi-party
protocol in which every dishonest party is penalized and there is no
economic disequilibrium.

Yes, I think this is a good observation. For the partitioned-payment pool
this can be corrected by ensuring only the honest party can enforce the
partitioned statement and you have to timestamp them in the chain for
Bitcoin Script itself to order them, I think.

Do the Tunable-Penalty Factory protocol have any "partition-throughput"
limit due to a subsidiary reliance on the chain or the liveliness of the N
counterparties ?

> If I understand this correctly, I think a penalty mechanism that allows a
"wronged" user to take some or all of a dishonest user's funds could be
exploited by a malicious coalition.
> Consider the case where Alice is an honest user who joins a partition
with Bob, where Bob and Carol are in a malicious coalition.
> Alice believes she has pooled her funds with Bob's and so she is able to
work with Bob to implement an off-line update of their balances, with Alice
believing
> that she has gained ownership over some of Bob's funds.
> However, when the partitioning Update transaction that joins Alice's and
Bob's funds is put on-chain, Carol pretends to have been "wronged" by Bob
and uses > the penalty mechanism to seize Bob's funds.
> In this case, Alice won't be able to get the funds that she thought she
had obtained from Bob.

Yes you need to order the "partition-statements" otherwise you're falling
on this issue and the ordering happening in a proof-of-non-publication
space, I think [1].

Best,
Antoine

[0] https://rubin.io/talks/2017/01/26/multi-txn-contracts/
[1] https://petertodd.org/2016/state-machine-consensus-building-blocks

Le ven. 17 mars 2023 =C3=A0 20:55, jlspc <jlspc@protonmail.com> a =C3=A9cri=
t :

> Hi Antoine,
>
> Thanks for your insightful post on the interactivity issue.
>
> Some thoughts are inline below.
>
> > However, those constructions require all the users to be online and
> > exchange rounds of signatures to update the balance distribution. Those
> > liveliness/interactivity requirements are increasing with the number of
> > users, as there are higher odds of *one* lazzy/buggy/offline user stall=
ing
> > the pool/factory updates.
>
> > In echo, the design of LN was envisioned for a network of
> > always-online/self-hosted participants, the early deployment of LN show=
ed
> > the resort to delegated channel hosting solutions, relieving users from=
 the
> > liveliness requirement. While the trust trade-offs of those solutions a=
re
> > significant, they answer the reality of a world made of unreliable netw=
orks
> > and mobile devices.
>
> Agreed that signing updates and monitoring the blockchain both create alw=
ays-online requirements that are not compatible with casual users' desires.
> I think it's helpful to separate these two cases, as they affect differen=
t parties and their solutions differ.
> In particular, limited availability to sign updates affects one's partner=
s and can be addressed by having fewer partners, not partnering with casual=
 users, evicting unresponsive users, etc.
> Limited availability to monitor the blockchain affects the security of on=
e's own funds and can be addressed by increasing one's safety parameters (s=
uch as the to_self_delay parameter in Lightning).
>
> > Ideally, I think we would like a trust-minimized solution enabling
> > non-interactive, off-chain updates of the pool/factory, with no or mini=
mal
> > consumption of blockspace.
>
> I would argue that we want a completely trust-free solution, if at all po=
ssible, while respecting users' actual availability.
> We should only consider solutions that require trust if we can't find a t=
rust-free solution that meets all other requirements.
>
> > For the remainder of this post, only the pool use-case will be mentione=
d.
> > Though, I think the observations/implications can be extended to factor=
ies
> > as well.
>
> > Of course, the double-spend issue is already addressed on the Bitcoin
> > base-layer due to nodes consensus convergence on the most-proof-of-work
> > accumulated valid chain of blocks. While reorg can happen, a UTXO canno=
t be
> > spent twice on the same chain. This security model can be said to be
> > prophylactic, i.e an invalid block cannot be applied to a node's state =
and
> > should be rejected.
>
> > The double-spend issue is also solved in its own way in payment channel=
s.
> > If a transaction is published, of which the correctness has been revoke=
d
> > w.r.t negotiated, private channel state, the wronged channel users must
> > react in consequence. This security model can be said to be corrective,
> > states updates are applied first on the global ledger then eventually
> > corrected.
>
> > A solution to the pool partition equivocation issue appears as either b=
ased
> > on a prophylactic one or a corrective security model.
>
> Actually, there's a third class of solutions that are possible, namely on=
es that use separate control transactions and value transactions (where the=
 value transactions "spend", and therefore depend on, the control transacti=
ons).
> If an invalid control transaction is put on-chain, it can be blocked by a=
nother user by spending its output(s) before the output(s) can affect the v=
alue transaction.
> Thus, control transactions can be viewed as proposals for state updates, =
and those proposals are blocked if they aren't valid.
>
> These solutions differ from prophylactic solutions, as they allow incorre=
ct transactions to be put on-chain and require another user to block them.
> They also differ from your definition of a corrective security model, as =
they never allow the state update to be applied to the value in the channel=
 or pool, so there's nothing to be corrected.
> An example of this third class of solutions is the Tunable-Penalty Factor=
y protocol [1].
> Of course, this example was not available when you noted that solutions a=
re either prophylactic or corrective.
>
> > E.g, let's say you have Alice, Bob, Caroll and Dave as pool participant=
s.
> > Alice contacts Bob to form a first partition, then Caroll to form a sec=
ond
> > one, then Dave to form a last one. If she is successful in that
> > equivocation trick, she can *triple*-spend her balance against any good=
s or
> > out-of-pool payments.
>
> > However, correction can only
> > be limited to the equivocated balance. Therefore, it appears that
> > corrective security models in the context of multi-party are always
> > producing an economic disequilibrium.
>
> On the other hand, protocols that use separate control and value transact=
ions do not have this limitation.
> For example, the Tunable-Penalty Factory protocol is a multi-party protoc=
ol in which every dishonest party is penalized and there is no economic dis=
equilibrium.
>
> > I think that leveraging covenants a revocation mechanism could be attac=
hed
> > on any equivocating branch of transactions, allowing in the above case =
a
> > single honest user to punish the publication. While a revocation mechan=
ism
> > does not work in case of multiple defrauded users, I believe the existe=
nce
> > of a revocation mechanism makes the formation of malicious coalitions
> > unsafe for their conjurers.
>
> > Indeed, any user entering in the coalition is not guaranteed to be blin=
ded
> > to other equivocating branches generated by the partition initiator.
> > Therefore, the publication of a partition statement by everyone is
> > holistically optimal to discover any equivocating candidate among the p=
ool
> > users.
>
> If I understand this correctly, I think a penalty mechanism that allows a=
 "wronged" user to take some or all of a dishonest user's funds could be ex=
ploited by a malicious coalition.
> Consider the case where Alice is an honest user who joins a partition wit=
h Bob, where Bob and Carol are in a malicious coalition.
> Alice believes she has pooled her funds with Bob's and so she is able to =
work with Bob to implement an off-line update of their balances, with Alice=
 believing that she has gained ownership over some of Bob's funds.
> However, when the partitioning Update transaction that joins Alice's and =
Bob's funds is put on-chain, Carol pretends to have been "wronged" by Bob a=
nd uses the penalty mechanism to seize Bob's funds.
> In this case, Alice won't be able to get the funds that she thought she h=
ad obtained from Bob.
>
> Does that make sense?
>
> Regards,
> John
>
> [1] Law, "Efficient Factories For Lightning Channels", available at https=
://github.com/JohnLaw2/ln-efficient-factories.
>
>
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
>
>

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

<div dir=3D"ltr">Hi John,<div><br></div><div>Thanks for the read!</div><div=
><br></div><div>&gt;=C2=A0<span style=3D"font-size:14px;white-space:pre-wra=
p">Agreed that signing updates and monitoring the blockchain both create al=
ways-online requirements that are not compatible with casual users&#39; des=
ires. </span><span style=3D"font-size:14px;white-space:pre-wrap">I think</s=
pan></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; it&=
#39;s helpful to separate these two cases, as they affect different parties=
 and their solutions differ.</span></div><div><span style=3D"font-size:14px=
;white-space:pre-wrap">&gt; In particular, limited availability to sign upd=
ates affects one&#39;s partners and can be addressed by having fewer partne=
rs, not partnering with casual users, evicting &gt; unresponsive users, etc=
.</span></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt;=
 Limited availability to monitor the blockchain affects the security of one=
&#39;s own funds and can be addressed by increasing one&#39;s safety parame=
ters (such as the &gt; to_self_delay parameter in Lightning).</span></div><=
div><br></div><div>Yes, I think effectively the logical coordination of the=
 signed off-chain updates and the chain monitoring is defining the problem =
space. Of course, there is the solution=C2=A0of</div><div>having less off-c=
hain partners and bumping safety timelocks.</div><div><br></div><div>Though=
 here I think it comes at the downside of more UTXO storage requirements fo=
r base-layer nodes and an average increase in the price of liquidity for LN=
 users due to more extensive timevalue.</div><div><br></div><div>I think an=
 intermediary solution can be to make the signing updates (and the fraud pr=
oofs or &quot;partition statements&quot; in the post) a structure enforceab=
le by Bitcoin Script in a way than all the &quot;revoked&quot; on-chain par=
titions can be punished, like with some OP_MERKLE_ADD/TAPROOT_LEAF_UPDATE_V=
ERIFY to ensure the cheater cannot escape the clawback ?</div><div><span st=
yle=3D"font-size:14px;white-space:pre-wrap"><br></span></div><div>&gt;=C2=
=A0<span style=3D"font-size:14px;white-space:pre-wrap">I would argue that w=
e want a completely trust-free solution, if at all possible, while respecti=
ng users&#39; actual availability.</span><br></div><div><span style=3D"font=
-size:14px;white-space:pre-wrap">&gt; We should only consider solutions tha=
t require trust if we can&#39;t find a trust-free solution that meets all o=
ther requirements.</span></div><div><span style=3D"font-size:14px;white-spa=
ce:pre-wrap"><br></span></div><div><span style=3D"font-size:14px;white-spac=
e:pre-wrap">I would love to find a completely trust-free solution. One of t=
he hard things is defining trust :)</span></div><div><span style=3D"font-si=
ze:14px;white-space:pre-wrap"><br></span></div><div><span style=3D"font-siz=
e:14px;white-space:pre-wrap">Note, as soon as you start to consider off-cha=
in Bitcoin trust models you have a multi-dimensional risks model to solve e=
.g miners incentives, network connectivity, mempools congestion, proactive =
security of your threshold signing shares in face of your counterparty live=
liness, consensus upgrades</span></div><div><span style=3D"font-size:14px;w=
hite-space:pre-wrap">altering network-wide transaction-relay rules, ...</sp=
an></div><div><span style=3D"font-size:14px;white-space:pre-wrap"><br></spa=
n></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; Actua=
lly, there&#39;s a third class of solutions that are possible, namely ones =
that use separate control transactions and value transactions (where the va=
lue &gt; transactions &quot;spend&quot;, and therefore depend on, the contr=
ol transactions).</span></div><div><span style=3D"font-size:14px;white-spac=
e:pre-wrap">&gt; </span><span style=3D"font-size:14px;white-space:pre-wrap"=
>If an invalid control transaction is put on-chain, it can be blocked by an=
other user by spending its output(s) before the output(s) can affect the va=
lue transaction.</span></div><div><span style=3D"font-size:14px;white-space=
:pre-wrap">&gt; Thus, control transactions can be viewed as proposals for s=
tate updates, and those proposals are blocked if they aren&#39;t valid.</sp=
an></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt;  </s=
pan><span style=3D"font-size:14px;white-space:pre-wrap">These solutions dif=
fer from prophylactic solutions, as they allow incorrect transactions to be=
 put on-chain and require another user to block them.</span></div><div><spa=
n style=3D"font-size:14px;white-space:pre-wrap">&gt; They also differ from =
your definition of a corrective security model, as they never allow the sta=
te update to be applied to the value in the channel or pool, so</span></div=
><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; there&#39;s =
nothing to be corrected.</span></div><div><span style=3D"font-size:14px;whi=
te-space:pre-wrap">&gt; </span><span style=3D"font-size:14px;white-space:pr=
e-wrap">An example of this third class of solutions is the Tunable-Penalty =
Factory protocol [1].</span></div><div><span style=3D"font-size:14px;white-=
space:pre-wrap">&gt; Of course, this example was not available when you not=
ed that solutions are either prophylactic or corrective.</span></div><div><=
span style=3D"font-size:14px;white-space:pre-wrap"><br></span></div><div><s=
pan style=3D"font-size:14px;white-space:pre-wrap">FYI, I think the idea of =
separating control transactions and value transactions (as done in electron=
ic engineering between control signal and actual voltage) has been explored=
 in the past [0].</span></div><div><span style=3D"font-size:14px;white-spac=
e:pre-wrap"><br></span></div><div><span style=3D"font-size:14px;white-space=
:pre-wrap">I still believe this family of solutions can be fitted in the co=
rrective class, as you have an invalid control transaction that can be corr=
ected by another *valid* control transaction, and I still think it&#39;s in=
centive-based as there is a risk of the valid control transaction never con=
firming ? Or the funds getting frozen due to a miscellaneous broadcast?</sp=
an></div><div><span style=3D"color:rgb(0,0,0);white-space:pre-wrap"><br></s=
pan></div><div><span style=3D"white-space:pre-wrap;font-size:14px">&gt; </s=
pan><span style=3D"color:rgb(0,0,0);white-space:pre-wrap">On the other hand=
, protocols that use separate control and value transactions do not have th=
is limitation.</span><br></div><div><span style=3D"color:rgb(0,0,0);white-s=
pace:pre-wrap">&gt; For example, the Tunable-Penalty Factory protocol is a =
multi-party protocol in which every dishonest party is penalized and there =
is no economic disequilibrium.</span><span style=3D"font-size:14px;white-sp=
ace:pre-wrap"> </span></div><div><span style=3D"font-size:14px;white-space:=
pre-wrap"><br></span></div><div><span style=3D"font-size:14px;white-space:p=
re-wrap">Yes, I think this is a good observation. For the partitioned-payme=
nt pool this can be corrected by ensuring only the honest party can enforce=
 the partitioned statement and you have to timestamp them in the chain for =
Bitcoin Script itself to order them, I think.</span></div><div><span style=
=3D"font-size:14px;white-space:pre-wrap"><br></span></div><div><span style=
=3D"font-size:14px;white-space:pre-wrap">Do the Tunable-Penalty Factory pro=
tocol have any &quot;partition-throughput&quot; limit due to a subsidiary r=
eliance on the chain or the liveliness of the N counterparties ?</span></di=
v><div><span style=3D"font-size:14px;white-space:pre-wrap"><br></span></div=
><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; If I underst=
and this correctly, I think a penalty mechanism that allows a &quot;wronged=
&quot; user to take some or all of a dishonest user&#39;s funds could be ex=
ploited by a malicious coalition.</span></div><div>&gt;=C2=A0<span style=3D=
"font-size:14px;white-space:pre-wrap">Consider the case where Alice is an h=
onest user who joins a partition with Bob, where Bob and Carol are in a mal=
icious coalition.</span></div><div><span style=3D"font-size:14px;white-spac=
e:pre-wrap">&gt;  </span><span style=3D"font-size:14px;white-space:pre-wrap=
">Alice believes she has pooled her funds with Bob&#39;s and so she is able=
 to work with Bob to implement an off-line update of their balances, with A=
lice believing</span></div><div><span style=3D"font-size:14px;white-space:p=
re-wrap">&gt; that she has gained ownership over some of Bob&#39;s funds.</=
span></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; Ho=
wever, when the partitioning Update transaction that joins Alice&#39;s and =
Bob&#39;s funds is put on-chain, Carol pretends to have been &quot;wronged&=
quot; by Bob and uses &gt; the penalty mechanism to seize Bob&#39;s funds.<=
/span></div><div><span style=3D"font-size:14px;white-space:pre-wrap">&gt; I=
n this case, Alice won&#39;t be able to get the funds that she thought she =
had obtained from Bob.</span></div><div><span style=3D"font-size:14px;white=
-space:pre-wrap"><br></span></div><div><span style=3D"font-size:14px;white-=
space:pre-wrap">Yes you need to order the &quot;partition-statements&quot; =
otherwise you&#39;re falling on this issue and the ordering happening in a =
proof-of-non-publication space, I think [1].</span></div><div><span style=
=3D"font-size:14px;white-space:pre-wrap"><br></span></div><div><span style=
=3D"font-size:14px;white-space:pre-wrap">Best,</span></div><div><span style=
=3D"font-size:14px;white-space:pre-wrap">Antoine</span></div><div><span sty=
le=3D"font-size:14px;white-space:pre-wrap"><br></span></div><div><span styl=
e=3D"font-size:14px;white-space:pre-wrap">[0] </span><a href=3D"https://rub=
in.io/talks/2017/01/26/multi-txn-contracts/">https://rubin.io/talks/2017/01=
/26/multi-txn-contracts/</a></div><div>[1]=C2=A0<a href=3D"https://petertod=
d.org/2016/state-machine-consensus-building-blocks">https://petertodd.org/2=
016/state-machine-consensus-building-blocks</a></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 17 mars=
 2023 =C3=A0=C2=A020:55, jlspc &lt;<a href=3D"mailto:jlspc@protonmail.com">=
jlspc@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><pre style=3D"wh=
ite-space:pre-wrap">Hi Antoine,

Thanks for your insightful post on the interactivity issue.

Some thoughts are inline below.

&gt; However, those constructions require all the users to be online and
&gt; exchange rounds of signatures to update the balance distribution. Thos=
e
&gt; liveliness/interactivity requirements are increasing with the number o=
f
&gt; users, as there are higher odds of *one* lazzy/buggy/offline user stal=
ling
&gt; the pool/factory updates.

&gt; In echo, the design of LN was envisioned for a network of
&gt; always-online/self-hosted participants, the early deployment of LN sho=
wed
&gt; the resort to delegated channel hosting solutions, relieving users fro=
m the
&gt; liveliness requirement. While the trust trade-offs of those solutions =
are
&gt; significant, they answer the reality of a world made of unreliable net=
works
&gt; and mobile devices.

Agreed that signing updates and monitoring the blockchain both create alway=
s-online requirements that are not compatible with casual users&#39; desire=
s.
I think it&#39;s helpful to separate these two cases, as they affect differ=
ent parties and their solutions differ.
In particular, limited availability to sign updates affects one&#39;s partn=
ers and can be addressed by having fewer partners, not partnering with casu=
al users, evicting unresponsive users, etc.
Limited availability to monitor the blockchain affects the security of one&=
#39;s own funds and can be addressed by increasing one&#39;s safety paramet=
ers (such as the to_self_delay parameter in Lightning).

&gt; Ideally, I think we would like a trust-minimized solution enabling
&gt; non-interactive, off-chain updates of the pool/factory, with no or min=
imal
&gt; consumption of blockspace.

I would argue that we want a completely trust-free solution, if at all poss=
ible, while respecting users&#39; actual availability.
We should only consider solutions that require trust if we can&#39;t find a=
 trust-free solution that meets all other requirements.

&gt; For the remainder of this post, only the pool use-case will be mention=
ed.
&gt; Though, I think the observations/implications can be extended to facto=
ries
&gt; as well.

&gt; Of course, the double-spend issue is already addressed on the Bitcoin
&gt; base-layer due to nodes consensus convergence on the most-proof-of-wor=
k
&gt; accumulated valid chain of blocks. While reorg can happen, a UTXO cann=
ot be
&gt; spent twice on the same chain. This security model can be said to be
&gt; prophylactic, i.e an invalid block cannot be applied to a node&#39;s s=
tate and
&gt; should be rejected.

&gt; The double-spend issue is also solved in its own way in payment channe=
ls.
&gt; If a transaction is published, of which the correctness has been revok=
ed
&gt; w.r.t negotiated, private channel state, the wronged channel users mus=
t
&gt; react in consequence. This security model can be said to be corrective=
,
&gt; states updates are applied first on the global ledger then eventually
&gt; corrected.

&gt; A solution to the pool partition equivocation issue appears as either =
based
&gt; on a prophylactic one or a corrective security model.

Actually, there&#39;s a third class of solutions that are possible, namely =
ones that use separate control transactions and value transactions (where t=
he value transactions &quot;spend&quot;, and therefore depend on, the contr=
ol transactions).
If an invalid control transaction is put on-chain, it can be blocked by ano=
ther user by spending its output(s) before the output(s) can affect the val=
ue transaction.
Thus, control transactions can be viewed as proposals for state updates, an=
d those proposals are blocked if they aren&#39;t valid.

These solutions differ from prophylactic solutions, as they allow incorrect=
 transactions to be put on-chain and require another user to block them.
They also differ from your definition of a corrective security model, as th=
ey never allow the state update to be applied to the value in the channel o=
r pool, so there&#39;s nothing to be corrected.
An example of this third class of solutions is the Tunable-Penalty Factory =
protocol [1].
Of course, this example was not available when you noted that solutions are=
 either prophylactic or corrective.

&gt; E.g, let&#39;s say you have Alice, Bob, Caroll and Dave as pool partic=
ipants.
&gt; Alice contacts Bob to form a first partition, then Caroll to form a se=
cond
&gt; one, then Dave to form a last one. If she is successful in that
&gt; equivocation trick, she can *triple*-spend her balance against any goo=
ds or
&gt; out-of-pool payments.

&gt; However, correction can only
&gt; be limited to the equivocated balance. Therefore, it appears that
&gt; corrective security models in the context of multi-party are always
&gt; producing an economic disequilibrium.

On the other hand, protocols that use separate control and value transactio=
ns do not have this limitation.
For example, the Tunable-Penalty Factory protocol is a multi-party protocol=
 in which every dishonest party is penalized and there is no economic diseq=
uilibrium.

&gt; I think that leveraging covenants a revocation mechanism could be atta=
ched
&gt; on any equivocating branch of transactions, allowing in the above case=
 a
&gt; single honest user to punish the publication. While a revocation mecha=
nism
&gt; does not work in case of multiple defrauded users, I believe the exist=
ence
&gt; of a revocation mechanism makes the formation of malicious coalitions
&gt; unsafe for their conjurers.

&gt; Indeed, any user entering in the coalition is not guaranteed to be bli=
nded
&gt; to other equivocating branches generated by the partition initiator.
&gt; Therefore, the publication of a partition statement by everyone is
&gt; holistically optimal to discover any equivocating candidate among the =
pool
&gt; users.

If I understand this correctly, I think a penalty mechanism that allows a &=
quot;wronged&quot; user to take some or all of a dishonest user&#39;s funds=
 could be exploited by a malicious coalition.
Consider the case where Alice is an honest user who joins a partition with =
Bob, where Bob and Carol are in a malicious coalition.
Alice believes she has pooled her funds with Bob&#39;s and so she is able t=
o work with Bob to implement an off-line update of their balances, with Ali=
ce believing that she has gained ownership over some of Bob&#39;s funds.
However, when the partitioning Update transaction that joins Alice&#39;s an=
d Bob&#39;s funds is put on-chain, Carol pretends to have been &quot;wronge=
d&quot; by Bob and uses the penalty mechanism to seize Bob&#39;s funds.
In this case, Alice won&#39;t be able to get the funds that she thought she=
 had obtained from Bob.

Does that make sense?

Regards,
John

[1] Law, &quot;Efficient Factories For Lightning Channels&quot;, available =
at <a href=3D"https://github.com/JohnLaw2/ln-efficient-factories" target=3D=
"_blank">https://github.com/JohnLaw2/ln-efficient-factories</a>.
</pre><br><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14=
px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
        Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        <br>
    </div></blockquote></div>

--000000000000c453d405f9940cf7--