lightning-dev
Combined summary - Lightning, the death of BIP62, and Segregated Witness
Pierre is seeking resources on "segregated witness" and reaches out to the community for information.
Doug responds, stating that code for a hard fork version of segregated witness has been posted on GitHub by Pieter. There is no public soft fork code available. The discussion continues with individuals discussing methods to mitigate transaction malleability, including the use of sighash_noinput. There is debate over whether a soft fork or a hard fork would be the best approach, with Mark explaining the soft-fork plan and Greg explaining the hard-fork variant. Glenn notes the lack of information on Segregated Witness but suggests it could potentially be done with a soft fork. The Lightning Network, a proposed payment channel network for instant and low-cost micropayments, faces concerns regarding the security of transaction IDs (txids) due to their malleability. Tadge proposes the "sighash_noinput" functionality as a solution for reliable spending from unconfirmed transactions without txid malleability. However, there are ongoing discussions about the possibility of retracting BIP62, which addresses txid malleability vectors but is not helpful in the context of lightning channel creation. The proposal is to test malleability mitigation through a new "testnet-L" similar to testnet3. There are also debates between a soft-fork and a hard-fork variant, with the former involving changes to the scriptPubKey and scriptSig, and the latter involving placing the signatures in a parallel Merkle tree.In response to Pierre's query, a link to the ElementsProject repository on GitHub is shared, providing information about segregated witness. Additionally, Greg Maxwell's PDF presentation explains how segregated witness can increase the block size limit without increasing the risk of malleability attacks.BIP62, a Bitcoin Improvement Proposal, has been withdrawn in favor of pursuing normalized txid or segregated witness-based solutions. BIP62 was not sufficient to address all cases of malleability and would require additional rules for each new complex transaction, making it impractical. Moving forward, options include ignoring non-standard malleated transactions, adding a timeout to the anchor, proposing a reduced version of BIP62 that only protects specific transaction versions, or assuming that Segregated Witness (SW) fixes all malleability issues.Rusty Russell, the author of a lightning variant using non-experimental, in-planning BIPs, chooses to assume that Segregated Witness fixes all malleability issues. Pieter Wuille is working on a prototype of Segregated Witness, making it the preferred choice. However, this decision will have no immediate impact on lightning. If malleability support needs to be added later, it will be challenging due to its absence in various areas.