[Lightning-dev] Lightning, the death of BIP62, and Segregated Witness

Rusty Russell rusty at rustcorp.com.au
Fri Nov 20 00:45:51 UTC 2015

Tadge Dryja <tadge at lightning.network> 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 :)


More information about the Lightning-dev mailing list