Inherited IDs [combined summary]



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

Published on: 2021-09-24T07:27:03+00:00


Summary:

John Law has shared his responses regarding btc-iids on his Github repository. He suggests responding to him through Github issue or similar platforms. The link to his Github repo is https://github.com/JohnLaw2/btc-iids.In an alternative proposal to BIP-118, John Law introduces Inherited IDs (IIDs), a new method that involves adding a resettable "structural" transaction ID called an "iid" to each UTXO. With IIDs, input transactions can be identified when signing, allowing for valid signatures even if the transaction details change but not its structure. The proposal also includes a tagging system using segwit v2 outputs to identify tagged outputs.The proposal also presents a protocol called "2stage" that enables fast closing of channels with two participants. However, this protocol is not applicable to more than two participants due to the risk of collusion. To address this limitation, invalidation trees are introduced to update the split of funds between groups of participants in channel factories. This introduces a tradeoff between the number of updates allowed, the time available to notice and correct a proposed close, and the initial extraction time for funds from the factory. A hierarchy of update transactions is proposed to reduce delays significantly.The IID proposal is compared to eltoo and statechains, with a focus on two-party channels. In uncooperative cases, the multisig iid factories approach requires log(n) transactions for the invalidation tree and log(n) time for delay to prevent the publication of invalidated states. On the other hand, eltoo requires one transaction and one block after the user notices, along with a fixed CSV delay. Lightning networks face challenges with layered commitments in both the delays while waiting for potential rejection in 2stage and the invalidation tree delays in factory construction.Implementing the "iid" concept would necessitate adding information to the UTXO database, resulting in a potential 1.4GB increase. However, iid transactions are expected to be infrequent and short-lived. The proposal is also compared to using ANYPREVOUT, which simulates the construction of IIDs without requiring additional changes beyond those needed for introducing ANYPREVOUT.In summary, the Inherited IDs (IIDs) proposal by John Law offers an alternative to BIP-118, introducing a new method that adds resettable "iid" transaction IDs to UTXOs. The proposal includes a tagging system and a protocol called "2stage" for fast channel closing. It also introduces invalidation trees for channel factories and suggests a hierarchy of update transactions to reduce delays. Implementing IIDs would require adding information to the UTXO database, potentially increasing its size. The proposal is compared to eltoo and statechains, with acknowledgments given to Ruben Somsen and Jeremy Rubin for their helpful comments and Bob McElrath for his original brainstorming that led to the creation of the IID concept. References to related resources such as BIP-118, eltoo, Bitcoin Lightning Network, and scalable funding of Bitcoin micropayment channel networks are provided.


Updated on: 2023-08-02T04:51:01.569843+00:00