[weavejester]

I feel I need to clarify some of your points, as they're a little misleading.

> Don't worry, they can't change after about an hour. Well, probably. It would be pretty expensive for an attacker to change them after an hour.

You use the term "pretty expensive" here without qualifying it. Changing a transaction encoded in the blockchain would require outpacing the current hashrate of the bitcoin network. That would require a significant hardware investment, on the order of tens of millions of dollars.

> Well you're already downloading every message ever. Just scan through for one which matches the same from number, to number, and message contents.

You make it sound as if you wouldn't have to do this if you had the transaction hash. You still need to iterate through the transactions regardless. It's just a question of whether you use the transaction hash, or derive your own from the parts of the transaction that are immutable.

Let's make your example a touch more realistic:

Me: "Hey Twilio I created an SMS message but when I try to query it for the results it 404s."

Them: "Has the message been delivered?"

Me: "I don't think so. I'm querying it shortly after I create it."

Them: "How are you querying it?"

Me: "With the message hash."

Them: "Ah, that explains it, then. A pending message may be changed before its delivered, altering the hash. This makes the hash unsuitable for identifying pending messages."

Me: "So how do I identify messages?"

Them: "Ideally you wait until they're delivered, but if you really need to check for pending messages, you can search through them looking for a message that matches on to, from and content."

Me: "That kinda sucks."

Them: "We know, but it's a difficult issue to fix. It's documented in our wiki."

Me: "What if I don't read your wiki, or follow your mailing list?"

Them: "Then should you really be running an exchange handling millions of dollars of transactions?"

Me: "... Good point."

[makomk]

There's one problem with this, at least if you're using the official client: the Bitcoin APIs telling you what transactions you've sent and received don't tell you where the transactions came from, which is what you need to know in order to match them. Indeed, the only way it provides to uniquely identify the transaction is the transaction ID, which can change unexpectedly.

[ogreyonder]

MtGox should absolutely have known about this issue. Everyone building anything related to BTC should know not to make assumptions about the protocol, and to treat every input as hostile.

You'd think they'd have at least one guy dedicated to nothing but breaking their software. They make my salary every day with transaction fees (well, maybe until recently) so you can't say they're unable to afford it.

Edit: Rereading this, it sounds more accusatory than I intended. I think your clarification was perfect, but at the same time that MtGox is at fault.

[patrickaljord]

Sorry to ask that but if to, from and content can't be changed, why not make the transaction id a hash of these three element using any deterministic algorithm such as sha1 etc?

[gojomo]

That is the obvious implementation workaround, and with such a 'canonical ID' software can do its own malleability-resistant transaction-tracking.

However, the hash over the malleable part is still protocol-significant: which exact incarnation of the isomorphic transaction is being passed around or cemented into blocks. So this new stable ID would be in addition to the older one, and might not even be necessarily expressed inside the protocol: it might just be a convention, and could vary across independent implementations.

The MTGox statement was a plea for the community to converge on such an consensus identifier before MtGox commits to a local fix. But that's not strictly technically necessary, so their stance looks like a strategy for blame-shifting and further delay. The Bitcoin core people don't like to rush into things.

[weavejester]

As I understand it, this is essentially the fix the exchanges need to implement. The exchange can generate a hash on the address, outputs and amount, and use that to confirm whether or not the money has been sent.

[Anderkent]

However they still need the full transaction hash to reference any outputs from it, as these are identified by the (txhash, index) tuple.

[codexon]

> "Then should you really be running an exchange handling millions of dollars of transactions?"

So what happens to people who aren't running an exchange handling millions of dollars of transactions? It doesn't matter if they get screwed by this flaw?

I read much of the wiki and never encountered any reference to transactional malleability.

[weavejester]

Presumably those people aren't writing their own custom Bitcoin client libraries.

[codexon]

So if you want to set up your own shop you are stuck doing transactions by hand or you have to use a 3rd party like bitpay?

Lol.

The point of bitcoin is being able to do it yourself and not rely on centralized institutions.

[psc]

Well don't forget, there's a standard client that works fine. These exchanges were writing their own custom clients, but that's probably not something a one man shop would have to do. And if you have to modify the client, you should definitely be reading the wiki. And test it extensively when you're running million dollar exchanges.

[Anderkent]

Not quite fine: http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ...

The bitcoin reference client seems to get confused by this. It seems to allow additional spending of the unconfirmed change addresses and forms a chain of double spent transactions. The bitcoin balance as reported by 'getbalance' also becomes unreliable as it computes the balance incorrectly. Eventually the wallet stops working.