Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: underhood on February 10, 2014, 10:07:53 AM



Title: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10:07:53 AM
https://www.mtgox.com/press_release_20140210.html

Quote
Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the BitcoinTalk forums. This defect, known as "transaction malleability" makes it possible for a third party to alter the hash of any freshly issued transaction without invalidating the signature, hence resulting in a similar transaction under a different hash. Of course only one of the two transactions can be validated. However, if the party who altered the transaction is fast enough, for example with a direct connection to different mining pools, or has even a small amount of mining power, it can easily cause the transaction hash alteration to be committed to the blockchain.

The bitcoin api "sendtoaddress" broadly used to send bitcoins to a given bitcoin address will return a transaction hash as a way to track the transaction's insertion in the blockchain.
Most wallet and exchange services will keep a record of this said hash in order to be able to respond to users should they inquire about their transaction. It is likely that these services will assume the transaction was not sent if it doesn't appear in the blockchain with the original hash and have currently no means to recognize the alternative transactions as theirs in an efficient way.

This means that an individual could request bitcoins from an exchange or wallet service, alter the resulting transaction's hash before inclusion in the blockchain, then contact the issuing service while claiming the transaction did not proceed. If the alteration fails, the user can simply send the bitcoins back and try again until successful.

We believe this can be addressed by using a different hash for transaction tracking purposes. While the network will continue to use the current hash for the purpose of inclusion in each block's Merkle Tree, the new hash's purpose will be to track a given transaction and can be computed and indexed by hashing the exact signed string via SHA256 (in the same way transactions are currently hashed).

This new transaction hash will allow signing parties to keep track of any transaction they have signed and can easily be computed, even for past transactions.

We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized.

Can any "Bitcoin core developer" confirm/deny this?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10:17:53 AM
Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jballs on February 10, 2014, 10:18:52 AM
This is such an egghead problem.

They decide to suspend all withdrawals because people can say they didn't receive a withdrawal and get paid out twice.

So, they could just hire humans to certify the claims and take however long need be to confirm they are legit.

What's that you say? Human intervention?

Well that is preposterous. No what we will do instead is lock the place down and hold all of our customers hostage until our thuper devs rewrite and implement the errant code.

Clearly that is the best and only solution here.

Painfully oblivious. Well go ahead and vaporize a few more billion in market cap then.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: maaku on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10: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.

Thanks finally someone who said something on topic.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jballs on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jl2012 on February 10, 2014, 10: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!


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mp420 on February 10, 2014, 10: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.

This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jl2012 on February 10, 2014, 10: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.

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?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dave111223 on February 10, 2014, 10: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.

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?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DubFX on February 10, 2014, 10:40:15 AM
Just BTW, don't they use their custom client?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 10: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


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: gizmoh on February 10, 2014, 10:46:18 AM
Some excerpts from irc:

<@MagicalTux> [19:26:18] <e5c> 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] <ersi> MagicalTux: Who wrote the press release? <- a lot of people actually, it took a very long time to reach something :(
<@MagicalTux> [19:29:31] <Mike_B> 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] <midnightmagic> A mutated transaction can be included directly in a block by a miner. <- or by anyone, actually

<@MagicalTux> [19:30:31] <midnightmagic> 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] <anddam> 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] <e5c> 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

<midnightmagic> 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] <archminer> 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] <midnightmagic> 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] <under_hood> 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] <Mike_B> magicaltux: have the developers indicated to you that they're on board with the new proposed standard? <- waiting on that for now


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: cobraman on February 10, 2014, 10: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!


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dave111223 on February 10, 2014, 10: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....


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 10: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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: maaku on February 10, 2014, 11: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.

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.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 11:02:32 AM
Some excerpts from irc:

<@MagicalTux> [19:26:18] <e5c> 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] <ersi> MagicalTux: Who wrote the press release? <- a lot of people actually, it took a very long time to reach something :(
<@MagicalTux> [19:29:31] <Mike_B> 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] <midnightmagic> A mutated transaction can be included directly in a block by a miner. <- or by anyone, actually

<@MagicalTux> [19:30:31] <midnightmagic> 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] <anddam> 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] <e5c> 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

<midnightmagic> 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] <archminer> 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] <midnightmagic> 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] <under_hood> 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] <Mike_B> magicaltux: have the developers indicated to you that they're on board with the new proposed standard? <- waiting on that for now

Why the hell do they need a fix in the protocol, when they already have their own SIGNATURE on the transaction? And most of it's content unchanged? It's trivial to check whether the block includes your transaction without any modification of the protocol. They just want to come out heroes from this. "We saved bitcoins". And crash the price to recover their losses. Fucking bastards.
EDIT: sorry for being emotional, it's just such an obvious lie for anybody familiar with how blockchain is organized.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dafqok on February 10, 2014, 11:08:58 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 11:10:07 AM
Some excerpts from irc:

<@MagicalTux> [19:26:18] <e5c> 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] <ersi> MagicalTux: Who wrote the press release? <- a lot of people actually, it took a very long time to reach something :(
<@MagicalTux> [19:29:31] <Mike_B> 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] <midnightmagic> A mutated transaction can be included directly in a block by a miner. <- or by anyone, actually

<@MagicalTux> [19:30:31] <midnightmagic> 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] <anddam> 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] <e5c> 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

<midnightmagic> 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] <archminer> 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] <midnightmagic> 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] <under_hood> 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] <Mike_B> magicaltux: have the developers indicated to you that they're on board with the new proposed standard? <- waiting on that for now

Why the hell do they need a fix in the protocol, when they already have their own SIGNATURE on the transaction? And most of it's content unchanged? It's trivial to check whether the block includes your transaction without any modification of the protocol. They just want to come out heroes from this. "We saved bitcoins". And crash the price to recover their losses. Fucking bastards.
EDIT: sorry for being emotional, it's just such an obvious lie for anybody familiar with how blockchain is organized.

Well look at it in optimists way ===> cheap bitcoins  ::) ::)
I don't think they will bring bitcoin down. My plan is buy now sell when bitcoin recovers.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 11:12:31 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

There is a bug found/known where transaction hash can change. Attacker cannot change the transaction only the hash. This way transaction goes trough and to sender it seems it didn't.
There is workaround where you simply look at transaction with same inputs and outputs in block-chain (ignoring hash)

Truth seems to be that Bitcoin protocol is simply flawed ... thankfully only in very non critical way (you cannot alter transaction only fool sender for some time and only if he doesn't implement additional checks).

proof issue is known: https://en.bitcoin.it/wiki/Transaction_Malleability


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 11:18:40 AM
Well that's why each users on the exchange will have a unique deposit address....
Not really, because:
  • people don't regenerate the address before each deposit
  • people will have the address copy-pasted in their wallet address book and reuse it even if the exchange regenerates it each time
  • doesn't solve a deposit followed by multiple withdrawals in smaller amounts

For the address to be significant, it needs to be handled under the hood by the exchange, as a dust/signature.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: turtle83 on February 10, 2014, 11:21:44 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dave111223 on February 10, 2014, 11:23:39 AM
Well that's why each users on the exchange will have a unique deposit address....
Not really, because:
  • people don't regenerate the address before each deposit
  • people will have the address copy-pasted in their wallet address book and reuse it even if the exchange regenerates it each time
  • doesn't solve a deposit followed by multiple withdrawals in smaller amounts

For the address to be significant, it needs to be handled under the hood by the exchange, as a dust/signature.

You seem to totally be missing the point here.  This does not affect mt gox deposits at all.

This is *withdrawals* from mt gox....under their current system they track withdrawals that they sent to users via the transaction hash.  Which is apparently a f***** way to track them.  So they should track the withdrawals via the input/output/amount instead.

It's impossible that two withdrawals would have the same inputs/outputs; provided that mt gox use change addresses.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: OutCast3k on February 10, 2014, 11:24:02 AM
Surely, with out even needing to modify the bitcoin client or protocol an easy solution would have been to monitor the inputs of a transaction when a user withdraws. Then, if a user ever claims they didn't receive the funds, mtgox can just check the inputs and follow them through the block chain. Assuming the date, receivers address and withdrawal amount are the same, and only the transaction id differs, you could quite easily determine if the user received their funds or not - and even identify the new transaction id.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 11:25:07 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No

No ... Bitcoin is safe. What i think however is Bitcoin foundation should also make press release to calm down this fear. People not really understanding Bitcoin could easily missinterpret it the same way as "dafqok" did.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jl2012 on February 10, 2014, 11:27:05 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dafqok on February 10, 2014, 11:39:47 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday
Fine, thx to you and underhood. So basically the only problem is with senders who believe in complaints of receivers upon a forgeable fact. Whereas if they take public available information into consideration, the sender arrive at a fully deterministic conclusion about whether the BTC arrived or not and therefore if the receiver's complaint is valid. Well, no big deal at all I would say.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Trillium on February 10, 2014, 11:39:56 AM
Just so I'm 100% clear on the development of this situation:

1. Over one year ago a (minor?) issue with the protocol was identified and some general information was added to the bitcoin wiki. http://en.bitcoin.it/wiki/Transaction_Malleability‎, a publicly viewable resource.

2. Engineers at Mt Gox, historically the most significant - and for a long time the largest - bitcoin exchange in the world, either were not aware of this information (on the public wiki? really), disregarded the issue, and/or failed to implement a solution on their end to prevent or at least monitor and warn of this kind of activity taking place between their backend and their customers.

(edit: From my understanding of their statement, it would seem that the attacker would start a support ticket, and inform Gox that their funds are not recieved. Gox would investigate on their end, only to find that their records show this is true, when in fact, it is not true, and the attacker already has the funds. It would then be sent again. This seems like the kind of thing that could be avoided by careful training of support staff.)

3. An attacker or group(s) of attackers realize that a vulnerability exists with some exchanges, or, at least just Mt Gox. Presumably they "extract" some funds without Mt Gox realizing right away.

4. Mt Gox audits their wallet balances and finds a discrepancy.

5. Mt Gox continues its hold on withdrawals, until the issue, known for over 12 months, is resolved with great urgency by the devs.

How very curious indeed!


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: delulo on February 10, 2014, 11:42:59 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday


Following this analogy how do other exchanges tackle this problem?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: bitdude on February 10, 2014, 11:48:05 AM
Just so I'm 100% clear on the development of this situation:

1. Over one year ago a (minor?) issue with the protocol was identified and some general information was added to the bitcoin wiki. http://en.bitcoin.it/wiki/Transaction_Malleability‎, a publicly viewable resource.

2. Engineers at Mt Gox, historically the most significant - and for a long time the largest - bitcoin exchange in the world, either were not aware of this information (on the public wiki? really), disregarded the issue, and/or failed to implement a solution on their end to prevent or at least monitor and warn of this kind of activity taking place between their backend and their customers.

3. An attacker or group(s) of attackers realize that a vulnerability exists with some exchanges, or, at least just Mt Gox. Presumably they "extract" some funds without Mt Gox realizing right away.

4. Mt Gox audits their wallet balances and finds a discrepancy.

5. Mt Gox continues its hold on withdrawals, until the issue, known for over 12 months, is resolved with great urgency by the devs.

How very curious indeed!

Seems so, more or less :)


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 10, 2014, 11:49:52 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday


