Published on: 2023-04-18T03:38:57+00:00
The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the 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.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels.
Updated on: 2023-08-02T06:18:48.419381+00:00