Inherited IDs [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2021-10-10T22:03:38+00:00


Summary:

John P. Newell responds to Anthony Towns' concerns and clarifies misunderstandings in his paper on inherited IDs (IIDs). He emphasizes that despite the operator's role in the "timeout trees", "update-forest", and "challenge-and-response" factory protocols, the operator is not a trusted party and cannot manipulate funds or impede others from accessing their rightful funds. Newell also asserts that IIDs cannot be replicated with anyprevout and provides an example illustrating how IIDs enable trust-free fund transfers between Alice and Bob without involving F2 and S on-chain.Newell contends that IIDs offer functionality beyond what anyprevout can provide, allowing for a single on-chain transaction to transfer ownership of numerous channels, even in the millions, in a trust-free manner. He hopes that addressing these misunderstandings will encourage Towns to delve into the details of the "timeout trees", "update-forest", and "challenge-and-response" protocols. Additionally, Newell includes minor comments about the worst-case delay comparison between eltoo-2party and 2Stage, the advantage of 2Stage in eliminating watchtowers, and a correction regarding the new address type for floating transactions mentioned in the paper.Overall, the paper demonstrates that IIDs can eliminate watchtowers for one or both parties involved in a two-party channel (2Stage), establish factories that allow a large number of users to acquire Bitcoin in a watchtower-free and trust-free manner (timeout trees), support trust-free factories with unlimited participants and channels, enabling their sale and purchase by anyone, including non-original parties, through a single on-chain transaction. Importantly, these achievements are accomplished by introducing safer changes to Bitcoin compared to the support for floating transactions.In a recent email exchange, ZmnSCPxj raises concerns about the necessity of an on-chain transaction to update the set of channels created by a factory. ZmnSCPxj argues that this undermines the purpose of having a factory, which is to facilitate changes in the channel set without requiring an on-chain transaction. Instead, ZmnSCPxj suggests that such factories can already be created without Taproot. The funding transaction output would pay to a simple n-of-n setup, which is then spent by an off-chain transaction dividing the funds among the current channels. To modify the channel set, participants create an alternate transaction, sign it without broadcasting, and subsequently sign and broadcast it to effectuate the update via an on-chain transaction. This approach functions without modifications to Bitcoin or even the presence of Taproot, although witness size may become substantial when dealing with large N values in the absence of Taproot. Essentially, this approach represents a "no updates" factory that bypasses the need for a closing transaction by initiating a new factory.


Updated on: 2023-07-31T23:48:22.406695+00:00