From rusty at rustcorp.com.au Fri Nov 20 00:45:51 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 20 Nov 2015 11:15:51 +1030 Subject: [Lightning-dev] Lightning, the death of BIP62, and Segregated Witness In-Reply-To: References: <87si42n1ir.fsf@rustcorp.com.au> <1447920788.2353.12.camel@ultimatestunts.nl> Message-ID: <87a8q9mrb4.fsf@rustcorp.com.au> Tadge Dryja writes: > 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. Yeah, that's why the deployable lightning model used single-sided funding (the escape tx model also works). > 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. The excitement is because the proposal is to soft-forked it in. Seems like it might work, but I'll have to see how ugly it is. > 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 was trying to a new OP_CHECKSIG2, because I'm fairly sure we're going to take years to winnow down the set of features. I expect it will logjam on "new sig flags" "schnorr!" "scriptable signature parts" etc... > 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!) Welcome :) Cheers, Rusty.