Conjectures on solving the high interactivity issue in payment pools and channel factories

Summary:

The discussion in this email thread revolves around 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. While 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. The author further suggests that we need a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace. However, such solutions should be completely trust-free if possible, while respecting users' actual availability. The email also discusses the double-spend issue and highlights that it is already addressed on the Bitcoin base-layer due to nodes consensus convergence on the most-proof-of-work accumulated valid chain of blocks. This security model can be said to be prophylactic, and an invalid block cannot be applied to a node's state and should be rejected. Similarly, payment channels offer a corrective security model where incorrect transactions put on-chain can be revoked by the wronged channel users.The email also proposes a third class of solutions that use separate control transactions and value transactions. An example of such a solution is the Tunable-Penalty Factory protocol, which is a multi-party protocol in which every dishonest party is penalized, and there is no economic disequilibrium.Furthermore, the email discusses the limitations of correction as a security model in the context of multi-party, which are producing an economic disequilibrium. The author suggests that leveraging covenants, a revocation mechanism could be attached to any equivocating branch of transactions, allowing for a single honest user to punish the publication. Finally, the email discusses the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds and how it can be exploited by a malicious coalition.

Updated on: 2023-06-15T19:57:38.818535+00:00