Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Tadge Dryja <tadge at ...
📅 Original date posted:2015-11-19
📝 Original message:
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 :)
Cheers,
Rusty.
📝 Original message:
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 :)
Cheers,
Rusty.