lightning-dev

Combined summary - Lightning, the death of BIP62, and Segregated Witness

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.

Discussion History

0
Rusty RussellOriginal Post
November 19, 2015 02:53 UTC
1
November 19, 2015 08:13 UTC
2
November 19, 2015 12:29 UTC
3
November 19, 2015 12:33 UTC
4
November 19, 2015 15:28 UTC
5
November 19, 2015 15:31 UTC
6
November 19, 2015 16:04 UTC
7
November 19, 2015 17:56 UTC
8
November 19, 2015 19:12 UTC
9
November 19, 2015 19:15 UTC
10
November 19, 2015 19:21 UTC
11
November 19, 2015 19:31 UTC
12
November 19, 2015 19:38 UTC
13
November 19, 2015 19:40 UTC
14
November 19, 2015 19:48 UTC
15
November 19, 2015 20:07 UTC
16
November 20, 2015 00:45 UTC
17
November 22, 2015 20:24 UTC