Nucleus: Capital-efficient multipeer Lightning payment channels



Summary:

In an email sent by Atomic Mr Nuclear, he expresses his gratitude for the work done on multiparty channel design. He highlights two points from a paper and questions their feasibility. The first point states that any construction relying on an honest majority is not safe when the majority consists of untrusted peers. In the context of a multiparty channel with random peers, Alice cannot accept payments safely without signatures from all other participants in the channel. This requirement for "full state updates" seems cumbersome and raises concerns about the practicality of the proposed design.The second point addresses the exclusion of uncooperative peers, which necessitates three confirmed onchain transactions. One of these transactions must have one output for each original participant, while another requires one input for every cooperative participant. Atomic Mr Nuclear finds this requirement excessive in terms of both cost and speed. He believes that such a process would be too expensive and slow to serve as a viable alternative to Lightning.Taking these two points into consideration, Atomic Mr Nuclear concludes that the proposal's reliance on "partial state updates" is not feasible for trustless payments. Without partial updates, the proposal mandates an expensive onchain process whenever even one participant becomes uncooperative. In Atomic Mr Nuclear's opinion, this approach appears inferior to existing designs for channel factories and multiparty channels mentioned in the paper.Atomic Mr Nuclear appreciates the effort put into the paper and expresses interest in learning more if there are any overlooked aspects. Furthermore, he encourages the author to review the work posted on the Lightning-Dev mailing list by John Law over the past year, as it may provide inspiring solutions to similar problems. Atomic Mr Nuclear provides a link to a collection and summary of John Law's work for reference [1].


Updated on: 2023-08-26T01:48:11.945423+00:00