MtGox in trouble
-
Check out realsolid’s comments …
[url=http://tuckfheman.com/post/76211621530/mtgox-bitcoin-exchange-halts-all-bitcoin-withdrawals]http://tuckfheman.com/post/76211621530/mtgox-bitcoin-exchange-halts-all-bitcoin-withdrawals[/url] -
I have been live tweeting the Gox drama directly from their hidden IRC channel https://twitter.com/Feathercoin
-
Makes me wonder how one can run a multimillion exchange and get fooled by a trick 3 years old. If a transaction doesn’t come through, must check inputs and outputs.
-
[quote name=“ghostlander” post=“58215” timestamp=“1392045005”]
Makes me wonder how one can run a multimillion exchange and get fooled by a trick 3 years old. If a transaction doesn’t come through, must check inputs and outputs.
[/quote]It’s actually a very hard problem.
You have an index, because god help you if you have to walk the blockchain every time you want to send from a wallet. So you index the ins and outs by wallet, and you use the most obvious thing in the world to id them: The transaction id.
And then suddenly, a new item appears in your index. Except really, it’s the old item, and the old item has actually been removed from the index, but no one told you, but what really happened is the new item just showed up with a completely different identifier. An identifier that is the result of a deterministic process which states that if the same data is used to form the id, the id will be the same.
Now, how on earth are you supposed to determine that this new transaction which has a new id is really exactly the same as the old transaction even though the id is different? This way lies madness.
Except it turns out that this is exactly the wrong way to approach wallets. Wallets are not a series of transaction ids. They’re a ledger of account changing ownership between entities, and if you’re following the bitcoin protocol, this means that each input references an output. If your index was correct, it would model that linkage of coins transfering between addresses, not the txid series, and such bugs couldn’t possibly happen: You’d correctly overwrite your index when the new modified transaction got included [u][i][b]because there can only be one spend of an output[/b][/i][/u].
[b]MtGox screwed up the protocol implementation.[/b] And it’s easy to see why: [i]It’s hard to do right.[/i]
-
It’s their fault, no doubts about it ( wrong implementation of the protocol ), but we must keep in mind that someone is exploiting that bug and that’s sort of attack. Everyone needs a time to recover from tech. issue specially when they transmitting virtual goods. According me the biggest error was when they mention bitcoin protocol as “broken” and got strong reactions from foundation… After that “To D Moon” guys came with the torches :D
-
[quote name=“Kevlar” post=“58429” timestamp=“1392106140”]
[quote author=ghostlander link=topic=7477.msg58215#msg58215 date=1392045005]
Makes me wonder how one can run a multimillion exchange and get fooled by a trick 3 years old. If a transaction doesn’t come through, must check inputs and outputs.
[/quote]It’s actually a very hard problem.
You have an index, because god help you if you have to walk the blockchain every time you want to send from a wallet. So you index the ins and outs by wallet, and you use the most obvious thing in the world to id them: The transaction id.
And then suddenly, a new item appears in your index. Except really, it’s the old item, and the old item has actually been removed from the index, but no one told you, but what really happened is the new item just showed up with a completely different identifier. An identifier that is the result of a deterministic process which states that if the same data is used to form the id, the id will be the same.
Now, how on earth are you supposed to determine that this new transaction which has a new id is really exactly the same as the old transaction even though the id is different? This way lies madness.
Except it turns out that this is exactly the wrong way to approach wallets. Wallets are not a series of transaction ids. They’re a ledger of account changing ownership between entities, and if you’re following the bitcoin protocol, this means that each input references an output. If your index was correct, it would model that linkage of coins transfering between addresses, not the txid series, and such bugs couldn’t possibly happen: You’d correctly overwrite your index when the new modified transaction got included [u][i][b]because there can only be one spend of an output[/b][/i][/u].
[b]MtGox screwed up the protocol implementation.[/b] And it’s easy to see why: [i]It’s hard to do right.[/i]
[/quote]Can something like this happen with ACP in place?
-
[quote name=“netnerd” post=“58431” timestamp=“1392107567”]
[quote author=Kevlar link=topic=7477.msg58429#msg58429 date=1392106140]
[quote author=ghostlander link=topic=7477.msg58215#msg58215 date=1392045005]
Makes me wonder how one can run a multimillion exchange and get fooled by a trick 3 years old. If a transaction doesn’t come through, must check inputs and outputs.
[/quote]It’s actually a very hard problem.
You have an index, because god help you if you have to walk the blockchain every time you want to send from a wallet. So you index the ins and outs by wallet, and you use the most obvious thing in the world to id them: The transaction id.
And then suddenly, a new item appears in your index. Except really, it’s the old item, and the old item has actually been removed from the index, but no one told you, but what really happened is the new item just showed up with a completely different identifier. An identifier that is the result of a deterministic process which states that if the same data is used to form the id, the id will be the same.
Now, how on earth are you supposed to determine that this new transaction which has a new id is really exactly the same as the old transaction even though the id is different? This way lies madness.
Except it turns out that this is exactly the wrong way to approach wallets. Wallets are not a series of transaction ids. They’re a ledger of account changing ownership between entities, and if you’re following the bitcoin protocol, this means that each input references an output. If your index was correct, it would model that linkage of coins transfering between addresses, not the txid series, and such bugs couldn’t possibly happen: You’d correctly overwrite your index when the new modified transaction got included [u][i][b]because there can only be one spend of an output[/b][/i][/u].
[b]MtGox screwed up the protocol implementation.[/b] And it’s easy to see why: [i]It’s hard to do right.[/i]
[/quote]Can something like this happen with ACP in place?
[/quote]Yes
-
Yeah, ACP just makes sure that the modified transactions get checkpointed. No help there.
Check out the latest commits to Bitcoin, like this one: https://github.com/bitcoin/bitcoin/commit/87fe71e1fc810ee120a10063fdd26c3245686d54
They’re already taking steps to prevent this. Basically that code reads, “Did you use too big an operation for too small a data type? You did? Reject it.” forcing implementors to use the smallest possible data types, disallowing future changes by padding the data with leading 0’s.
The problem, which is a harmless problem to begin with [u]if your following the protocol[/u], is already being mitigated. +1 for the Bitcoin dev team, and minus several thousand for Gox.
