lightning-dev

Lightning, the death of BIP62, and Segregated Witness

Lightning, the death of BIP62, and Segregated Witness

Original Postby Tadge Dryja

Posted on: November 19, 2015 19:21 UTC

The discussion revolves around various methods to mitigate transaction malleability in Bitcoin, with a focus on the sighash_noinput method.

This method allows signers to exclude their input's transaction ID and index, and potentially even the pubkeyscript of the input. The resulting flexibility could allow for innovative constructions. However, it could also be dangerous if public keys are reused, especially in a multisig setting. The miners can decide which utxo outpoint is consumed assuming there are multiple candidates variant of the idea. The purpose of this discussion is to find ways to spend unconfirmed transactions reliably. Segregated witness is one such solution, but it requires a hard fork change. Sighash_noinput, on the other hand, could accomplish this without signing input txids, making it possible to modify the spending transaction while leaving counterparty signatures intact. To test the viability of this method, a new "testnet-L" similar to testnet3 will be set up. There is also an ongoing debate between a soft-fork and a hard-fork variant, with the former being the more straightforward option. The soft-fork plan involves having the scriptPubKey as just the 20-byte hash of the redeem script, while the actual scriptSig is contained in a separate Merkle tree. Meanwhile, the hard-fork variant opts to place the signatures in a parallel Merkle tree, allowing users to only download and validate the necessary information. Despite the lack of information on Segregated Witness, it is believed to be a simple concept that those working on it have not yet felt the need to write up.