Pages:
Author

Topic: Contrary to Mt.Gox’s Statement, Bitcoin is not at fault - Gavin Andresen 10/2/14 - page 4. (Read 13161 times)

sr. member
Activity: 322
Merit: 252
I wonder if all Mt. GOXXX threads will be moved to service discussion?  Hmmm... maybe just mine...
full member
Activity: 157
Merit: 100
Gox creates a withdrawal and makes note of the TXID. Then, before it is included in a block, someone else changes the transaction such that only the TXID changes, but the transaction is still the same. When the new TXID gets included in the blockchain, the customer who requested the withdrawal claims they never received it. But they actually did! Gox looks up the old TXID and doesn't find it, so they create a whole new transaction and send another withdrawal to the customer. The customer has now been paid twice!!! This is solely Gox's problem because they do not correctly track transactions.

To clarify further: in an transaction, only the inputs, the outputs and the amount are signed. The TXID is -not- signed, and thus can be changed by anybody while keeping the transaction valid. It is -not- a bug, it's a design choice. The Bitcoin protocol never stated that the TXID was to be unchangeable, and thus nobody should have expected that in their software.

One can uniquely track transactions otherwise. Even if the TXID is changes, the inputs are not. Thus one can know if a transaction went trough by checking if a given input has been spent according to the blockchain.
legendary
Activity: 3878
Merit: 1193

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?

Gox creates a withdrawal and makes note of the TXID. Then, before it is included in a block, someone else changes the transaction such that only the TXID changes, but the transaction is still the same. When the new TXID gets included in the blockchain, the customer who requested the withdrawal claims they never received it. But they actually did! Gox looks up the old TXID and doesn't find it, so they create a whole new transaction and send another withdrawal to the customer. The customer has now been paid twice!!! This is solely Gox's problem because they do not correctly track transactions.
full member
Activity: 154
Merit: 100

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?


legendary
Activity: 3878
Merit: 1193
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!
newbie
Activity: 14
Merit: 0
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.
sr. member
Activity: 399
Merit: 250
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
legendary
Activity: 2492
Merit: 1491
LEALANA Bitcoin Grim Reaper
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.  Grin
legendary
Activity: 3878
Merit: 1193
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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
member
Activity: 66
Merit: 10
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.
newbie
Activity: 14
Merit: 0
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?
legendary
Activity: 3878
Merit: 1193
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.
newbie
Activity: 18
Merit: 0
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
legendary
Activity: 1400
Merit: 1013
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.
legendary
Activity: 1176
Merit: 1005
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.
newbie
Activity: 14
Merit: 0
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?
legendary
Activity: 1176
Merit: 1005
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.
legendary
Activity: 1400
Merit: 1013
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.
newbie
Activity: 14
Merit: 0
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.
Pages:
Jump to: