jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-17 🗒️ Summary of this message: The post ...
📅 Original date posted:2023-03-17
🗒️ Summary of this message: The post discusses the liveliness/interactivity requirements of updating balance distribution in pools and the design of Lightning Network for always-online participants. The author suggests a trust-minimized solution for non-interactive, off-chain updates of the pool/factory. The post also discusses the double-spend issue and proposes solutions based on prophylactic or corrective security models.
📝 Original message: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 stalling
> 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 showed
> the resort to delegated channel hosting solutions, relieving users from the
> liveliness requirement. While the trust trade-offs of those solutions are
> significant, they answer the reality of a world made of unreliable networks
> and mobile devices.
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).
> Ideally, I think we would like a trust-minimized solution enabling
> non-interactive, off-chain updates of the pool/factory, with no or minimal
> consumption of blockspace.
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.
> For the remainder of this post, only the pool use-case will be mentioned.
> Though, I think the observations/implications can be extended to factories
> 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 cannot 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 channels.
> If a transaction is published, of which the correctness has been revoked
> 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 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 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.
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Alice contacts Bob to form a first partition, then Caroll to form a second
> one, then Dave to form a last one. If she is successful in that
> equivocation trick, she can *triple*-spend her balance against any goods 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 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.
> I think that leveraging covenants a revocation mechanism could be attached
> on any equivocating branch of transactions, allowing in the above case a
> single honest user to punish the publication. While a revocation mechanism
> does not work in case of multiple defrauded users, I believe the existence
> 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 blinded
> 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 "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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230317/04bc8655/attachment.html>;
🗒️ Summary of this message: The post discusses the liveliness/interactivity requirements of updating balance distribution in pools and the design of Lightning Network for always-online participants. The author suggests a trust-minimized solution for non-interactive, off-chain updates of the pool/factory. The post also discusses the double-spend issue and proposes solutions based on prophylactic or corrective security models.
📝 Original message: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 stalling
> 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 showed
> the resort to delegated channel hosting solutions, relieving users from the
> liveliness requirement. While the trust trade-offs of those solutions are
> significant, they answer the reality of a world made of unreliable networks
> and mobile devices.
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).
> Ideally, I think we would like a trust-minimized solution enabling
> non-interactive, off-chain updates of the pool/factory, with no or minimal
> consumption of blockspace.
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.
> For the remainder of this post, only the pool use-case will be mentioned.
> Though, I think the observations/implications can be extended to factories
> 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 cannot 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 channels.
> If a transaction is published, of which the correctness has been revoked
> 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 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 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.
> E.g, let's say you have Alice, Bob, Caroll and Dave as pool participants.
> Alice contacts Bob to form a first partition, then Caroll to form a second
> one, then Dave to form a last one. If she is successful in that
> equivocation trick, she can *triple*-spend her balance against any goods 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 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.
> I think that leveraging covenants a revocation mechanism could be attached
> on any equivocating branch of transactions, allowing in the above case a
> single honest user to punish the publication. While a revocation mechanism
> does not work in case of multiple defrauded users, I believe the existence
> 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 blinded
> 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 "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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230317/04bc8655/attachment.html>;