From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B87DC002A for ; 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 ; 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 ; 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 ; Tue, 18 Apr 2023 03:39:09 +0000 (UTC) Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-7606d6b0db3so227797139f.1 for ; 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: In-Reply-To: From: Antoine Riard Date: Tue, 18 Apr 2023 04:38:57 +0100 Message-ID: To: jlspc Content-Type: multipart/alternative; boundary="000000000000c453d405f9940cf7" X-Mailman-Approved-At: Tue, 18 Apr 2023 10:10:30 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 secure email. > > > --000000000000c453d405f9940cf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for the read!

>=C2=A0Agreed that signing updates and monitoring the blockchain both create al= ways-online requirements that are not compatible with casual users' des= ires. I think
> it&= #39;s helpful to separate these two cases, as they affect different parties= and their solutions differ.
> In particular, limited availability to sign upd= ates affects one's partners and can be addressed by having fewer partne= rs, 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 parame= ters (such as the > to_self_delay parameter in Lightning).
<= 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
having less off-c= hain partners and bumping safety timelocks.

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.

I think an= intermediary solution can be to make the signing updates (and the fraud pr= oofs or "partition statements" in the post) a structure enforceab= le by Bitcoin Script in a way than all the "revoked" 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 ?

>=C2= =A0I would argue that w= e want a completely trust-free solution, if at all possible, while respecti= ng users' actual availability.
> We should only consider solutions tha= t require trust if we can't find a trust-free solution that meets all o= ther requirements.

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

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
altering network-wide transaction-relay rules, ...

> Actua= lly, there's a third class of solutions that are possible, namely ones = that use separate control transactions and value transactions (where the va= lue > transactions "spend", and therefore depend on, the contr= ol transactions).
> 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.
> Thus, control transactions can be viewed as proposals for s= tate updates, and those proposals are blocked if they aren't valid.
> These solutions dif= fer 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 sta= te 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 not= ed that solutions are either prophylactic or corrective.
<= span 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].

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'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?

> On the other hand= , protocols that use separate control and value transactions do not have th= is 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-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.

Do the Tunable-Penalty Factory pro= tocol have any "partition-throughput" limit due to a subsidiary r= eliance on the chain or the liveliness of the N counterparties ?

> If I underst= and 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.
>=C2=A0Consider 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.
> 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 A= lice believing
> that she has gained ownership over some of Bob's funds.
> Ho= wever, when the partitioning Update transaction that joins Alice's and = Bob's funds is put on-chain, Carol pretends to have been "wronged&= quot; by Bob and uses > the penalty mechanism to seize Bob's funds.<= /span>
> I= n 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


Le=C2=A0ven. 17 mars= 2023 =C3=A0=C2=A020:55, jlspc <= jlspc@protonmail.com> a =C3=A9crit=C2=A0:
= 
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. Thos=
e
> liveliness/interactivity requirements are increasing with the number o=
f
> users, as there are higher odds of *one* lazzy/buggy/offline user stal=
ling
> 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 sho=
wed
> the resort to delegated channel hosting solutions, relieving users fro=
m the
> liveliness requirement. While the trust trade-offs of those solutions =
are
> significant, they answer the reality of a world made of unreliable net=
works
> and mobile devices.

Agreed that signing updates and monitoring the blockchain both create alway=
s-online requirements that are not compatible with casual users' desire=
s.
I think it'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'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's safety paramet=
ers (such 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 min=
imal
> consumption of blockspace.

I would argue that we want a completely trust-free solution, if at all poss=
ible, 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.

> For the remainder of this post, only the pool use-case will be mention=
ed.
> Though, I think the observations/implications can be extended to facto=
ries
> 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-wor=
k
> accumulated valid chain of blocks. While reorg can happen, a UTXO cann=
ot 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 s=
tate and
> should be rejected.

> The double-spend issue is also solved in its own way in payment channe=
ls.
> If a transaction is published, of which the correctness has been revok=
ed
> w.r.t negotiated, private channel state, the wronged channel users mus=
t
> 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 =
based
> on a prophylactic one or a corrective security model.

Actually, there's a third class of solutions that are possible, namely =
ones that use separate control transactions and value transactions (where t=
he value transactions "spend", 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'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'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.

> E.g, let's say you have Alice, Bob, Caroll and Dave as pool partic=
ipants.
> Alice contacts Bob to form a first partition, then Caroll to form a se=
cond
> one, then Dave to form a last one. If she is successful in that
> equivocation trick, she can *triple*-spend her balance against any goo=
ds 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 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.

> I think that leveraging covenants a revocation mechanism could be atta=
ched
> on any equivocating branch of transactions, allowing in the above case=
 a
> single honest user to punish the publication. While a revocation mecha=
nism
> does not work in case of multiple defrauded users, I believe the exist=
ence
> 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 bli=
nded
> 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 =
pool
> users.

If I understand this correctly, I think a penalty mechanism that allows a &=
quot;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 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's funds.
However, when the partitioning Update transaction that joins Alice's an=
d Bob's funds is put on-chain, Carol pretends to have been "wronge=
d" 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.

Does that make sense?

Regards,
John

[1] Law, "Efficient Factories For Lightning Channels", available =
at https://github.com/JohnLaw2/ln-efficient-factories.



=20
=20
Sent with Proton Mail secure email.


--000000000000c453d405f9940cf7--