Topic: Contrary to Mt.Gox’s Statement, Bitcoin is not at fault - Gavin Andresen 10/2/14 - page 4. (Read 13078 times)
February 11, 2014, 01:52:08 PM
I wonder if all Mt. GOXXX threads will be moved to service discussion? Hmmm... maybe just mine...
February 11, 2014, 01:37:50 PM
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.
February 11, 2014, 01:19:37 PM
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.
February 11, 2014, 03:57:29 AM
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?
February 10, 2014, 09:49:40 PM
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!
February 10, 2014, 09:25:13 PM
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.
February 10, 2014, 09:21:05 PM
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?
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
February 10, 2014, 09:20:45 PM
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.
February 10, 2014, 09:18:09 PM
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?
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.
February 10, 2014, 09:12:01 PM
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.
February 10, 2014, 09:09:41 PM
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.
February 10, 2014, 09:08:47 PM
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?
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?
February 10, 2014, 09:07:38 PM
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.
February 10, 2014, 08:59:53 PM
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
February 10, 2014, 08:47:35 PM
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.
February 10, 2014, 08:46:30 PM
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.
February 10, 2014, 08:42:03 PM
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?
February 10, 2014, 08:39:26 PM
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.
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.
February 10, 2014, 08:37:37 PM
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.
February 10, 2014, 08:34:21 PM
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.
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.
Jump to: