Topic: MtGox blames Bitcoin protocol problem for BTC withdrawal issue - page 7. (Read 15236 times)
February 10, 2014, 06:02:32 AM
February 10, 2014, 06:02:25 AM
That would only be good for unique transactions, and for individual wallets.
If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?
And how long do you wait before re-sending the transaction if you don't spot it?
The more you wait, the greater the risk a User 3 will ask for the same transaction, which will just further mess things up, and it wouldn't be hard to exploit your input/output based "simple" transaction check to cause trouble.
A safer solution under the current protocol would be to spam the blockchain by including signature transactions: small extra amounts going to specific addresses known to the exchange, and that are unique (to the exchange) at any point in time. This will cause transaction dust of course, which is its own problem.
If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?
And how long do you wait before re-sending the transaction if you don't spot it?
The more you wait, the greater the risk a User 3 will ask for the same transaction, which will just further mess things up, and it wouldn't be hard to exploit your input/output based "simple" transaction check to cause trouble.
A safer solution under the current protocol would be to spam the blockchain by including signature transactions: small extra amounts going to specific addresses known to the exchange, and that are unique (to the exchange) at any point in time. This will cause transaction dust of course, which is its own problem.
I'm not sure you understand how bitcoin works. The problem which precipitated this is not about different users requesting different transactions. It is about the same transaction being "helpfully" modified to be standards compliant, but in the process changing the txid. However it is still the same transaction. The same funds going from the same inputs (albeit with modified scriptSigs) to the same outputs. It is easy to check whether a similar mutated transaction got on the chain or not.
February 10, 2014, 05:57:20 AM
Plus they can then easily track/suspend people who have a record of changing transaction hashes can't they?
No they can't. Because
Simply because they are incompetent.
February 10, 2014, 05:56:22 AM
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
That would only be good for unique transactions, and for individual wallets.If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?
Well that's why each users on the exchange will have a unique deposit address....
February 10, 2014, 05:53:52 AM
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
That would only be good for unique transactions, and for individual wallets.If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?
And how long do you wait before re-sending the transaction if you don't spot it?
The more you wait, the greater the risk a User 3 will ask for the same transaction, which will just further mess things up, and it wouldn't be hard to exploit your input/output based "simple" transaction check to cause trouble.
A safer solution under the current protocol would be to spam the blockchain by including signature transactions: small extra amounts going to specific addresses known to the exchange, and that are unique (to the exchange) at any point in time. This will cause transaction dust of course, which is its own problem.
February 10, 2014, 05:53:27 AM
How you want to verify transaction went trough?
Just check blockchain.info - it's trivial to find transaction knowing source and destination address, amount and approximate time. Least to say they have a signature and can look for it without the need for any tricks with hashing which they mentioned in their statement.
February 10, 2014, 05:51:03 AM
Maybe Mt.gox is after revenge from other Bitcoin exchanges? Mt.gox dropped from handling 80% [historically] of all bitcoin trades to only 25% today. Ultimately, this could be a business tactic by Mt.Gox to crash confidence in Bitcoin and possibly get customers back from other exchanges? Anyway, can't wait for http://ex.nintencoin.com and other such exchanges to come online, so exchange fees can disappear for good!
February 10, 2014, 05:49:09 AM
Painfully oblivious. Well go ahead and vaporize a few more billion in market cap then.
Ah, you are not getting it. They can recover some of the stolen coins this way.
February 10, 2014, 05:46:18 AM
Some excerpts from irc:
<@MagicalTux> [19:26:18] MagicalTux: wasn't a fix already provided, now mutated transaction no longer get accepted to block chain, aren't they? <- they do
<@MagicalTux> [19:28:01] MagicalTux: Who wrote the press release? <- a lot of people actually, it took a very long time to reach something 
<@MagicalTux> [19:29:31] MagicalTux: will you wait for the developers to change the code in some way, or do you just want them to agree on the new standard? Is an agreement enough to make withdrawals processed again? <- agreement + we will implement that standard on our own system without waiting for a bitcoin release
<@MagicalTux> [19:29:52] A mutated transaction can be included directly in a block by a miner. <- or by anyone, actually
<@MagicalTux> [19:30:31] MagicalTux: Only if they race the original transaction. <- yep, which is easy to do if you have a half node that focuses only on catching the tx, morphing it and forwarding it directly to mining pools
<@MagicalTux> [19:30:42] MagicalTux: is there a workaround you could apply meanwhile? <- the solution we propose can be implemented quickly, we just want to make sure everyone agrees to it
<@MagicalTux> (by everyone, I mean the Bitcoin core team and possibly other involved people)
<@MagicalTux> [19:31:54] MagicalTux: so what's the fix you're proposing? is it that starting some particular block depth mutated transactions can't be appear even in block? <- the fix we propose is that even if someone mutates a transaction it has a specific identifying hash that won't change
All major pools (and many p2pool nodes) are directly peering with one another, or via BlueMatt's backbone, including Eligius. It would be strange to discover that they can successfully race that; still, the coins are spent. This is how the satoshidice mutated bets were re-rolled (and how the *.io miners are or were recently re-rolling the latest SD incarnation.)
<@MagicalTux> midnightmagic, and they also peer with wallet & exchange services?
<@MagicalTux> [19:33:32] MagicalTux: If you don't need a new bitcoin release for it to work, then you don't need an agreement for it to work. Why not make it work and seek agreement afterwards? <- if the bitcoin core devs settle for a different solution then we'll have to re-implement it from zero
<@MagicalTux> [19:34:36] MagicalTux: I know I am, minus those goons at blockchain.info. <- inversely, it means it's easy for someone to catch the tx at the source and push it quickly to all miners
<@MagicalTux> [19:37:16] however from what is studiet it shoult be easy to prevent this attack and check if transaction really went trough with different hash <- that's our suggestion, however since that new hash doesn't exist as of today in Bitcoin, it wouldn't mean much to people receiving txs - also since this potentially affects other exchanges, it's better to get a global fix
<@MagicalTux> [19:40:33] magicaltux: have the developers indicated to you that they're on board with the new proposed standard? <- waiting on that for now
<@MagicalTux> [19:26:18]
<@MagicalTux> [19:28:01]
<@MagicalTux> [19:29:31]
<@MagicalTux> [19:29:52]
<@MagicalTux> [19:30:31]
<@MagicalTux> [19:30:42]
<@MagicalTux> (by everyone, I mean the Bitcoin core team and possibly other involved people)
<@MagicalTux> [19:31:54]
<@MagicalTux> midnightmagic, and they also peer with wallet & exchange services?
<@MagicalTux> [19:33:32]
<@MagicalTux> [19:34:36]
<@MagicalTux> [19:37:16]
<@MagicalTux> [19:40:33]
February 10, 2014, 05:44:36 AM
Just BTW, don't they use their custom client?
Yes. And because this possible technical issues before this announcement could be:
- Custom client doesn't follow Bitcoin protocol corretly (bug in custom client)
- Bitcoin protocol has a flaw
the second proved to be true
February 10, 2014, 05:40:15 AM
Just BTW, don't they use their custom client?
February 10, 2014, 05:39:50 AM
It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?
Plus they can then easily track/suspend people who have a record of changing transaction hashes can't they?
If the withdrawn transaction hash was changed; but the transaction did go through (same inputs/outputs/amount) but the user is claiming they never received it; they are a scammer correct? So just ban their account?
February 10, 2014, 05:37:46 AM
It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?
Simply because they are incompetent.
Bitstamp, BTC-E, BTC-China, Huobi, OKCoin: all of these have higher transaction volume than MtGox. Did you ever see a report of similar issue from them?
February 10, 2014, 05:34:38 AM
It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?
February 10, 2014, 05:33:42 AM
FXXK THEM!!! It's just due to the stupid way of their custom wallet follows transactions. The reference client shouldn't have such problem!
February 10, 2014, 05:33:03 AM
Please this thread should be about technical discussion. Everybody is annoyed by their money stuck in MtGox in one form or other. But screams of hate are not of interest on this thread. What i try to found out is legitimacy of technical issue of Bitcoin protocol that MtGox claims to have.
You are right and I apologize, I will delete that, moment of aggravation. You cannot lock people in an exchange and let them keep trading. It is guaranteed to result in what is happening right now.l I do not know why anyone would be allowed to run an exchange who did not know this.
February 10, 2014, 05:31:47 AM
It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Thanks finally someone who said something on topic.
February 10, 2014, 05:30:29 AM
You people are so unbelievably stupid IRL.
I mean you at Mt Gox I know you are here too and this is to you.
Either open the doors or HALT FUCKING TRADING until you do.
Or enjoy your financial hub recreation of Lord of the Flies.
Morons.
Please this thread should be about technical discussion. Everybody is annoyed by their money stuck in MtGox in one form or other. But screams of hate are not of interest on this thread. What i try to found out is legitimacy of technical issue of Bitcoin protocol that MtGox claims to have.
February 10, 2014, 05:30:12 AM
It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.
February 10, 2014, 05:28:46 AM
Well I don't know. From what they say it seems they really cannot easily verify if transaction was added to blockchain (as the transaction hash changes with this attack). How you want to verify transaction went trough?
Human intervention??? I don't think that is feasible given amount of transactions they process daily. Even if they hire 100 monkeys how exactly would they find those transactions in the chain?
I am no expert here. That is why I call for some official Bitcoin developer to confirm or deny issue with protocol that MtGox describes. But if it really exists don't see many options for MtGox to continue withdrawals with knowledge they are being scammed out of BTC. Then lockdown and change of Bitcoin protocol is only feasible solution to me.
Well but as I said depends if MtGox is right/wrong/lying and this I cannot confirm and/or deny.
Human intervention??? I don't think that is feasible given amount of transactions they process daily. Even if they hire 100 monkeys how exactly would they find those transactions in the chain?
I am no expert here. That is why I call for some official Bitcoin developer to confirm or deny issue with protocol that MtGox describes. But if it really exists don't see many options for MtGox to continue withdrawals with knowledge they are being scammed out of BTC. Then lockdown and change of Bitcoin protocol is only feasible solution to me.
Well but as I said depends if MtGox is right/wrong/lying and this I cannot confirm and/or deny.
Jump to: