TX Malleability is NOT A BUG: fix not needed

[Hyena]

I've always thought TX malleability is an embarrassing bug and should be fixed ASAP. I thought this because I had no practical experience in dealing with this aspect of TX hashes. Today I had to deliberately adjust my code so that it wouldn't break due to double spends and duplicate TXs with different hashes. By doing this I came to a realization that TX malleability is not a bug but a feature and that developers should absolutely consider the possibility of seeing the same TX essentials with different hashes on the network. Here's why...

Double spending is an issue for those who accept 0 confirmation TXs. It will never be fixed because this issue is intrinsic to Bitcoin. Turns out that TXs affected by TX-malleability are basically plain old double spends. If you accept 0 confirmation TXs then you must deal with double-spending attempts. If you do that then TX malleability is not going to be an issue for you to begin with because duplicate TXs with same hashes are basically double spends.

Having said this, I am confused why Core devs even bothered to "fix" TX malleability if it's not even a bug. I think people should be made aware of this discovery. There is no such thing as TX malleability vulnerability because it is just a special case of double spending.

 

[AdrianX]

This thread should be merged with the previous one you opened.

there are many reasons to keep and remove transaction malleability, this topic need more economic analysts before it can be fully understood.

it's not black and white, https://www.reddit.com/r/btc/comments/5ymr4a/bitclub_is_unintentionally_launching_a/

 

[freetrader]

>I am confused why Core devs even bothered to "fix" TX malleability if it's not even a bug

Can't speak for them, but the arguments that it's needed for HTLC and therefore efficient Lightning do sound plausible to me. Haven't spent time delving into the specifics. Maybe @achow101 or others could help on this topic.

 

[satoshis_sockpuppet]

@freetrader
I heard conflicting statements from LN/Core devs about whether it's needed or not for HTLC. IIRC Greg and Timon claimed that it is absolutely not necessary while the LN devs sounded a bit desperate.

Actually I think, that it's a good reason to think about it very long. Do we actually want to allow such a disconnected "network", a layer without much interaction with the blockchain?

 

[AdrianX]

@satoshis_sockpuppet how Gred described it to me (in his cryptic way) is if you have malleable transactions you can still deploy LN, the trade off is you need to have a full node on each end of the LN channel, so it's a lot less scalable and the benefits restricted to those who run full nodes.

It sounds like a good place to start, the problem is that's not how it is currently designed so its a big setback for LN developers.

 

[satoshis_sockpuppet]

Wait what??
If that's how it is, core should fight against any malleability fix.
They are obsessed with everybody and his grandma running a full node. According to luke, you are not using Bitcoin if you are not running a full node.

It's a feature, not a bug.

 

[AdrianX]

I'm speaking from my understanding, - I can't validate the code so I am limited to understanding what developers tell me, and transaction malleability does prevent many user-cases for smart contracts typical those LN will depend on, while transaction malleability could be a bug I see it as a feature.

Core cant fight against any malleability fix, Core is a Hydra, it has no one specific goal but to stay in control of the "centralized or decentralized" process by which changes are made to the reference bitcoin client.

 

[Joel Dalais]

I agree with Hyena.

Malleability makes LN basically impossible (no business, or person would be sanely use LN without a malleability 'fix'). As it makes revocable transactions very dodgy (easy to falsify). And allegedly it also fucks up sidechains with a similar issue (though I don't know the issue so well with sidechains), something along the lines of 'sidechains can't confirm whatever they've been doing if malleability exists/is used'.

Which means LN and sidechains are extremely dependent upon SegWit. Having code extremely reliant on bad code makes that code (ln/sidechains) bad code in my eyes. It's like building a beautiful house in a field of permanent manure.

As Hyena says, any platform (or person) reliant on 0 confirmation (should) take malleability into account and not only rely on transaction hash.

I think people will (in the future) find a use for malleability.

As sockpuppet says,

It's a feature, not a bug.