Following this analogy how do other exchanges tackle this problem?

Simply they don't look only at hash to confirm transaction was sent. Same thing Gox now needs to implement


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: grau on February 10, 2014, 11:57:55 AM
Such a bullshit. Malleability exists and is a pain. I can however not draw the line between this and stopping withdrawals.

Performing such an attack is non-trivial and unlikely common for the entire customer base. Even if some customer are attacking Gox like described, they should be able to spot and deal with them, without the need to generally stop withdrawals.

Added: Maybe they were incompetent enough not to spot the attack for a longer time, automatically resubmitting same withdrawals again and again until they discovered that they are bankrupt.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 11:58:17 AM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday

Following this analogy how do other exchanges tackle this problem?

Well they don't tackle it because they don't need to. Their transactions are correctly formed, and are readily accepted by the nodes and miners without modification. To force the network to accept modified transaction would take some effort now, because current version of bitcoin node would not retransmit non-canonical transaction. This is actually what made this attack on MtGox possible - and not the speedy link to the miners, or significant mining power of the exploiters. And that's another implied lie in their statement. MtGox issued not-quite-correct transactions to start with, they were rejected by the nodes, and then replayed by the hackers with fixed format. Now I hope you get a better picture of how filthy their lies are.

UPDATE: In the event there are indeed any rejected transactions, they are very rare and far apart, can be easily investigated and dealt with appropriately.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 11:59:38 AM
Such a bullshit. Malleability exists and is a pain. I can however not draw the line between this and stopping withdrawals.

Performing such an attack is non-trivial and unlikely common for the entire customer base. Even if some customer are attacking Gox like described, they should be able to spot and deal with them, without the need to generally stop withdrawals.


Exactly, and that's yet another level of their hypocrisy.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: horsebox1 on February 10, 2014, 12:00:46 PM
Mt. Gox Blames Bitcoin – Core Developer Greg Maxwell Responds

http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: bidji29 on February 10, 2014, 12:01:09 PM
mcxNOW (BTC/Alt exchange) statement about the Mtgox press release. "...stupidity on mtgox part..."

http://www.reddit.com/r/Bitcoin/comments/1xih5d/mcxnow_btcalt_exchange_statement_about_the_mtgox/


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: delulo on February 10, 2014, 12:05:56 PM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday

What are they looking at then?
Following this analogy how do other exchanges tackle this problem?

Simply they don't look only at hash to confirm transaction was sent. Same thing Gox now needs to implement

What are they looking at then?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 12:13:16 PM
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.

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: OpenPay on February 10, 2014, 12:16:41 PM
I'm expecting the next note from MtGox to read something along the lines of "Thank you everyone for your patience while we drove down the market price.  Thank you also for selling so cheap, we are now able to process withdrawls because we bought so cheaply on bitstamp.  Again thank you and sorry we forgot the lube, but at least we only put in the tip this time."


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: rammy2k2 on February 10, 2014, 12:25:13 PM
I'm expecting the next note from MtGox to read something along the lines of "Thank you everyone for your patience while we drove down the market price.  Thank you also for selling so cheap, we are now able to process withdrawls because we bought so cheaply on bitstamp.  Again thank you and sorry we forgot the lube, but at least we only put in the tip this time."

ROFL ... exactly what i was thinking


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 12:36:59 PM
I'm expecting the next note from MtGox to read something along the lines of "Thank you everyone for your patience while we drove down the market price.  Thank you also for selling so cheap, we are now able to process withdrawls because we bought so cheaply on bitstamp.  Again thank you and sorry we forgot the lube, but at least we only put in the tip this time."

They buy cheaply on MtGox. Bitstamp is pricey. So they 1) reduce the number of their BTC liabilities 2) cover the remaining liabilities with cheap coins.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 12:39:44 PM
Maybe they were incompetent enough not to spot the attack for a longer time, automatically resubmitting same withdrawals again and again until they discovered that they are bankrupt.

I have spotted before withdrawals going as far back as 10 November 2013.
http://www.reddit.com/r/Bitcoin/comments/1x4yqe/mtgox_btc_withdrawal_doublespending/

So.. one can only guess.

Update: ah, yes, and that's another lie in their filthy statement, that this has only started in the end of January.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: grau on February 10, 2014, 12:48:19 PM
This is how one could have played the attack on Gox:

You need:

1. Some sizable Bitcoin deposit at Gox
2. A program that grabs the withdraw Gox sends, modifies it such that economics is the same but hash different, then re-sends.
3. Accounting system and Customer Support at Gox, that is incompetent to spot that it gets robbed.

I think 1. can be arranged and 3. is given, for 2 you need some skill and a direct link to some mining pools to increase the chances the altered transaction gets to them quicker than Gox's original. 

4. Some luck and repeat

I Guess Gox was robbed over a longer period of time systematically and they were incompetent enough not to notice it until there were really no coins left.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 01:05:45 PM
Here is the link to the thread, where the patch addressing malleability was discussed:
https://bitcointalk.org/index.php?topic=8392.0

The whole MtGox goxing was only possible because:
1) They were issuing transactions with sloppy signature format
2) This was accepted by the network for some time
3) New bitcoin client with tightened rules was released
4) Their sloppy transactions started being rejected
5) Exploiters "fixed" those transactions
6) MtGox sloppy software didn't notice transaction went through
7) Mt-gox sloppy software didn't notice output's were spent (making them unaware that they lose coins). It didn't even lock outputs which are used in pending transactions!!
8) MtGox incompetent customer support resubmitted transactions manually without looking into issue and alarming developers. Or maybe they did, but developers were too busy/confident/not able to fix the problem.

Overall: MtGox are incompetent bunch of liers


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: snooopy on February 10, 2014, 01:09:25 PM
5) Exploiters "fixed" those transactions

thats the point  ;D


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: spartacusrex on February 10, 2014, 01:20:51 PM
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.

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.

Is it possible to get this hash value from bitcoind ?

Or - How do you get this Hash ?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: grau on February 10, 2014, 01:35:35 PM
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.

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.

that would not spot modifications e.g. through removing/altering an unused push from script.

The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: meelos on February 10, 2014, 01:38:57 PM
I'm expecting the next note from MtGox to read something along the lines of "Thank you everyone for your patience while we drove down the market price.  Thank you also for selling so cheap, we are now able to process withdrawls because we bought so cheaply on bitstamp.  Again thank you and sorry we forgot the lube, but at least we only put in the tip this time."

Haha! Lightened up my afternoon slightly. :)


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Elo on February 10, 2014, 01:44:06 PM
Or - How do you get this Hash ?

Calculate it according to transaction signing rules, which are tricky. (But are implemented in the reference client, so you can copy that.)

that would not spot modifications e.g. through removing/altering an unused push from script.

? Any modification that changes the signing hash would invalidate the signature.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 01:45:09 PM
You seem to totally be missing the point here.  This does not affect mt gox deposits at all.
Which is exactly what I said  ;D

This is *withdrawals* from mt gox....under their current system they track withdrawals that they sent to users via the transaction hash.  Which is apparently a f***** way to track them.  So they should track the withdrawals via the input/output/amount instead.

It's impossible that two withdrawals would have the same inputs/outputs; provided that mt gox use change addresses.
How is it impossible?

MtGox doesn't control the destination address, so that can be the same.

For MtGox to control the origin address it means they would have to spam the blockchain with internal transfers to intermediate addresses (that they could change) for withdrawals, so that a given address is only used once for a given amount in a given time-frame.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dave111223 on February 10, 2014, 01:56:00 PM
This is *withdrawals* from mt gox....under their current system they track withdrawals that they sent to users via the transaction hash.  Which is apparently a f***** way to track them.  So they should track the withdrawals via the input/output/amount instead.

It's impossible that two withdrawals would have the same inputs/outputs; provided that mt gox use change addresses.
How is it impossible?

MtGox doesn't control the destination address, so that can be the same.

For MtGox to control the origin address it means they would have to spam the blockchain with internal transfers to intermediate addresses (that they could change) for withdrawals, so that a given address is only used once for a given amount in a given time-frame.

By default an address is only used once, the entire balance on the address is spent and any leftover coins are returned to a new change address.  Mt Gox has literally millions of addresses.  Address can be used once then discarded.  This is not "spamming the blockchain" this is just the way bitcoin works by design.

It's trivial for them to discard used change addresses.

It's very easy for them to ensure that the same inputs/outputs/amount are never used more than once.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jl2012 on February 10, 2014, 02:00:27 PM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday


Following this analogy how do other exchanges tackle this problem?

I have a better analogy here and also answered your question: https://bitcointalk.org/index.php?topic=458386


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: newguy05 on February 10, 2014, 02:07:43 PM
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.

Yes, It's not a technical issue mtgox is trying to solve but liquidity/price related.  The news release is a sham just like their past usd halt release to fix "technical issues" when it turned out the us government froze their us bank assets as the real reason.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: grau on February 10, 2014, 02:09:21 PM
that would not spot modifications e.g. through removing/altering an unused push from script.

? Any modification that changes the signing hash would invalidate the signature.

Input scripts are not in the signature hash, otherwise signature would have to sign itself.
In n-out-of-m multi signature one can even have any garbage in place of signatures not needed to verify.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: surphactone on February 10, 2014, 02:44:19 PM
I think that the market need to swith to another Altcoin like LTC or QRK


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Bobsurplus on February 10, 2014, 02:53:51 PM
I think that the market need to swith to another Altcoin like LTC or QRK

I agree. Mostly because I hold many of both coin and would love to see a jump in price.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: tacotime on February 10, 2014, 03:07:25 PM
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday

Following this analogy how do other exchanges tackle this problem?

Understand the protocol before you write software for it...


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phzi on February 10, 2014, 03:12:15 PM
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 03:14:09 PM
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. Bo problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.

bitcoinfoundation....how much influence does mtgox have?
i am very interested to see how this will end.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Totscha on February 10, 2014, 03:31:05 PM
Mt.Gox is not hurting Bitcoin, it's people still using Mt.Gox that are hurting Bitcoin. (Guns don't kill people, people kill people...) But in that respect I also blame the Bitcoin Foundation for not throwing Mark out of their board and revoking the gold member status that Mt.Gox still holds.

People that got into Bitcoin in the last six months got the wrong impression that Mt.Gox was a solid exchange only because their status in the foundation.

Just ignore it and move on. This kind of utterly irresponsible negligence must not go unpunished!

Seriously, what did you expect from an exchange that is too lazy to even change its name after it switched from trading Magic the Gathering cards to Bitcoin trading?


Unless you really like to be 'mtgoxed' every few months. Then by all means, transfer you life savings over there.



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: vleroybrown on February 10, 2014, 03:31:56 PM
Ok so to me basically this situation is because of a skilled hands on manipilation of bitcoin transactions in a way that is meant to trick dumb I/O cycles of computer processing rules thereby producing enough inconsistency that the attacker succeeded in duping users.  

Now then the whole issue I see now is that the distributed nature of the protocol allows a major sneaky manipulation like this to occur but without any way to resolve than point fingers at others or the fundamentals of the bitcoin protocol itself.  No one can say conclusivly that MtGox is wrong on this one because a solution to a known issue has not been fixed within bitcoin itself.  These types of situations never seem to end equitable for all.  And without consistency in addressing this I do believe the bitcoin to be less valuable fundamentally for this issue status.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 03:40:47 PM
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.

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.

that would not spot modifications e.g. through removing/altering an unused push from script

The goal isn't to "spot modifications", the goal is to check if transaction was included into a block.

Generally speaking, attacker can only modify scriptSig(s), so if you compute hash of a transaction without scriptSig(s) (like how it is done for signing purposed), that hash will be unique: if you spot transaction with that hash in blockchain then transaction was successful.
.
The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash.

Yes, but what I described above can be a drop-in replacement in a gox-like system: simply use a different hash as a txid.

But, yeah, whatever...


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: af_newbie on February 10, 2014, 03:44:34 PM
Store the original transaction id, and (amount, timestamp, dest address).  Assign "in" and "out" bitcoin addresses to each account.

All withdrawals will come from "out" address to "dest" (end user, private) address.  If someone changes the original transaction id, no problem.
Use the "out" address, timestamp and amount to find the changed transaction id and validate the transaction.
Store the modified transaction id along with the original transaction id.

If someone comes along and claims that they did not receive funds, check the list of transactions, if more than one, flag the user.

I think what happened was that their system was looking for the original transaction id in the block chain, and if not found their system was
automatically initiating another transaction
to the same dest address.  I say their system did not handle this "not found" error properly.

Claiming that the protocol needs to be changed is a bit extreme.  I hear this all the time from "not so hot" developers.  
"The problem is not in my code.  It is not me, it is xxx/so and so.  Excuse after excuse.  My code is perfect, if you want to work with my module, change your interface, blah, blah"

They want bitcoin to change the protocol so that their system works.  Well, they should change their system so that it works with bitcoin network, not the other way around.

I think Mt.Gox should close the doors after this.  They would save their face, if they came out and said "yes, we've had a bug in our code.  We'll fix this in two days."
That would give them some credibility.  Now, they look like "not so hot" developers.

If they cannot handle errors in their system, I wonder how stable their trading platform is?



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: justusranvier on February 10, 2014, 03:49:05 PM
The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash.
I can't comprehend why anyone would code a wallet that doesn't do this. There's no excuse for failing to notice relevant changes to the canonical source of your balance information, the blockchain.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: dddbtc on February 10, 2014, 03:53:06 PM
Quote from: Mount Cocks
We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized.


Translation: "If you can convince the whole world to hard-fork the blockchain, you can have your money back.  But that'll be about as easy as making your money back, so good luck"  ::)

http://www.free-management-ebooks.com/images/fiap0302.jpg



I'd make a wager that they ran the whole exchange on a misguided fractional reserve, now their books don't balance, and they're halting withdrawals and doing arbitrage hoping the ship doesn't sink.  



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 03:57:14 PM
Another lie from MtGox:

[10/02/14 15:08:48] <@ne0futur> epscy: the problem is ackowledged
[10/02/14 15:09:04] <@ne0futur> <gmaxwell> Oh there is a “problem” in the Bitcoin protocol, known since at least 2011 (see the link I gave). But for normal applications, not involving unconfirmed transactions, it shouldn’t cause any severe problems because wallets can handle it locally.
[10/02/14 15:09:07] <epscy> ne0futur: what does that mean?
[10/02/14 15:09:12] <@ne0futur> http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
[10/02/14 15:09:31] <@ne0futur> the disagreement is on how to fix it
[10/02/14 15:10:06] <@ne0futur> one option is putting much more load on the client who cant trust the transaction hash on the blockchain
[10/02/14 15:10:10] <@ne0futur> as I understand it
...
[10/02/14 15:15:16] <ibtc> ne0futur the problem was acknowledged in May 2011: https://bitcointalk.org/index.php?topic=8392.0. The patches were submitted in late 2012: https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp. Stop repeating "the problem was acknowledged" - it sounds really pointless
[10/02/14 15:15:50] <@ne0futur> ibtc: https://en.bitcoin.it/w/index.php?title=Transaction_Malleability&action=history
[10/02/14 15:15:53] <ibtc> MtGox had a sloppy implementation for transaction signature format which made it vulnerable
[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers
[10/02/14 15:16:35] <ibtc> What, DER standard was documented in 2013???
[10/02/14 15:16:50] <ibtc> Do you actually understand what you are talking about?
[10/02/14 15:40:24] <ibtc> "[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers" <- yet another lie from MtGox. https://en.bitcoin.it/w/index.php?title=Protocol_specification&oldid=7624     Edited on 24 April 2011: "Signatures use DER encoding to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). "

Specification was updated in April 2011, clarifying that the format for the signatures is DER encoding (which, when strictly followed, would always produce the correct signature accepted by all clients, not just OpenSSL ones). Apparently, MagicalTux didn't know about that. And I highly doubt he learn about it any time earlier than a few days ago.

What a bunch of liars. All of them. :(


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Yogafan00000 on February 10, 2014, 04:13:56 PM
... doing arbitrage hoping the ship doesn't sink.  



I doubt they are savvy enough to pull off an arbitrage move successfully.  Especially given the fact they seem to have left themselves vulnerable to a double-spend attack due flaws in their own business systems.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 04:27:15 PM
No one can say conclusivly that MtGox is wrong on this one because a solution to a known issue has not been fixed within bitcoin itself.

You're wrong, it doesn't need to be fixed. It is gox's problem.

If you have problems understanding how it works, read this: http://www.reddit.com/r/Bitcoin/comments/1xiowj/explain_the_gox_transaction_malleability_issue/

What we take from it is that it is a bad idea to rely on closed-source wallets, as it is likely that dude implementing it will miss something.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 04:27:46 PM
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.  Other exchanges, merchants, and service providers have dealt with this for years.  MtGox is not only incompetent but they are also adding a fud fueled headline to cover their asses ("Bitcoin protocol is broken, we can't safely transfer coins until it is fixed").  We all know how much fact checking the media does so I expect to see the headline about Bitcoin broken and unsafe any hour now.

It is important to point out that transactions don't accidentally get mutated. and there are no false positives.   If you make a tx (tx hash A) and that tx (tx hash A) ends up in the blockchain then the user got paid.  Period.  If you are competent that should be 99.99999% of your transactions right there.  Thus the mutated tx are a edge case and one which can be handled manually if you want.

TO AVOID LOSING MONEY TO SCAMMERS (hint hint MtGox before you lose more of your user's funds):
If a user reports they did not receive the withdraw there are three possibilities.

First you first check the blockchain for the tx hash.  If you find it then you are right and user is wrong.  You have paid them.

Second if the tx hash is not in the blockchain, you check to see if the same tx (same inputs, same outputs) is in the blockchain.  If you find one, then the user is wrong.  You paid them and "someone" (likely the scammer user you are talking to right now) mutated the transaction to hide the fact from you and is trying to get double paid. So you flag or ban the user whatever your internal policy but you don't pay them again.

If the payment if not found by either method in the blockchain then you (MtGox) likely fucked up again.  Check to see if you:
a) are spending immature outputs
b) are double spending prior spent outputs
c) are paying insufficient fees (yup charging users 10x the min fee then failing to pay even the min fee for your tx)
d) are producing bloated spammy tx which violate the Bitcoin protocol spam rules





Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 04:29:58 PM
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.
You mean spam the solution is to spam the blockchain with transactions to credit the one-time addresses used only for tracking purposes?

That's okay if you're Joe's Backwater Exchange with 2 withdrawals a day, but if major exchanges all do that it'll just bloat the blockchain, and it's already bloating fast enough, thank you.

Just improve the damn protocol.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 04:33:05 PM

Just improve the damn protocol.

nope
its enough when mtgox does the same as the bitcoind wallet: check for outputs and dont rely on txid alone.

you really want a hardfork because one company did fuck up their custom client?
<sarcasm>while we are at it we could also reverse the transactions which stole money from gox


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 04:34:57 PM
This.  Other exchanges, merchants, and service providers have dealt with this for years.

Urgh, actually I think most of them don't.

All services that provide you with an unconfirmed transaction ID right at withdrawal times are likely to be vulnerable from the same MtGox issue in one form or another.

IMHO they were just too puny for anyone to have bothered, we'll see sinkers and floaters in the next weeks.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: af_newbie on February 10, 2014, 04:36:08 PM
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.
You mean spam the solution is to spam the blockchain with transactions to credit the one-time addresses used only for tracking purposes?

That's okay if you're Joe's Backwater Exchange with 2 withdrawals a day, but if major exchanges all do that it'll just bloat the blockchain, and it's already bloating fast enough, thank you.

Just improve the damn protocol.

Just improve the damn application.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 04:36:23 PM
Store the original transaction id, and (amount, timestamp, dest address).  Assign "in" and "out" bitcoin addresses to each account.
...

While that would work, you don't even need to do that much.

You don't need unique out addresses because even if you pay two (or 10,000) users from the same address, Bitcoin doesn't work on the concept of addresses and balances.  Each user will have unique inputs for their tx.   That is how Bitcoin works, it is how it has always worked, and it is how it always will work. 

You simply record the raw tx.  Thats it.  Nothing special.  Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet.

Now for 99.999% of your transactions (if you are competent and not doing things like double spending your own coins, paying insufficient fees on masive spammy txs, and spending immature coins) the tx will go through fine.

For the 0.001% of transaction where user reports non-payment you:
a) check the blockchain to see if the tx exists by tx hash
b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.

Why do a if b will find all txs?  Simple it is faster and tx don't accidentally mutate themselves so it gives you good information on which customers might be trying to rob you.  You don't have enough "evidence" to have them arrested, maybe not enough to even ban them, but you certainly have enough to flag their account so it warns other customer support reps to be extra vigilant.



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 04:43:14 PM
its enough when mtgox does the same as the bitcoind wallet: check for outputs and dont rely on txid alone.
Once the volume is large enough, that's exploitable as well if the exchange doesn't spam the blockchain with unique withdrawal addresses (since you'll get or can manufacture duplicates).

And if TX ID are useless for identifying transaction, improve the protocol by dropping them from the blockchain, that'll help cut down on the bloat, you can always locate a transaction by block height + tx index.

you really want a hardfork because one company did fuck up their custom client?
Seriously? If forking for improvements has become such a scary concept to bitcoiners, then that tech is fast turning into a train wreck waiting to happen.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 04:44:50 PM
This.  Other exchanges, merchants, and service providers have dealt with this for years.

Urgh, actually I think most of them don't.

All services that provide you with an unconfirmed transaction ID right at withdrawal times are likely to be vulnerable from the same MtGox issue in one form or another.

IMHO they were just too puny for anyone to have bothered, we'll see sinkers and floaters in the next weeks.

Not really.

The first thing to point out is that if you are competent very few of your txs should ever end up dropped from the network.  MtGox had thousands of them.  They had not one problem but at least 4
a) double spending previously spent coins = invalid tx so nodes dropped it.
b) spending immature coins = invalid tx so nodes dropped it (although these would eventually get through after 120 blocks).
c) paying insufficient fees for relay (not following the fee rules in the reference client so nodes running on those rules would drop the tx instead of relaying them).
d) using non canonical signing two years after the issue was reported and modified in the reference client.

This changed what normally is an incredibly rare event (tx not propagating the network) to one that was widespread and affecting innocent users.  Had this giant cluster fuck of layered incompetency not happened the actions of any scammer would be more obvious.  If you only have a handful of users reporting they didn't get paid it is a little more obvious when 20% to 30% of all your withdraws across all users are failing.

A small exchange doesn't need an automated system to deal with tx mutability.  We don't. That is because 99.9%+ of the tx will never be mutated and there are no false positives.  There is nothing wrong with using the tx id as long as you don't rely on it as your first, last, and only method of accounting.   Mutability doesn't happen by accident.  

IF a user reports they didn't get paid and IF the tx hash is not in the blockchain then you MANUALLY flag the account and look for a tx which has the same inputs and outputs.

If you don't have that laundry list of problems above going on this should be a VERY VERY RARE EVENT and one that likely warrants manual attention anyways.  Sure a super duper automated system would be great and if you have the funds to build, extensively test, and deploy it go ahead but this isn't a routine occurrence for a properly running node.  So if your backend can process 99.9% of tx in an automated fashion and flags 1 in 1000 (and honestly probably more like 1 in 100,000) for manual review well guess what?  That is called doing business.  Most automated systems have some event which are logged for manual review.

The other thing to keep in mind is that most likely, the only reason it happened is because the user who reports he "didn't get paid", modified the tx intentionally so he can try to collect a second payment.  That means putting a man in the loop is a good idea even if you do have a super duper automated handle every edge case back end processor.  


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 10, 2014, 04:45:09 PM
>Now for 99.999% of your transactions (if you are competent and not doing things like double spending your own coins, paying insufficient fees on masive spammy txs, and spending immature coins) the tx will go through fine.


...and signign with non-canonical signatures, after it's a known issue for two years


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: af_newbie on February 10, 2014, 04:45:33 PM

b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.


Even better.  Someone should send them the above line.  


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 04:46:09 PM

Once the volume is large enough, that's exploitable as well if the exchange doesn't spam the blockchain with unique withdrawal addresses (since you'll get or can manufacture duplicates).


outputs != withdraw address
its very easy to do and bitcoind does it. just mtgox thought txid is ok: and i expect a major exchange which custom software to follow bitcoin changes closely: so they should have known it before


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 04:50:46 PM
Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet.

The wallet solves different problems, it's like a piggy bank, it only cares about what goes in and out, with limited attribution capability.

In the grand scheme of things, exchanges should not be using the wallet, just like stock exchanges aren't run with Excel spreadsheets and VB macros.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 04:55:39 PM
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.
You mean spam the solution is to spam the blockchain with transactions to credit the one-time addresses used only for tracking purposes?

Please learn how Bitcoin works.

All txs have change (except in the edge case that the output exactly matches the inputs).  Sending the change back to the same address, or sending it to a new address doesn't have any effect on the size of the blockchain or UXTO.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 04:56:53 PM
Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet.

The wallet solves different problems, it's like a piggy bank, it only cares about what goes in and out, with limited attribution capability.

In the grand scheme of things, exchanges should not be using the wallet, just like stock exchanges aren't run with Excel spreadsheets and VB macros.

but you agree that if an exchange builds there own wallet software they are responsible for it?

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).
it is public knowledge: every wallet developer should closely follow bitcoin changes and bugs. if mtgox had done that they could have avoided this desaster


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 04:59:39 PM
A small exchange doesn't need an automated system to deal with tx mutability.  We don't.  That is because 99.9%+ of the tx will never be mutated.
We'll see who sinks and floats as other exchanges pick up the slack and grow.

I wish you and them all well, but I would be surprised if there aren't other noteworthy casualties.

And anyway, this is a good opportunity to improve things, assuming the devs act on it. Otherwise, it'll just generate bad press.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 05:08:46 PM
And anyway, this is a good opportunity to improve things, assuming the devs act on it. Otherwise, it'll just generate bad press.

MtGox will continue to generate bad press as long as they remain incompetent and then lie with inflammatory language in order to obfuscate that fact.  Either they will become competent, the exchange will get sold to people who are, or they will go out of business.  There is nothing for the developers to change at this point.  The protocol isn't going to be hard forked due to the incompetence of one exchange.  The reference client handles this fine.

If you make a payment with the reference client and the tx ends up in the blockchain but with a mutated tx hash what do you think the reference client does?
a) continue to report the tx as unconfirmed so users will think they need to make a second payment
OR
b) detect the modified version of the tx (when it scans blocks for new txs anyways) and modify the client's records so the tx shows the proper confirmations and the new modified tx hash?

Hint the answer is B

In other words the reference client handles this issue properly.  MtGox hacked together code does not (along with at least 4 other errors in processing txs).  MtGox also tries to spend immature newly mined coins.  That is another obviously wrong thing to do, No other client does that, The protocol doesn't allow that.  Should the protocol also be changed to allow the spending of immature coins so MtGox broken client will be not as broken?   This isn't a protocol issue, it is a client issue.  The client should handle this condition.  Most clients do, the "Gox Custom v0" ended up goxxing the exchange because it doesn't.

If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 05:10:02 PM
but you agree that if an exchange builds there own wallet software they are responsible for it?

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).
it is public knowledge: every wallet developer should closely follow bitcoin changes and bugs. if mtgox had done that they could have avoided this desaster
Sure, they are responsible for it, but that doesn't absolve the Bitcoin devs from working out better solution, nor does it absolve the bitcoin community to all pile it on MtGox.

This is an image issue there, look at the outside perception:
  • the obvious well defined transaction ID (a basic accounting principle) isn't guaranteed by bitcoin
  • bunch of geeks says MtGox was wrong because of obscure incomprehensible reasons for most outsiders
  • the biggest exchange obviously got it wrong on those incomprehensible reasons
  • bitcoin devs resist change, giving an image of denial
  • bitcoin community runs afraid screaming "hard fork" whenever a protocol change is mentioned

So that just gives an image of a fossilized complex tech that even large players get wrong.

Just won't build much mainstream confidence, will it?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: justusranvier on February 10, 2014, 05:16:16 PM
Sure, they are responsible for it, but that doesn't absolve the Bitcoin devs from working out better solution, nor does it absolve the bitcoin community to all pile it on MtGox.

This is an image issue there, look at the outside perception:
  • the obvious well defined transaction ID (a basic accounting principle) isn't guaranteed by bitcoin
  • bunch of geeks says MtGox was wrong because of obscure incomprehensible reasons for most outsiders
  • the biggest exchange obviously got it wrong on those incomprehensible reasons
  • bitcoin devs resist change, giving an image of denial
  • bitcoin community runs afraid screaming "hard fork" whenever a protocol change is mentioned

So that just gives an image of a fossilized complex tech that even large players get wrong.

Just won't build much mainstream confidence, will it?
There is no image problem, just altcoin pumpers who grasp at any straw to keep their exchange rates pumped up just a little bit longer. Same shit that's been going on for three years now.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 10, 2014, 05:16:22 PM
If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

If the most widespread implementation does it one way, then it becomes standard. Happened with IE bugs, happens these days with Safari and Chrome bugs.

Public does NOT GIVE A DAMN about geeky correctness. If a page fails on FireFox but works with IE, users will accuse FireFox/Chrome and stick with IE. They did. For years. So FireFox and Chrome supported Quirks mode, and still do.

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.

Either this is taken as an opportunity, or it will be taken as a blow, that's all.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: af_newbie on February 10, 2014, 05:19:08 PM

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.


I think in this case, MtGox got bad press in more ways than one.  Bitcoin is fine.

They tried to blame bitcoin, didn't work.  Move along.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: cr1776 on February 10, 2014, 05:35:19 PM
If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

If the most widespread implementation does it one way, then it becomes standard. Happened with IE bugs, happens these days with Safari and Chrome bugs.

Public does NOT GIVE A DAMN about geeky correctness. If a page fails on FireFox but works with IE, users will accuse FireFox/Chrome and stick with IE. They did. For years. So FireFox and Chrome supported Quirks mode, and still do.

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.

Either this is taken as an opportunity, or it will be taken as a blow, that's all.

Thankfully MtGox is not anywhere near the "most widespread implementation" (and is dropping wildly by the second), and so it is not the "standard". So MtGox is wrong. The opportunity here is for Gox to either implode or fix their sh!t.  In all likelihood, given their issues and inability to fix repeated problems for a year now, it will be for former.  

MtGox is on its way to being an extremely minor player in the exchange business. If MtGox comes out of this with anything but a minuscule percentage of the exchange business (if ANY), I'll be surprised.






Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 05:38:56 PM
If the most widespread implementation does it one way, then it becomes standard.

Ok then the standard is that tx hashes are mutable and clients need to account for that.  Glad you agree. 


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: Zzzack on February 10, 2014, 05:40:15 PM
I was wondering something about this issue.. Would a coin with a 30 minute block interval be more susceptible to this problem?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 05:48:06 PM
b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.

It makes sense to find all transactions which spend same coins.

1. No such transaction -> txn was not included into a block
2. One such transaction -> that's what we're looking for, now check its outputs
3. More than one transaction -> bug in software, investigate

Unlike what you described, this check can be done with simple tools like block explorer (or, automatically).

E.g. suppose software says that transaction in question spends b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895:1

Then you look it up: https://blockchain.info/tx/b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895/1

Red link (Spent) points to a transaction which spends this output, which is the transaction we are looking for.

(I simply want to clarify that it is better to look up inputs one by one than look up "the unique set of inputs" (whatever it means)).


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 05:55:10 PM
And if TX ID are useless for identifying transaction, improve the protocol by dropping them from the blockchain, that'll help cut down on the bloat, you can always locate a transaction by block height + tx index.

ITT: People who have only a very vague idea about how Bitcoin works offer solutions and propose protocol changes.

Seriously, if you haven't read the source code, SHUT THE FUCK UP. You're simply not competent to say anything on this matter.

This mess was caused by people who weren't competent enough, do not make it worse by making strange noises.

(What you wrote above is ridiculous, you have no idea what is "TX ID" and how it is used, how it is included into blockchain etc.)


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 05:57:15 PM
I was wondering something about this issue.. Would a coin with a 30 minute block interval be more susceptible to this problem?

No.  This has nothing to do with the block interval.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mb300sd on February 10, 2014, 06:00:06 PM
My proposal for a very simple fix: track change addresses instead of txid.

https://bitcointalk.org/index.php?topic=458668.0


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mightycount on February 10, 2014, 06:03:05 PM
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.

MtGox's problem is not "malleability", it's the fact that they didn't submit transactions to the network, at the same time making internal hashes public. The answer to Mr. Karpiles from the core development team should be clear and resounding "NO". Bitcoin is fine as is and MtGox should pull their $#!+ together. I could not believe the idiot dared to blame the Bitcoin protocol.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 06:08:47 PM
I could not believe the idiot dared to blame the Bitcoin protocol.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 06:16:24 PM
It is easy to check whether a similar mutated transaction got on the chain or not.

Surely, with out even needing to modify the bitcoin client or protocol an easy solution would have been to monitor the inputs of a transaction when a user withdraws.

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).

b) detect the modified version of the tx (when it scans blocks for new txs anyways) and modify the client's records so the tx shows the proper confirmations and the new modified tx hash?

Someone please show me how to do this easy check with a few bitcoind commands?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 06:20:32 PM

Someone please show me how to do this easy check with a few bitcoind commands?

when a new block arrives get it with rpc and look through the json output?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: ZephramC on February 10, 2014, 06:33:07 PM
If the most widespread implementation does it one way, then it becomes standard. Happened with IE bugs, happens these days with Safari and Chrome bugs.

Public does NOT GIVE A DAMN about geeky correctness. If a page fails on FireFox but works with IE, users will accuse FireFox/Chrome and stick with IE. They did. For years. So FireFox and Chrome supported Quirks mode, and still do.

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.

Either this is taken as an opportunity, or it will be taken as a blow, that's all.

Well, then the public deserves to loose their money. Any system that would shield them from this is a bad system. Doesn't matter how widespread is the non-complaint solution.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 06:46:19 PM

Someone please show me how to do this easy check with a few bitcoind commands?

when a new block arrives get it with rpc and look through the json output?

Sure, poll getblockcount, then what? Please show how easy it is to spot this.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: flower1024 on February 10, 2014, 06:49:41 PM

Someone please show me how to do this easy check with a few bitcoind commands?

when a new block arrives get it with rpc and look through the json output?

Sure, poll getblockcount, then what? Please show how easy it is to spot this.

Code:
$ bitcoind getblock 000000000000010c5ba86d05c6f43df46921d453d23fdafe85229f6a7d840e16 '{"tx":"obj", "script":"asm"}'
{
    "hash" : "000000000000010c5ba86d05c6f43df46921d453d23fdafe85229f6a7d840e16",
    "confirmations" : 43,
    "size" : 1473,
    "height" : 186154,
    "version" : 1,
    "merkleroot" : "47de80c28529a69bddefb90ea15388f10e2647482560bb50857e7b586d45a8c3",
    "time" : 1340614357,
    "nonce" : 728350342,
    "bits" : "1a09b78a",
    "difficulty" : 1726566.55919348,
    "tx" : [
        {
            "txid" : "11af9ba807942f7db6274f40442651c7b58b02b0a942867847b2b8a3932df7b1",
            "version" : 1,
            "locktime" : 0,
            "size" : 142,
            "vin" : [
                {
                    "coinbase" : "048ab7091a027702062f503253482f",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 50.00000000,
                    "scriptPubKey" : "04b034ecbcbe86f327d2edd25ce1fce3f4463710c00ae00d1a25198bab882be95c72d3468dc6931f756b03d99a3b7f3a07543834370ad023b37cb1127c6266d91a OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "9fb85b2c9085284a6c39407025cbec31b4c88b1075f3d98840395bc4e389616d",
            "version" : 1,
            "locktime" : 0,
            "size" : 259,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "1f16f657fb093f4618c1ad6504130d08fa71bb1964d0be5574f44011124f7b64",
                        "n" : 1
                    },
                    "scriptSig" : "3046022100dea86a40b8ffcfa446e05886e18c7ea8bca371118da48d4adfde846b87af43190221009652d86f7013afd35311fe8d080c9e592758716c08e971c39283ca08746db78501 04a1ce79a9fec1018129bb79c19dc90dcb4657e8cf725c635909ea402143b64e84fb06bf0b2c96ca6f0db9ac8ae480399f7724a9b288faf52c16d1535f13b90fe6",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 1066.13121507,
                    "scriptPubKey" : "OP_DUP OP_HASH160 e51a349be7044a8d84c6e8370ff56ff6860f3597 OP_EQUALVERIFY OP_CHECKSIG"
                },
                {
                    "value" : 1242.21306062,
                    "scriptPubKey" : "OP_DUP OP_HASH160 51fb66b01bcdbcdc67049fa97a8da21a2fa912e0 OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "060cbd899b2c1fac0cdbcf580a3f90aae131b16d516f049baf1d13c66e410892",
            "version" : 1,
            "locktime" : 0,
            "size" : 226,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "f2b6efbef50c026efc19dac73ed787b0ccc1697c8640e96637ab861e85afca60",
                        "n" : 0
                    },
                    "scriptSig" : "3045022100a0be436cb85b899740792206a17658ef96e6d786e53448cab8b11f9e51be96a6022063ab6d9337fa71b9d5a75e3ebe0a33c151ad6cdca70f9170c1b0297d655c5b3301 022cb39adb02162270b89b08975256293182bcaa84622d18a30c3bd72751d4ddd5",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 1.40018289,
                    "scriptPubKey" : "OP_DUP OP_HASH160 d6211f74851b1cc1d181d0fe591445a18f49c818 OP_EQUALVERIFY OP_CHECKSIG"
                },
                {
                    "value" : 1.00000000,
                    "scriptPubKey" : "OP_DUP OP_HASH160 713c581950bbfb0545f1418bbfe825911e8efa5c OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "2da6e2a83abe9e870a3a4762d8159e523a3068cce26c5670afdcd2c63486a1ac",
            "version" : 1,
            "locktime" : 0,
            "size" : 765,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "9aa47d859bda3eba62fd366461adda78f6df3293dd7b1681361f54531220b378",
                        "n" : 2
                    },
                    "scriptSig" : "3046022100f10d0f6fc6ce90ae97a04627a659791b1caed48aae8d70b82c73c5c730758576022100aba76d54166189b50e678faac63a4265d6d2daf48889a23a1fc285e042fb9c8901 04addfdfd09989768bc93678fd4eca1bf8d485e98690b7584a7559ab30a63ac16fd33e8e7db59f72c21b402a78bacbde205d642e60037d8b660a57341a60c4e646",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "125ea4a6f9e86333de7566af28e6a5558a2c66e5c41b197560bd9a8e6c56866b",
                        "n" : 0
                    },
                    "scriptSig" : "3045022100c9e3d69de5bcbb9252b2b637e6846eaef971959653c887e7bb13f6528f1587f2022059d47b80f98460c0a02a9f7a7977202533fe3566a1cbecc599b122af02a8b8ac01 04a875f1a901e23be1435350f1a94820f84f590e297c0a34e393b873ac5b3182d071ca43890a54c750ad2fd6288416a319e70e48f2c2d2fe828666cfc98689ce0e",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "e2b9a62cd1ad312f510510bf071ae0079b6b858db8b43e86809b7269d8ad1ff7",
                        "n" : 1
                    },
                    "scriptSig" : "3045022100a198dea14374a5d0584cfedeb8f6a457556b9bdd0488c433b179ad328a007c7102200a3179f1b8a95ae4e02183c25fb3234f1efe0db9129806d38579b2845e77a11801 047b19a9c3e6b0a92e9bdeeb294ebea709dd1d9b5e2ccb7e1fb03ca6bfa43b78dd0a6d72ddd9e64130513d63dc1ea5609906a15f1d3044f50ee6415b2e4eaf59e4",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "b6548149a182fd10330b9f69024bdd55ce521ce367e9125d1bd8c91a8c5539da",
                        "n" : 0
                    },
                    "scriptSig" : "30450220670628b426d996131f064bb861554e31bd3afcdc581ae9824af1610dcc079080022100d240e2f445670f8e2be82f5fc74dfbc98312f0adb5f2ec163449588bdd8e9f8401 045c7e935730d0a7e45615e4a5df7c50b8bdde7fad7c978c569563b5451a756710d7dc0f1a248bd233467f17dd28e27484a91c0af4123c131b87d959dd37850692",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 0.19950871,
                    "scriptPubKey" : "OP_DUP OP_HASH160 c6b92e0b69d3a7aa53a28e2bc5a6de3f32fbff5a OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        }
    ],
    "previousblockhash" : "00000000000006d68b5d22acef2a43b38dc692782d7c12c0ae43259b9eb46078",
    "nextblockhash" : "000000000000023b6a46f950ef1ccd08519c2e26208d1af157c6e7fa541bd043"
}




