Topic: Malleability in a nutshell (Read 1644 times)

I can deal with mutated transactions, and I have no plans to shut down and wait for a fix. I agree that transactions are malleable today, and to run a bitcoin service today you will have to deal with that. I also agree that this is a difficult thing to fix in a good way. So it may take some time until we see a good solution. I never disagreed with any or that and I never said I, personally, had problems dealing with malleability.

What I have a problem with is all the people saying there is nothing wrong with bitcoin. Malleability is not a bug, it's just the way bitcoin works. And if it causes problems for you then the issue is your low IQ, not malleability. There are plenty of knowledgeable people saying these and similar things. In my opinion people acting this way can harm bitcoin more than malleability itself.

By the way, while we have these booby traps waiting to cause disasters for unsuspecting newbies; wasn't there someone working on a best practices guide/document for bitcoin?

Nobody competent and knowledgeable is saying mutable transaction ids are a good thing.  The trolling and clueless might but who cares.  The long term goal is immutable transaction ids but there are a lot of technical challenges.  It isn't going to be done overnight.  In the short term the way clients handle/report duplicate transactions will be improved, however the reality is that tx ids are mutable for the immediate future.  

So (and I say this tongue in cheek I have used your pool for years) you can either learn to handle mutable tx ids or you can shutdown for 6-12 months and at that point you likely will be able to rely on unconfirmed tx ids being immutable (but even then could be changed by the sender).  To make unconfirmed tx ids immutable will require a core change to the protocol.  There is still disagreement on what is the best way to achieve that goal.   Then extensive testing that will need to be done.  Miners will probably have to show support, clients will have to be soft upgraded, and a deadline put in place.  Just like adding P2SH support,  in a distributed decentralized consensus system there is no fast and easy way to make a breaking change.

So if you want to run a Bitcoin related business in 2014, mutable transaction ids are simply a reality, like the possibility of a double spend, or a 51% attack, or a DDOS attack, or a hacker breaching your hot wallet.  It is just another reality that makes all this a challenge.  I am pretty sure you understand this but for anyone else, the blockchain is the canonical reference of transactions.  Unconfirmed transactions are not guaranteed to be accepted by all nodes. The transaction ids of unconfirmed transaction being mutable are just a manifestation of that reality.

hmm so to do this? someone waits for some new unconfirmed transactions to show up.. then the send the same ones with some modified data into the network.. and that screws up the original tx's ??

i dont want to do it.. just curious...

Lol. I must admit, I did not do my research there. Apple actually responded exactly the same way the Bitcoin community is responding about malleability. I guess it's a normal human reaction. If someone says something negative about something you love then they are always wrong. Per definition.


You just chose B but wrote the text in a different way. The fact that the transaction identifier cannot identify a transaction is a bad thing. It doesn't matter what you call it. I'm pretty sure it is a bug and unintentional. But even if you call it a feature and say it is what Satoshi intended all along, that's all irrelevant.

bitcoind gives you a txid when you send coins. bitcoind has "gettransaction " to look up transactions. This being broken means that it is all there as a trap to cause you grief. And as a great tool for social engineering to steal your coins. What you are basically saying is that you want bitcoind to contain broken tools so that people will have problems and lose lots of money, and then you can later laugh at them and call them stupid. I don't think that's a good future for bitcoin.

Insisting that something bad is good - that's NOT how you build a good product.

Giving people a broken tool and calling them stupid when they struggle to use it - that's NOT how you promote a product.

Sorry, bad wording from my side. I meant: TxID isn't the way to verify transactions. Or to identify bitcoins (i.e. to which address they have or have not been sent).

And bitcoin ( the reference implementation ) itself is using the TxID to spend unconfirmed change.  
It is really sad how many people still don't get this.

You're saying the TxID shouldn't be used to identify transactions? The Transaction IDentifier shouldn't be used to identify transactions? 

Your argument might have a little merit if the TxID wasn't used by Bitcoin itself to identify transactions in the Merkle tree and inputs!

C) Sorry sir, you're using Bitcoin in the wrong way, 'ABC123' is not the way to identify your transaction. The actual inputs & outputs are (as in, addresses and amounts). But in order to make things as fool-proof as possible, it would be even better if we remove this malleability thing altogether, so sure, we'll remove that possibility. By the way, neither you nor Bitcoin are perfect, although be aware you're not blaming your own incorrect processing of transactions on Bitcoin supposedly being flawed. Thank you!

It has suddenly become a very different issue from the one mtgox mentioned. Lets say you have 10 btc in an output. You choose to spend 1 btc, 9 btc is sent back to you as change. Let's mark this as tx1. In tx2, you use that 9 btc output and spend it, this can be done without it ever being confirmed because there is not logical anyone would double spent their own change, this is how (all?) the majority of wallets work. Suddenly someone changes the signatures from tx1, changing it's hash, and that tx1_ gets into a block. Tx2 is invalidated since internally it refers to tx1's hash and not tx1_'s hash. This is why tx id has to be fixed in a way it always remains the same. Afaik, sipa already made some good progress on that front.

Bitcoin #9 has all the same weaknesses as Bitcoin and, of course, as Bitcoin #99, #999 etc.

Worst analogy ever.
http://www.engadget.com/2010/06/24/apple-responds-over-iphone-4-reception-issues-youre-holding-th/
http://www.cnn.com/2010/TECH/mobile/06/25/iphone.problems.response/
http://www.pcmag.com/article2/0,2817,2365705,00.asp
http://www.wired.com/gadgetlab/2010/06/iphone-4-holding-it-wrong/

Damn, are other people confirming it now? The Bitcoin deve team lets be honest, hasn't really ever had a challenge like this before, I think we need to make a thread to report the problems and test everything if it really is an issue.

This was my point. Many would disagree with you.

It's like the time when one of the iPhone models had antenna problems. Apple told people there was nothing wrong with the phone, the problem was actually the low IQ of the users, they didn't understand they needed to hold the phone a certain way for it to work. Oh, that's right, Apple never said that.

Sigh - or the idiots who ignored the issue that's been known for almost 2 years could have written their site code that does payouts to handle it so that it's not an issue ...

Discussed almost 2 years ago:
https://bitcointalksearch.org/topic/new-attack-vector-8392

Check the history - this page was added a year ago:
https://en.bitcoin.it/wiki/Transaction_Malleability

Yes, the bitcoin devs should fix it.
No, the idiots out their complaining about it can also fix it by not depending on txid, as they should have known for years ...

So mtgox was right, time to switch to litecoin?

Actually the solution from MtGox is relatively reasonable... there might still be some issues where parts of the actual transaction can be changed and its signature is still valid (as far as I understand it) but in total calling a checksum of the inputs "transaction id" instead of a checksum of the whole signed transaction might be a good thing to have.

All in all, bitcoind should return something that is guaranteed to be able to be found again after submitting a transaction to it, not a TXID that in the end does not mean what people apparently thought it means (known malleability or not).

Me: I'd like to send some coins.
bitcoind: Sent in transaction ABC123.
Me: How is transaction ABC123 doing? Any confirmations yet?
bitcoind: Are you making things up? There's no such transaction.
Me:

(The transaction did go through but is now called XYZ789)

Now you have two options:

A) Bitcoin isn't perfect, but we can make it better.

B) Bitcoin is perfect. You are the problem. YOU'RE STUPID!

I see many people already chose attitude B.

It's the wrong choice.