Transaction malleability: MalFix, SegWit, SIGHASH_NOINPUT, SIGHASH_SPENDANYOUTPUT, etc

Is anyone still interested in an all-encompassing solution to third-party transaction malleability for Bitcoin Cash?

Some background reading:

As I understand it, the primary expected benefit of some large-scale “malleability fix” would be:

To enable applications that rely on off-chain unconfirmed transaction chaining.

So: is malleability solved?

BCH has already rolled out a number of upgrades addressing malleability in various places. Are we done? Are there any other “use-case breaking” sources of malleability we should fix?

1 Like

I wanted to bring up this discussion because a transaction malleability solution could also replace half of the PMv3 proposal:

If anyone is interested in this topic, we should adjust that spec sooner rather than later, since it’s unlikely we’ll want to implement both hashed witnesses and a “malleability fix”.

My understanding was that 3rd party malleability was completely fixed over a range of BCH upgrades, but I could certainly be wrong and it’s a good question.

No more third-party malleability : By completing the BIP62 malleability fixes, it will be possible to make P2PKH-spending transactions that cannot be malleated by any third party (miners, relay nodes, etc.). This removes the need for OP_CHECKLOCKTIMEVERIFY timeout clauses. We can also engineer smart contracts to be immune from malleability.

From BIP62 & Schnorr by @markblundeberg

2 Likes

Third-party malleability has been eliminated by a sequence of network upgrades. See here for an overview.

Second-party malleability can be avoided by using Schnorr signatures.

So there is essentially no more malleability to be fixed. Compared to SegWit, the only disadvantage I am aware of is that you cannot sign a child transaction before the parent transaction is signed. But that is a different problem than malleability.

1 Like

So there is essentially no more malleability to be fixed.

That’s my impression too – it’s something contract authors (or compilers) will always have to review to avoid griefing, but I think pretty much any unlocking script can be validated-enough to remove malleability vectors.

Compared to SegWit, the only disadvantage I am aware of is that you cannot sign a child transaction before the parent transaction is signed.

And even that use case is easily solved with covenants. Not only do you not need to know the parent transaction ID before signing, you can pre-sign dozens of CashChannel authorizations even if your CashChannel doesn’t yet have a high enough balance to pay them all. The receiver can simple process the authorizations whenever you’ve topped it up (and the proper payment time has been reached).

1 Like