just loop through vin and check your already sent transaction for dups.
anyway: i dont have a bitcoin node ready to check and i just copied it from the forum.
for anybody developing custom client software this should be easy, dont you think?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 07:08:43 PM
Sure, poll getblockcount, then what? Please show how easy it is to spot this.

Making custom Bitcoin clients, in general, isn't easy. It should be avoided unless it is absolutely necessary.

If you're asking a question like this, then you're simply not qualified to do this.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mightycount on February 10, 2014, 07:23:09 PM
Here is the link to the thread, where the patch addressing malleability was discussed:
https://bitcointalk.org/index.php?topic=8392.0

The whole MtGox goxing was only possible because:
1) They were issuing transactions with sloppy signature format
2) This was accepted by the network for some time
3) New bitcoin client with tightened rules was released
4) Their sloppy transactions started being rejected
5) Exploiters "fixed" those transactions
6) MtGox sloppy software didn't notice transaction went through
7) Mt-gox sloppy software didn't notice output's were spent (making them unaware that they lose coins). It didn't even lock outputs which are used in pending transactions!!
8) MtGox incompetent customer support resubmitted transactions manually without looking into issue and alarming developers. Or maybe they did, but developers were too busy/confident/not able to fix the problem.

Overall: MtGox are incompetent bunch of liers


To be fair, the "workaround" implemented by Gox following a core dev recommendation, was horrible. Staging transactions is much worse than the initial "bad sig" problem, IMHO.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 08:18:53 PM

Someone please show me how to do this easy check with a few bitcoind commands?

when a new block arrives get it with rpc and look through the json output?

Sure, poll getblockcount, then what? Please show how easy it is to spot this.

Code:
$ bitcoind getblock 000000000000010c5ba86d05c6f43df46921d453d23fdafe85229f6a7d840e16 '{"tx":"obj", "script":"asm"}'
{
    "hash" : "000000000000010c5ba86d05c6f43df46921d453d23fdafe85229f6a7d840e16",
    "confirmations" : 43,
    "size" : 1473,
    "height" : 186154,
    "version" : 1,
    "merkleroot" : "47de80c28529a69bddefb90ea15388f10e2647482560bb50857e7b586d45a8c3",
    "time" : 1340614357,
    "nonce" : 728350342,
    "bits" : "1a09b78a",
    "difficulty" : 1726566.55919348,
    "tx" : [
        {
            "txid" : "11af9ba807942f7db6274f40442651c7b58b02b0a942867847b2b8a3932df7b1",
            "version" : 1,
            "locktime" : 0,
            "size" : 142,
            "vin" : [
                {
                    "coinbase" : "048ab7091a027702062f503253482f",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 50.00000000,
                    "scriptPubKey" : "04b034ecbcbe86f327d2edd25ce1fce3f4463710c00ae00d1a25198bab882be95c72d3468dc6931f756b03d99a3b7f3a07543834370ad023b37cb1127c6266d91a OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "9fb85b2c9085284a6c39407025cbec31b4c88b1075f3d98840395bc4e389616d",
            "version" : 1,
            "locktime" : 0,
            "size" : 259,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "1f16f657fb093f4618c1ad6504130d08fa71bb1964d0be5574f44011124f7b64",
                        "n" : 1
                    },
                    "scriptSig" : "3046022100dea86a40b8ffcfa446e05886e18c7ea8bca371118da48d4adfde846b87af43190221009652d86f7013afd35311fe8d080c9e592758716c08e971c39283ca08746db78501 04a1ce79a9fec1018129bb79c19dc90dcb4657e8cf725c635909ea402143b64e84fb06bf0b2c96ca6f0db9ac8ae480399f7724a9b288faf52c16d1535f13b90fe6",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 1066.13121507,
                    "scriptPubKey" : "OP_DUP OP_HASH160 e51a349be7044a8d84c6e8370ff56ff6860f3597 OP_EQUALVERIFY OP_CHECKSIG"
                },
                {
                    "value" : 1242.21306062,
                    "scriptPubKey" : "OP_DUP OP_HASH160 51fb66b01bcdbcdc67049fa97a8da21a2fa912e0 OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "060cbd899b2c1fac0cdbcf580a3f90aae131b16d516f049baf1d13c66e410892",
            "version" : 1,
            "locktime" : 0,
            "size" : 226,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "f2b6efbef50c026efc19dac73ed787b0ccc1697c8640e96637ab861e85afca60",
                        "n" : 0
                    },
                    "scriptSig" : "3045022100a0be436cb85b899740792206a17658ef96e6d786e53448cab8b11f9e51be96a6022063ab6d9337fa71b9d5a75e3ebe0a33c151ad6cdca70f9170c1b0297d655c5b3301 022cb39adb02162270b89b08975256293182bcaa84622d18a30c3bd72751d4ddd5",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 1.40018289,
                    "scriptPubKey" : "OP_DUP OP_HASH160 d6211f74851b1cc1d181d0fe591445a18f49c818 OP_EQUALVERIFY OP_CHECKSIG"
                },
                {
                    "value" : 1.00000000,
                    "scriptPubKey" : "OP_DUP OP_HASH160 713c581950bbfb0545f1418bbfe825911e8efa5c OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        },
        {
            "txid" : "2da6e2a83abe9e870a3a4762d8159e523a3068cce26c5670afdcd2c63486a1ac",
            "version" : 1,
            "locktime" : 0,
            "size" : 765,
            "vin" : [
                {
                    "prevout" : {
                        "hash" : "9aa47d859bda3eba62fd366461adda78f6df3293dd7b1681361f54531220b378",
                        "n" : 2
                    },
                    "scriptSig" : "3046022100f10d0f6fc6ce90ae97a04627a659791b1caed48aae8d70b82c73c5c730758576022100aba76d54166189b50e678faac63a4265d6d2daf48889a23a1fc285e042fb9c8901 04addfdfd09989768bc93678fd4eca1bf8d485e98690b7584a7559ab30a63ac16fd33e8e7db59f72c21b402a78bacbde205d642e60037d8b660a57341a60c4e646",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "125ea4a6f9e86333de7566af28e6a5558a2c66e5c41b197560bd9a8e6c56866b",
                        "n" : 0
                    },
                    "scriptSig" : "3045022100c9e3d69de5bcbb9252b2b637e6846eaef971959653c887e7bb13f6528f1587f2022059d47b80f98460c0a02a9f7a7977202533fe3566a1cbecc599b122af02a8b8ac01 04a875f1a901e23be1435350f1a94820f84f590e297c0a34e393b873ac5b3182d071ca43890a54c750ad2fd6288416a319e70e48f2c2d2fe828666cfc98689ce0e",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "e2b9a62cd1ad312f510510bf071ae0079b6b858db8b43e86809b7269d8ad1ff7",
                        "n" : 1
                    },
                    "scriptSig" : "3045022100a198dea14374a5d0584cfedeb8f6a457556b9bdd0488c433b179ad328a007c7102200a3179f1b8a95ae4e02183c25fb3234f1efe0db9129806d38579b2845e77a11801 047b19a9c3e6b0a92e9bdeeb294ebea709dd1d9b5e2ccb7e1fb03ca6bfa43b78dd0a6d72ddd9e64130513d63dc1ea5609906a15f1d3044f50ee6415b2e4eaf59e4",
                    "sequence" : 4294967295
                },
                {
                    "prevout" : {
                        "hash" : "b6548149a182fd10330b9f69024bdd55ce521ce367e9125d1bd8c91a8c5539da",
                        "n" : 0
                    },
                    "scriptSig" : "30450220670628b426d996131f064bb861554e31bd3afcdc581ae9824af1610dcc079080022100d240e2f445670f8e2be82f5fc74dfbc98312f0adb5f2ec163449588bdd8e9f8401 045c7e935730d0a7e45615e4a5df7c50b8bdde7fad7c978c569563b5451a756710d7dc0f1a248bd233467f17dd28e27484a91c0af4123c131b87d959dd37850692",
                    "sequence" : 4294967295
                }
            ],
            "vout" : [
                {
                    "value" : 0.19950871,
                    "scriptPubKey" : "OP_DUP OP_HASH160 c6b92e0b69d3a7aa53a28e2bc5a6de3f32fbff5a OP_EQUALVERIFY OP_CHECKSIG"
                }
            ],
            "confirmations" : 0
        }
    ],
    "previousblockhash" : "00000000000006d68b5d22acef2a43b38dc692782d7c12c0ae43259b9eb46078",
    "nextblockhash" : "000000000000023b6a46f950ef1ccd08519c2e26208d1af157c6e7fa541bd043"
}




just loop through vin and check your already sent transaction for dups.
anyway: i dont have a bitcoin node ready to check and i just copied it from the forum.
for anybody developing custom client software this should be easy, dont you think?

Parsing whatever bitcoind spits out is easy, yes, custom bitcoin clients are not or github would be full of them. All that's left from my sendtoaddress is a txid, please, someone claiming how easy this is show me how to spot this.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 08:23:15 PM
That is the point.  Custom bitcoin clients are NOT easy.  Unless you know what you are doing you probably should NOT be making a custom bitcoin client.  

As much money as MtGox has made over the last four years they could have hired someone who knew what they were doing but install hack together a client which is non compliant with the reference implementation in at least half a dozen areas (who knows how many others as the source code isn't public so we can only observe the fail from the outside).  This is the same MtGox which has no development server and just makes changes to production live so they decided getting the implementation of a mission critical component which involves the transfer of money, "close enough" was an acceptable standard.

A compliant client should not:
a) violate spam rules
b) pay less than the min mandatory fee (well a business client where users expect timely payments shouldn't)
c) send immature (less than 120 confirmations) newly generated coins
d) double spend its own "coins" (use outputs which were already spent in a prior tx)
e) use non-canonical signatures
f) rely only on tx-id as absolute proof on if a payment has been made or not

The "Gox Special" client did all of those, and who know what else.  It would be like building a jet airline by copying a photo of a jet you once saw, and being surprised when someone dies because "well it looks kinda like a jet, the engines are pointing the right way, and it has some wings and stuff".  Who possibly could imagine that slapping together some random parts so it looks like a jet wouldn't actually be a functional, safe jet?

Like cryptography, if you "roll your own" bitcoin node, you have to get it EXACTLY RIGHT.  Not kinda right, not mostly right, not hey it does sometimes push tx the network doesn't reject but absolutely right down to every single detail.   Most entities (companies and individuals) should not attempt that.  They should build off existing proven clients.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: justusranvier on February 10, 2014, 08:33:04 PM
As much money as MtGox has made over the last four years they could have hired someone who knew what they were doing
There are companies who do know what they are doing offering to send a team of coders to Japan to fix their problems free of charge, just because of how much damage Mt Gox is doing right now.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 08:53:04 PM
That is the point.  Custom bitcoin clients are NOT easy.  Unless you know what you are doing you probably should NOT be making a custom bitcoin client.

There is nothing custom about doing bitcoind sendtoaddress and getting a txid back.

f) rely only on tx-id as absolute proof on if a payment has been made or not
[snip]
They should build off existing proven clients.

So, then how do I easily spot this with a reasonably recent standard client?


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 09:11:32 PM
MtGox's problem is not "malleability", it's the fact that they didn't submit transactions to the network, at the same time making internal hashes public. The answer to Mr. Karpiles from the core development team should be clear and resounding "NO". Bitcoin is fine as is and MtGox should pull their $#!+ together. I could not believe the idiot dared to blame the Bitcoin protocol.

Bitcoin doesn't have to change one bit to come up with a standardised way of making these kind of hashes. I prefer we all come up with one that has a fighting chance to get included in the bitcoin client (not chain!) than every cat and dog inventing their own transaction numbers.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 09:47:19 PM
So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.

Code:
getrawtransaciton <txid>

This will give you the raw tx details in hex.
 
Code:
decoderawtransaction <rawtxhex>

This will give you json representation of a tx.

You can do your own parsing of the raw hex or you can feed the hext into decoderawtx.  Either way you now have the details of your payment.

For example (tx pulled randomly from the blockchain)

Quote
getrawtransaction da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270

01000000026b7a832578be08083147c5b5734b359b2c04c552d8dda3c0b3eef007f852d5ac01000 0008e4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f 065a02207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d410 0049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5 b0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68cffffffff57a11702d068380603e e9c71d97a280d4d8ef34c46443034de3095fbbcef7ee8010000008e4d4700304402202ada2194c1 f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a34637ce86dacc835603 088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b13e7ae7f4a7a9942c3a2998c8 e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e6291615fed8b3ef67a5a2fc7971 70db7028710d0cdb0e18cb5ffffffff02f0076606000000001976a91472e57193b8672cd0875adc 9c0264ca6fa15e3e4688acf7641800000000001976a91404157cfd60177f4fa31c7572d7f5fe14a 8f7930d88ac00000000

decoderawtx 01000000026b7a832578be08083147c5b5734b359b2c04c552d8dda3c0b3eef007f852d5ac01000 0008e4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f 065a02207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d410 0049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5 b0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68cffffffff57a11702d068380603e e9c71d97a280d4d8ef34c46443034de3095fbbcef7ee8010000008e4d4700304402202ada2194c1 f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a34637ce86dacc835603 088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b13e7ae7f4a7a9942c3a2998c8 e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e6291615fed8b3ef67a5a2fc7971 70db7028710d0cdb0e18cb5ffffffff02f0076606000000001976a91472e57193b8672cd0875adc 9c0264ca6fa15e3e4688acf7641800000000001976a91404157cfd60177f4fa31c7572d7f5fe14a 8f7930d88ac00000000

{
"txid" : "da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b",
"vout" : 1,

"scriptSig" : {
"asm" : "304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f065a02207bf efc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f3101 049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5b 0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68c",
"hex" : "4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f065a0 2207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d41000497 63964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5b0fa2 de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68c"
},
"sequence" : 4294967295
},
{
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157",
"vout" : 1,

"scriptSig" : {
"asm" : "304402202ada2194c1f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a3 4637ce86dacc835603088b3519fb9c419c77b79b4084a554b55487f803e8e01 04b13e7ae7f4a7a9942c3a2998c8e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0 e6291615fed8b3ef67a5a2fc797170db7028710d0cdb0e18cb5",
"hex" : "4d4700304402202ada2194c1f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d61300 2200a34637ce86dacc835603088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b1 3e7ae7f4a7a9942c3a2998c8e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e629 1615fed8b3ef67a5a2fc797170db7028710d0cdb0e18cb5"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 1.07350000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 72e57193b8672cd0875adc9c0264ca6fa15e3e46 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91472e57193b8672cd0875adc9c0264ca6fa15e3e4688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1BUWttqJ7gNNhqfYF8rjVpYBPj735PVhRQ"
]
}
},
{
"value" : 0.01598711,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 04157cfd60177f4fa31c7572d7f5fe14a8f7930d OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91404157cfd60177f4fa31c7572d7f5fe14a8f7930d88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1NbSoCQiHQCuJc7jPn4SuNXu2xrkyvrWs"
]
}
}
]
}

These RPC call(s) can be made at the time the payment is made and stored.  The bolded part is what we are interested.  You can save the full output but this is the minimum information you need.  Lets imagine tx da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270 was a payment from MtGox to a customer.

The payment to the user was made using two inputs:
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b", "vout" : 1
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157", "vout" : 1

Note this is all we care about.  The amount of the inputs are not needed.  If these inputs are in are found in a tx to the user in a block regardless of the tx hash then the user has been paid.

So before MtGox pays the user again they need to verify that these outputs don't exist in a tx in any block since the tx was created.

How do to that.  Well here are two options (there likely are more):

Method 1: Scan all tx in all blocks as blocks are received.
Pro: you get realtime status of mutated txs.
Cons: it is probably more resource intensive then it is worth given the low rate that tx should be mutated in normal operation.

When bitcoind reports a block has been received, you pull the block details
Code:
getblock <blockhash>

You can then parse all the raw tx in the block using getrawtransaction and decoderawtransaction.  If any of the tx have the same inputs from your payment tx then the tx is confirmed, update your records to reflect that the hash is changed, and also flag the tx as having been "modified" after being sent.

Personally I wouldn't even do this because in my experience mutated tx are insanely rare under normal conditions but it is an option.

Method 2: Just flag tx which don't confirm.  Don't send repayment until you validate flagged transactions.

At block time simply update tx based on tx hash.  This should get 99.9% of your tx.  Tx normally are not going to be modified.  Note this will never give false positives.  There is no risk in doing this.

Now some tx hashes may be modified but they should be rare so we can handle them in batches at periodic intervals (say every 24 hours).  Tx which don't confirm in some expected period of time (say 60 blocks) are flagged. 

Once a day do a "missing tx" check.
1) generate a list of blocks since the last time the check was run.
2) pull the tx hashes from the blocks.
3) get the raw tx and decode (either using internal process or using the decoderawtx RPC).
4) For each decoded raw tx compare the inputs (txin_hash and txin_index) of the decoded block tx to your list of "missing tx".

If you get a match the tx is not missing.  "Someone" likely the user mutated the hash.  So update your records to reflect the correct tx_hash, block#, and confirmation status.  Like in method #1 I would also flag the tx that it was mutated. 

Matching based on raw tx is slower than tx hash.  Since most tx are going to have same tx hash this is why I prefer to do this as a periodic job.  You can also run this job on a different server so as to not impact the load on the main tx server. 

The advantage of flagging tx (by eithe rmethod) is it provides you the ability to report on how often this is occurring and with which users.  If you have 10,000 tx in a month and only have 20 "missing" txs and of those 20, 18 involve a single user, you might want to drop that user, especially if he keeps reporting to customer support that he isn't "getting paid".  








Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phelix on February 10, 2014, 10:13:31 PM
I wonder if it would be possible to guesstimate the number of coins stolen from gox.

Probably there is somebody monitoring all TXs floating around through the network (blockchain.info). Maybe this data could be used to check how many Gox TXs have been modified. It would be very interesting to see the size of this issue.



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: killerstorm on February 10, 2014, 10:29:24 PM
The payment to the user was made using two inputs:
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b", "vout" : 1
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157", "vout" : 1
Note this is all we care about.  The amount of the inputs are not needed.  If these inputs are in are found in a tx to the user in a block regardless of the tx hash then the user has been paid.

One can simply record this information and wait until he gets complaints.

Normally there is no need to do anything. When a complaint is received, knowing inputs he can check whether these inputs are spent, and thus determine if complaint is valid or not. (If it is a valid complaint things become tricky, at that point consultation with specialists might be necessary as bitcoind won't just forget about wallet transactions.)

If you want an automatic sanity checker, the easiest way is to lookup spends of these coins via some kind of a block explorer API, in this case it might be just like a dozen lines of code. If you don't trust external block explorer, run your own ABE instance.

Processing block data like DeathAndTaxes described is also an option, but requires more code


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 10:41:04 PM
The payment to the user was made using two inputs:
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b", "vout" : 1
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157", "vout" : 1
Note this is all we care about.  The amount of the inputs are not needed.  If these inputs are in are found in a tx to the user in a block regardless of the tx hash then the user has been paid.

One can simply record this information and wait until he gets complaints.

Agreed.  There is no "one solution".  What works best will depend on the business needs and available resource.  The only way you get "robbed" is if you just look to see if a tx confirmed based on the tx id, and if it doesn't show then you pay the user again.  Even beyond mutability there are other (harder) ways this could be exploited.  A tx which doesn't get relayed to all nodes for example could get relayed to the attacker who saves a copy and once MtGox pays them again, directly broadcasts the tx to miners.  If one of them picks it up then the user could get paid twice. 

The simplest method would be as you said, to manually review tx which don't confirm and not assume that no confirmation when looking up by txid means it is safe to pay again.

Another way to prevent this would be for MtGox to pay THEMSELVES before paying the user "again".  If the user in this tx reported they hadn't been paid.  MtGox could create a new tx spending these inputs back to an address they (MtGox) controls.  If the complaint was legit then MtGox would be able to spend those coins back to themselves and then after that "refund" confirms would they pay the user again (or return funds back to the user's account).  If the user was lying and the had mutated the signature then MtGox attempt transfer the coins back to their hotwallet would fail.  Why? because it would be rejected by the network as a double spend of a outputs already spent in a tx in a block.  Although this method provides less "automatic information" it would have prevent a single satoshi from being stolen.

Yet another way would be for MtGox to delete the "missing tx" from their wallet and then check the unspent outputs list.  With the tx gone, in this case those two inputs should return to the unspent output list. If they don't then it is because the attacker has already been paid in a modified transaction  (Note I don't recommend using this method without testing).

