Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin



Summary:

In an email response to Anthony Towns, John P. Newell addresses some misunderstandings in his paper on inherited IDs (IIDs). He explains that despite the use of an operator in the "timeout trees", "update-forest" and "challenge-and-response" factory protocols, the operator is not a trusted party and cannot take funds or prevent others from obtaining the funds that are due to them. Newell also argues that IIDs cannot be simulated with anyprevout and provides an example of how IIDs can provide a trust-free means for Alice to transfer funds to Bob without putting F2 and S on-chain. Newell believes that IIDs provide functionality that anyprevout does not provide, allowing for a single on-chain transaction to transfer ownership of thousands or millions of channels in a trust-free manner. He hopes that clearing up these misunderstandings will pique Towns' interest in reading about the "timeout trees", "update-forest" and "challenge-and-response" protocols in more detail. Newell's remaining comments are minor and include points on the worst-case delay for eltoo-2party vs. 2Stage, the advantage of 2Stage's elimination of watchtowers, and a correction regarding the new address type for floating transactions mentioned in the paper. Overall, the paper shows that IIDs can be used to eliminate watchtowers for one or both parties in a two-party channel (2Stage), create factories that allow very large numbers of new users to obtain bitcoin in a watchtower-free and trust-free manner (timeout trees), support trust-free factories with unbounded numbers of parties (and channels) that allow the channels to be bought and sold by anyone, including parties not originally in the factory, with a single on-chain transaction, and achieve these results while using a more constrained, and thus safer, change to Bitcoin than the support for floating transactions.


Updated on: 2023-06-03T05:54:04.086699+00:00