Contrary to Mt.Gox’s Statement, Bitcoin is not at fault - Gavin Andresen 10/2/14

[justusranvier]

The problem is, if I'm understanding it reduced to its simplest level, relying on transaction information that is NOT YET ON THE BLOCKCHAIN.  It kind of boggles my mind anyone could base any reliance for verifying deposits to a system on anything whatsoever not on the blockchain, even for tracking purposes.

Not only relying on information that is not yet in the blockchain, but also not paying attention to relevant information in the blockchain because you think you preliminary information is canonical.

[1714846569]

1714846569

[1714846569]

1714846569

[1714846569]

1714846569

[1714846569]

1714846569

[1714846569]

1714846569

[1714846569]

1714846569

[bitsaber]

In 2010.  If I recall correctly 2010 is before 2011.

So the transaction malleability problem was created in 2010 and reported in 2011.

[justusranvier]

So the transaction malleability problem was created in 2010 and reported in 2011.

No.

Transactions have always been malleable prior to being included in a block. This wasn't really apparent until 2011.

There's nothing wrong with txid, the only problem is inaccurately assuming that it's immutable, and especially not noticing when changes to the blockchain affect your balance in ways you weren't expecting.

[bitsaber]

Transactions have always been malleable prior to being included in a block. This wasn't really apparent until 2011.

Maybe they were, but this certainly didn't help:

I'm proposing one small change to Bitcoin's JSON-RPC api:  return a transaction ID when Bitcoins are successfully sent.

Why?  Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes.  The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.

[justusranvier]

I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes.

That's the part Mt Gox missed.

In order to do this you've actually got to pay attention to the network to make sure that what you think it's going to do is actually what it does.

They fucked up by assuming that if the txid they sent didn't make it into a block, then no other txid could have spent those coins so they didn't bother checking the blockchain to make sure that was the case.

[darkmule]

Transactions have always been malleable prior to being included in a block. This wasn't really apparent until 2011.

Maybe they were, but this certainly didn't help:

I'm proposing one small change to Bitcoin's JSON-RPC api:  return a transaction ID when Bitcoins are successfully sent.

Why?  Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes.  The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.

Where's the part of that where he says "then, after returning the txid, depend on it as a permanent identification proving a deposit into an exchange?"  I'm not seeing that.  There's really nothing more fundamental to Bitcoin than the blockchain, and that if something is on it, you can trust it forevermore after whatever number of confirms makes you comfortable.  If it isn't, you can't, even if it might have some temporary use in the interim.

[bitsaber]

They fucked up by assuming that if the txid they sent didn't make it into a block, then no other txid could have spent those coins so they didn't bother checking the blockchain to make sure that was the case.

Wasn't that a reasonable conclusion from sendtoaddress being updated to return a txid?

[darkmule]

They fucked up by assuming that if the txid they sent didn't make it into a block, then no other txid could have spent those coins so they didn't bother checking the blockchain to make sure that was the case.

Wasn't that a reasonable conclusion from sendtoaddress being updated to return a txid?

Not when they had been personally told otherwise.

[justusranvier]

Wasn't that a reasonable conclusion from sendtoaddress being updated to return a txid?

No.

Only the blockchain is canonical.

It's been that way since day 1. If you're implementing a wallet you already have to account for the fact that the blockchain can change during a reorg, so you should already be constantly checking what you think you know according to what is actually true.

There's no excuse for not noticing that outputs you thought hadn't been spent yet have been included as inputs to a transaction in the blockchain just because you weren't expecting that txid.

[gbgamer]

I agree with the statement, however, I do believe this is something that should get addressed sooner rather than later.  been set aside too for too long

[Syke]

I'm not saying Mt. Gox are the good guys here (they clearly screwed up), but shouldn't Gavin Andresen have accepted some responsibility?

How could he? The flaw is in MtGox's closed-source implementation and customer service policies. Not Bitcoin.

[bitsaber]

OK, let's try a little experiment.

Suppose you're in charge of the London Underground, and you're having the slight annoyance of an occasional passenger being run over by a train.

You could:

1. play a recording saying "Mind the gap" every ten seconds or
2. put a wall with sliding doors between the platform and the train.

Which one would you choose?

[wolongong]

Well, then, let's get some broad consensus and running code out of the door to find your tx back in the chain reliably if that's all we need.

[DeathAndTaxes]

I'm not saying Mt. Gox are the good guys here (they clearly screwed up), but shouldn't Gavin Andresen have accepted some responsibility?

How could he? The flaw is in MtGox's closed-source implementation and customer service policies. Not Bitcoin.

It does show the power of open source.  Had MtGox's "Gox Special Wallet" been an open source project it is very likely someone would have caught the numerous implementation errors.  Nobody knew except MtGox how incredibly flawed their wallet was, and they didn't have the competence to realize it was flawed.  I am not just talking about the tx hash malleability issue but a host of other flaws as well.

[Syke]

OK, let's try a little experiment.

Suppose you're in charge of the London Underground, and you're having the slight annoyance of an occasional passenger being run over by a train.

You could:

1. play a recording saying "Mind the gap" every ten seconds or
2. put a wall with sliding doors between the platform and the train.

Which one would you choose?

You're not listening. MtGox built their own subway with flawed doors. Only MtGox can fix those doors.

[smoothie]

I'm not saying Mt. Gox are the good guys here (they clearly screwed up), but shouldn't Gavin Andresen have accepted some responsibility?

Responsibility for MtGox choosing to willingly donate coins to people asking for them to their support team?
Let me think....
Err, no.

Yeah lol Gavin should be held responsible for something he didn't do.

Good luck with that. 

[razorfishsl]

OK, let's try a little experiment.

Suppose you're in charge of the London Underground, and you're having the slight annoyance of an occasional passenger being run over by a train.

You could:

1. play a recording saying "Mind the gap" every ten seconds or
2. put a wall with sliding doors between the platform and the train.

Which one would you choose?

Both…. same as they do in HK,
 because there is always some Deaf guy who cannot hear the announcements… then they have people standing by the walls to stop the mainlanders trying to force the doors open, and Security for the people like (gox) who flatly refuse to follow the rules

[bitsaber]

You're not listening. MtGox built their own subway with flawed doors. Only MtGox can fix those doors.

Oh, I am listening. The problem isn't with the doors (as far as we know). Had it been the doors, a wall wouldn't help.

[Syke]

Oh, I am listening. The problem isn't with the doors (as far as we know). Had it been the doors, a wall wouldn't help.

Yes, that is the problem. Gox built their doors out of rice paper. People are walking right through them.

Gox has a flawed implementation. They allow customers who have already received a withdrawal to claim they didn't, and Gox will send them a new withdrawal!

[whitenight639]

Can someone explain how the malleability problem is manifest?

I thought Gox like other waited for 3x confirmations in the Blockchain before acknowledging transfers into or out of a Gox account?