Yet another way would be to have a business rule of only using the same inputs when making a duplicate payment attempt.  This would ensure the user couldn't possibly be paid twice as that would mean both copies of a double spend were included in a block.

So there are a lot of ways (with differing degrees of reporting, complexity to code, and advantages).  The only thing you absolutely can't do is to naively "check tx id, yup not confirmed let me make a new payment to the user".  


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phzi on February 10, 2014, 10:57:15 PM
So, shall we speculate how many bitcoins MtGox lost when someone realized they were not checking their txouts properly?  Could be 1000s of BTC.  But, I bet it was nothing at all... MtGox just screwed up on how they track their txouts, and re-spent txouts that were already spent.  Cross fingers the next announcement isn't MtGox has lost your bitcoins (which would probably be yet another lie)...

Bitcoin wiki: "assuming a txout exists because the client created it previously is unsafe." Obvious MtGox failed to heed this advise...  This is MtGox stupidity plain and simple.  I hope anyone still using MtGox (god knows why) withdrawals everything as soon as they have the opportunity (presuming they ever re-enable withdrawals).

I also think it is high time the Bitcoin foundation removed MtGox's member status and kicked out their failing leader (if you can even call him that).  Badmouthing the bitcoin protocol because you have a faulty inplementation with a lack of checks and balances is ridiculous and should not be acceptable to the foundation or the community.  I would say the foundation's credibility is severly at stake here.

Transaction maliability is not a 'defect'... it is a known and published reality of the bitcoin protocol.  Txid's identify a transaction reliably _after_ it is included in a block.  Using txid as an identifier to track your txouts is beyond stupid.  (Which must be the case if MtGox was trying to re-use txouts that where previously spent but confirmed with different txids).


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 11:19:03 PM
So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: DeathAndTaxes on February 10, 2014, 11:25:49 PM
So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).

In theory you don't need to save more than just the txid, you should be able to look it up the rest as/when needed.  However I didn't code bitcoind, I don't know every event which could result in it repository changing.  As someone with a background in enterprise "database/backend stuff" (official title) that doesn't leave me with a happy feeling.  I don't like the idea of relying on data which a third party (bitcoind) has direct access to.  If I put the data in a repository and strictly control access then it makes for a more controlled environment and that makes me more confident that there will not be any unexpected changes.

It may not be necessary, I just have never traced every possible condition that might result in the bitcoind changing information in the wallet that I may be unaware of.



Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: wolongong on February 10, 2014, 11:50:27 PM
So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).

In theory you don't need to save more than just the txid, you should be able to look it up the rest as/when needed.  However I didn't code bitcoind, I don't know every event which could result in it repository changing.  As someone with a background in enterprise "database/backend stuff" (official title) that doesn't leave me with a happy feeling.  I don't like the idea of relying on data which a third party (bitcoind) has direct access to.  If I put the data in a repository and strictly control access then it makes for a more controlled environment and that makes me more confident that there will not be any unexpected changes.

It may not be necessary, I just have never traced every possible condition that might result in the bitcoind changing information in the wallet that I may be unaware of.



Maybe this can help a little if there are no gaping holes in it https://github.com/sipa/bitcoin/commit/1173eef630783a822d9a709cfbc22ba91880231e
Now sendtoaddress just returns an id for what you did that might be altered by the distributed bookkeepers before being fixed into the ledger.
This getnormalizedtxid seems to give you something short to recognise your tx back no matter how long someone put in on an anvil and banged at it.

 


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mb300sd on February 11, 2014, 01:24:52 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phzi on February 11, 2014, 01:46:44 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mb300sd on February 11, 2014, 01:55:32 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phzi on February 11, 2014, 02:05:45 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.
Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mb300sd on February 11, 2014, 02:24:59 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.
Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.

1 more column in a table and a couple extra lines of code is overhead? Instead they cause a massive crash by blaming it on the bitcoin protocol.

But knowing gox they would have implemented it wrong on their production server and screwed things up worse.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: phzi on February 11, 2014, 02:58:56 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.
Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.

1 more column in a table and a couple extra lines of code is overhead? Instead they cause a massive crash by blaming it on the bitcoin protocol.

But knowing gox they would have implemented it wrong on their production server and screwed things up worse.
Heh, not saying their claim of overhead is reasonable, just re-stating it.

And yes... Gox seems full of fail right now.  I mean come on, throw a fix together and get your business going again, and then work on core protocol changes.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: jl2012 on February 11, 2014, 03:47:05 AM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

So this is essentially what gox is proposing


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 11, 2014, 01:16:44 PM
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

So this is essentially what gox is proposing

They are not even using reference client, why the hell they are fucking everybody's brain? Your system failed to track transactinos - so go and fix your system, and then go ahead and propose a patch in the reference client if you believe this is necessary/reasonable. I don't understand why core developers even take this seriously. That's like negotiating with terrorists - just encouraging them.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: hostmaster on February 11, 2014, 01:23:05 PM
Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"
Why to blame they make tons of money they can fix it by themself???


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mp420 on February 11, 2014, 01:29:22 PM
Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"
Why to blame they make tons of money they can fix it by themself???

I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: il--ya on February 11, 2014, 01:59:54 PM
I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.

I believe the reason they are doing that is because they simply don't have enough coins, and they are trying to win time under a false pretext and force their users to sell bitcoins cheaply (to them). They can then sell those coins somewhere else, and buy more, until they become solvent. No matter how shitty their developers are, they should still be able to fix their bug in some shitty way, which would be enough to restart "normal" operation. Also they could provide manual withdrawal option at a premium - but they don't do that. They simply don't have enough coins.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.

seems so..


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: mp420 on February 11, 2014, 02:15:21 PM
I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.

I believe the reason they are doing that is because they simply don't have enough coins, and they are trying to win time under a false pretext and force their users to sell bitcoins cheaply (to them). They can then sell those coins somewhere else, and buy more, until they become solvent. No matter how shitty their developers are, they should still be able to fix their bug in some shitty way, which would be enough to restart "normal" operation. Also they could provide manual withdrawal option at a premium - but they don't do that. They simply don't have enough coins.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.

seems so..

I don't think the insolvency explanation holds any water. Even if they have less money than their all deposits are worth, they still have huge amounts of BTC and fiat. And there's no way their day-to-day operations would lose money. They're actually still making a lot of money from the trading fees. And they would make even more money if they'd be wise enough to fix their buggy software.

On the other hand, I do not trust their (or actually, Mark's) overall technical or business competence at all.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 11, 2014, 02:56:29 PM
I don't think the insolvency explanation holds any water. Even if they have less money than their all deposits are worth, they still have huge amounts of BTC and fiat. And there's no way their day-to-day operations would lose money. They're actually still making a lot of money from the trading fees. And they would make even more money if they'd be wise enough to fix their buggy software.

On the other hand, I do not trust their (or actually, Mark's) overall technical or business competence at all.

+1 to that


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 12, 2014, 07:37:06 AM
A small exchange doesn't need an automated system to deal with tx mutability.  We don't.  That is because 99.9%+ of the tx will never be mutated.
We'll see who sinks and floats as other exchanges pick up the slack and grow.

I wish you and them all well, but I would be surprised if there aren't other noteworthy casualties.

Damn, looks like it happened

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

MtGox was just the first (and biggest) victim. And the wallet is vulnerable due to bugs as well

https://bitcoinfoundation.org/blog/?p=422

Looks like the devs and foundation finally decided to step on it and work together. Which is great.

As an aside, bitcoin is technology, not religion, it's not about what's right or wrong or who is to blame.
Technology is about moving forward, fixing bugs and delivering, once you get entrenched in finger pointing, you're losing the plot.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: ZephramC on February 12, 2014, 08:49:14 AM
Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 12, 2014, 10:05:18 AM
Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.

I hope they'll leave advanced scripts and automation out, those will likely introduce a lot more problems than they'll solve.

I'd rather see the focus on the basic "everyday" issues first: malleability, blockchain bloat, micro-payments / fees from dust, low performance of wallets with many transactions, etc.

At the current rate, blockchain bloat alone is enough to menace the distributed nature of the network.
Every time someone switches to a MultiBit-like wallet, the network loses a node and becomes more vulnerable.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: ZephramC on February 12, 2014, 10:12:57 AM
Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.

I hope they'll leave advanced scripts and automation out, those will likely introduce a lot more problems than they'll solve.

I'd rather see the focus on the basic "everyday" issues first: malleability, blockchain bloat, micro-payments / fees from dust, low performance of wallets with many transactions, etc.

At the current rate, blockchain bloat alone is enough to menace the distributed nature of the network.
Every time someone switches to a MultiBit-like wallet, the network loses a node and becomes more vulnerable.

Well, me too. I'd also rather see more pressing issues focused on first. But with keeping long time development in mind. It is easy to make some change now that will have to be undone in the future.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: fairglu on February 12, 2014, 10:21:04 AM
Well, me too. I'd also rather see more pressing issues focused on first. But with keeping long time development in mind. It is easy to make some change now that will have to be undone in the future.

Agreed. Undoing is often quite problematic, when it is possible at all.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: underhood on February 12, 2014, 07:07:47 PM
I just hope issues are really being worked on. From both sides Bitcoin and Gox/exchanges.

If it was just Gox I would say what the hell let them die. But now all exchanges are closing BTC withdrawals. And what I am afraid of is stubborn attitude from both sides. Gox saying Bitcoin guys need fix their stuff. Bitcoin guys saying Gox need fix their stuff when obviously blame is on both sides. This is very damaging for Bitcoin reputation and I think only way to save this terrible situation is cooperation... Fix transaction malleability on one side and exchanges fix their stuff too.

Otherwise this is going nowhere and we will watch Bitcoin die just when it gained wider acceptance, trust and people outside tech. circles started treating it seriously.


Title: Re: MtGox blames Bitcoin protocol problem for BTC withdrawal issue
Post by: vleroybrown on February 13, 2014, 05:21:32 AM
Its quite amazing the amount of denial a forum post can generate.  Qoutes of supposed expertise in subject areas that clearly now the posters whom many you might expect some level of expertise had no info to go on are rampart here.  Without the increased trade support synthesizing value at a higher confidence level, I image this issue would have driven the price down to under $200.  The resilience of the value at the moment is astounding but seeing the denial this forum go figure.  At what point will this real issue within bitcoin tarnish the short term potential value perspective of the holders when it does $200-400 range if that.