Inherited IDs [combined summary]



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

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


Summary:

John Law has made a proposal for an alternative to BIP-118 called Inherited IDs (IIDs). This proposal introduces a resettable "structural" transaction ID called an "iid" to each unspent transaction output (utxo). The purpose of the iid is to identify input transactions when signing, so that even if the details of the transaction change but not the structure, the signature remains valid. The proposal suggests tagging a segwit v2 output in the transaction to be used as the tagging method.The proposal also includes the concept of multisig factories, which involve using invalidation trees to update the split of funds between groups of participants. However, this approach introduces a tradeoff between the number of updates allowed, the time available to notice and correct a close, and the time it takes to extract funds from the factory in case of initial problems.The proposal compares IIDs with eltoo and concludes that special casing two-party channels with eltoo would make eltoo-2party and 2stage equally effective. When comparing eltoo-nparty and the multisig iid factories approach, it is shown that ms-iid would require log(n) transactions for the invalidation tree and log(n) time for the delays to prevent invalidated states from being published, while eltoo would only require one transaction and one block after noticing, plus a fixed csv delay.The paper discussing the IID concept also addresses its implementation, acknowledging that it would introduce additional complexity, but mostly just in terms of the additional complexity itself. It is noted that both iid and ANYPREVOUT would require changes to how signatures are evaluated and how applications using the new feature are written, but ANYPREVOUT does not require any additional changes beyond that. The author suggests that this construction could be simulated with ANYPREVOUT and does not allow for any new constructions that ANYPREVOUT wouldn't enable.The IID proposal is presented as a potential solution to the issues with BIP-118 and offers more scalable and usable Layer 2 protocols than those proposed in BIP-118. The proposal also mentions the support for channel factories that are more scalable and powerful than any previously-proposed channel factories, including eltoo factories. These channel factories, when combined with the 2Stage protocol, can create trust-free and watchtower-free channels, even with a large number of casual users.The paper provides options for how IIDs could be added to Bitcoin through a soft fork and invites feedback on the proposal. References to BIP-118, eltoo, Lightning Network, and other related works are included in the article. To engage in further discussion or respond to John's responses, it is recommended to use Github issue or similar means by accessing the provided Github repository link.


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