From tadge at lightning.network Thu Nov 19 19:40:12 2015 From: tadge at lightning.network (Tadge Dryja) Date: Thu, 19 Nov 2015 11:40:12 -0800 Subject: [Lightning-dev] Lightning, the death of BIP62, and Segregated Witness In-Reply-To: <564E2546.3060908@mattcorallo.com> References: <87si42n1ir.fsf@rustcorp.com.au> <1447920788.2353.12.camel@ultimatestunts.nl> <564E2546.3060908@mattcorallo.com> Message-ID: Cool, I had not seen that, I'll take a look. I'm all for anything that allows reliable spends from unconfirmed txs. If SW can get in easier, sounds good. -Tadge On Thu, Nov 19, 2015 at 11:38 AM, Matt Corallo wrote: > Nope, Luke came up with a way to do it in a soft-fork. > > On 11/19/15 19:12, Tadge Dryja wrote: > >> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses >> many vectors for txid malleability, but maybe there are more. And more >> importantly, it addresses 3rd party malleability. It's not helpful in >> the context of lightning channel creation because ECDSA sigs are >> inherently malleable. You can always re-sign the same message with a >> different k-value and get a different signature. >> >> The functionality that's needed is to be able to reliably spend from >> unconfirmed transactions. Segregated witness can accomplish that, but >> it quite a large hard-fork change. sighash_noinput can also accomplish >> that: as input txids are not signed, if they change, the spending >> transaction can be modified while leaving counterparty signatures intact. >> >> I'm hoping to start a new "testnet-L" similar to testnet3, with this >> sighash type so that we can test malleability mitigation out. >> >> (Oh also, hi mailing list, sorry I have not posted till now! But I will >> start posting!) >> >> -Tadge >> >> On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach > > wrote: >> >> The basic idea of the soft-fork plan is very simple --- have the >> scriptPubKey be just the 20-byte hash of the redeem script. The >> scriptSig of the spending input is empty. The actual scriptSig, with >> the redeem script and signatures, is contained in a separate Merkle >> tree committed to elsewhere in the block (e.g. in the last output of >> the coinbase, or the last output of the last transaction). >> >> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders > > wrote: >> >> The hardfork variant is quite simple, if I understood it >> correctly. You just stick the signatures in another parallel >> merkle tree. So if you don't want to validate signatures, just >> don't download them, and validate everything else. TXIDs don't >> use the signature at all. Nothing to malleate, AFAIK. Not sure >> what the softfork plan is, but it will be a talk at Scaling >> Bitcoin HK. >> >> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD >> > wrote: >> >> >> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com >> > > wrote: >> >> Hi Pierre >> >> you could start here >> >> >> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness >> >> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf >> https://github.com/ElementsProject/elements >> >> >> There was a brief blip on Reddit: >> >> >> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh >> >> Its weird how little information there is on Segregated >> Witness. I'm guessing its a simple concept and those >> working on it (sipa / gmaxwell) haven't felt the need to >> write it up. >> >> That it "apparently" can be done with a soft fork similar to >> P2SH is good news... I guess... >> >> >> -- >> Glenn H. Tarbox, PhD >> =]|[= >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: