[IMP] Malleability : Attack scheme

[thenoblebot]

I hereby propose the following scheme for an attack against an exchange/organisation using txid to track payments :

So if I was the attacker then this is how I would go :

1) Buy some btc with cash from the exchange
2) Try to withdraw it using malleable transactions (for this I would need to make some arrangements)
3) Claim I have not received it and try to get them to send it again
4) Repeat steps 1-3 using different ips and accounts using small amounts so as to make the trace hard to detect.

Attack successful. If not get more than the amount of BTC I should get, it will at least bring the exchange/processor to a halt.

Win win win !!

Or am I missing something ? Would like to know if this is possible from the core devs/experts ?

PS : Obviously this would be successful with an exchange/processor who is using txid for his system. Otherwise the above fails.

UPDATE : For a network level attack against such entities relying on txid see response below https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789

UPDATE 2 : I think this is the same situation described by the update above : http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CoinDesk+%28CoinDesk+-+The+Voice+of+Digital+Currency%29 . I'd really like to know if they are not the same. So basically the exchanges are/were delaying to counter such an attack, if I'm not mistaken. I'd really like to know if I am making a logical jump here, since of the devs (not gonna name him for ethical reasons/was a pvt conversation) would keep saying that this is far from the issue. I'd just like to know how.

[Amitabh S]

If I were to code an exchange, I'd use the tx inputs to track the transaction, not the tx hash. If I understand correctly, this cannot be attacked.

[thenoblebot]

If I were to code an exchange, I'd use the tx inputs to track the transaction, not the tx hash. If I understand correctly, this cannot be attacked.

Yes thats why the PS note above, but I am afraid given Gox's reasoning in spite of being the oldest in the business. I am certain if Gox was actually following the system, then a whole lot of other smaller ones might possibly be following a similar scheme of things. So it could still be used against those as the OP states, isn't it ?

[cr1776]

If I were to code an exchange, I'd use the tx inputs to track the transaction, not the tx hash. If I understand correctly, this cannot be attacked.

Yes thats why the PS note above, but I am afraid given Gox's reasoning in spite of being the oldest in the business. I am certain if Gox was actually following the system, then a whole lot of other smaller ones might possibly be following a similar scheme of things. So it could still be used against those as the OP states, isn't it ?

Gox is done for if they don't get this act together very quickly (and probably even if they do).  They have a solution that can implement (perhaps they are not able to do so, but it is there), they can either fix it and resume withdrawals, or they can sit on their hands, blaming other people and evaporate.  They have burned so many bridges with their blame game that I find it hard to believe people will be bending over backwards to help, and using them in the future.

I doubt this scam would work on any competent exchange because it has been so widely exposed now, no one would fall for it.

One question, do you usually refer to yourself in the third person?  You are the OP!

[thenoblebot]

Gox is done for if they don't get this act together very quickly (and probably even if they do).  They have a solution that can implement (perhaps they are not able to do so, but it is there), they can either fix it and resume withdrawals, or they can sit on their hands, blaming other people and evaporate.  They have burned so many bridges with their blame game that I find it hard to believe people will be bending over backwards to help, and using them in the future.

I doubt this scam would work on any competent exchange because it has been so widely exposed now, no one would fall for it.

One question, do you usually refer to yourself in the third person?  You are the OP!

1. This is not about Gox. This question is about the protocol and about the exchanges/processors still using the txid methods. So this is a viable attack mechanism for those. And as the present scenario suggests it should be a big percentage.
2. OP=Original Post , also, So no unless I am in my grandiose dreams I usually dont, in that case I call myself "your highness"

[mightycount]

Well if I was the attacker then this is how I would go :

1) Buy some btc with cash from the exchange
2) Try to withdraw it using malleable transactions (for this I would need to make some arrangements)
3) Claim I have not received it and try to get them to send it again
4) Repeat steps 1-3 using different ips and accounts using small amounts so as to make the trace hard to detect.

Attack successful. If not get more than the amount of BTC I should get, it will at least bring the exchange/processor to a halt.

Win win win !!

Or am I missing something ? Would like to know if this is possible from the core devs/experts ?

PS : Obviously this would be successful with an exchange/processor who is using txid for his system. Otherwise the above fails.

No, if the exchange immediately broadcasts *all* transactions to the network. Which is all of them, except MtGox. Which is no longer an exchange, anyway.

[thenoblebot]

Well if I was the attacker then this is how I would go :

1) Buy some btc with cash from the exchange
2) Try to withdraw it using malleable transactions (for this I would need to make some arrangements)
3) Claim I have not received it and try to get them to send it again
4) Repeat steps 1-3 using different ips and accounts using small amounts so as to make the trace hard to detect.

Attack successful. If not get more than the amount of BTC I should get, it will at least bring the exchange/processor to a halt.

Win win win !!

Or am I missing something ? Would like to know if this is possible from the core devs/experts ?

PS : Obviously this would be successful with an exchange/processor who is using txid for his system. Otherwise the above fails.

No, if the exchange immediately broadcasts *all* transactions to the network. Which is all of them, except MtGox. Which is no longer an exchange, anyway.

In that case the attacker could screw the exchange/service even more. Use the same logic but for *all* transactions.

[gmaxwell]

The only safe way to reissue a transaction is to double-spend the original transaction in progress. This eliminates the entire class of user-got-paid-twice vulnerability. To do otherwise is insane: You're giving someone a check, and then a second check— and never canceling the first.

[kano]

so ... is it possible to modify the script such that is has more rules that make the recipient unable to receive the coins in some circumstances now that transaction have available extra script operations?

[gmaxwell]

so ... is it possible to modify the script such that is has more rules that make the recipient unable to receive the coins in some circumstances now that transaction have available extra script operations?

No. The scriptpubkeys are under signature, otherwise you could just steal the output of people's transactions.

All of the mutants possible are functionally identical (ignoring the node-local rules that may refuse to relay some forms, and the txid).

[thenoblebot]

The only safe way to reissue a transaction is to double-spend the original transaction in progress. This eliminates the entire class of user-got-paid-twice vulnerability. To do otherwise is insane: You're giving someone a check, and then a second check— and never canceling the first.

Absolutely agree. But even then systems using txid for tracking purposes would fall prey to attack if the transaction happens to be modified (either intentionally or some software glitch for a set of nodes). Thus changing (rather invalidating) the hash. So this leaves a whole lot of (unsafe) businesses who rely on txid. I just think there should be an advisory of some sort for such people. Because if we do not then it will only take a medium size pool to change the every transaction such that the hashes of each are invalidated. Leaving such systems in a great mess as described above. I believe for a sufficiently motivated (not something above the reaches of a meduim sized pool) group, this attack is a fairly trivial one to cause disruption in businesses (at least the ones that continue to rely on txid).

[kano]

so ... is it possible to modify the script such that is has more rules that make the recipient unable to receive the coins in some circumstances now that transaction have available extra script operations?

No. The scriptpubkeys are under signature, otherwise you could just steal the output of people's transactions.

All of the mutants possible are functionally identical (ignoring the node-local rules that may refuse to relay some forms, and the txid).

Nothing to do with outputs being changed.
I'm of course referring to adding some sort of "multi-party-protocol" to the script or even writing a new one that uses all the inputs and outputs but ... doesn't allow the recipient to simply just 'get' the result?

[buffett]

The only safe way to reissue a transaction is to double-spend the original transaction in progress. This eliminates the entire class of user-got-paid-twice vulnerability. To do otherwise is insane: You're giving someone a check, and then a second check— and never canceling the first.

Absolutely agree. But even then systems using txid for tracking purposes would fall prey to attack if the transaction happens to be modified (either intentionally or some software glitch for a set of nodes). Thus changing (rather invalidating) the hash. So this leaves a whole lot of (unsafe) businesses who rely on txid. I just think there should be an advisory of some sort for such people. Because if we do not then it will only take a medium size pool to change the every transaction such that the hashes of each are invalidated. Leaving such systems in a great mess as described above. I believe for a sufficiently motivated (not something above the reaches of a meduim sized pool) group, this attack is a fairly trivial one to cause disruption in businesses (at least the ones that continue to rely on txid).

i really need advice on how to anticipate this malleability issue. we are using bitcoind. if we dont rely on txid, then what?

[buffett]

If I were to code an exchange, I'd use the tx inputs to track the transaction, not the tx hash. If I understand correctly, this cannot be attacked.

if i use bitcoind, how to get tx input when i make a transaction?  (what is tx input anyway?)

[thenoblebot]

The only safe way to reissue a transaction is to double-spend the original transaction in progress. This eliminates the entire class of user-got-paid-twice vulnerability. To do otherwise is insane: You're giving someone a check, and then a second check— and never canceling the first.

Absolutely agree. But even then systems using txid for tracking purposes would fall prey to attack if the transaction happens to be modified (either intentionally or some software glitch for a set of nodes). Thus changing (rather invalidating) the hash. So this leaves a whole lot of (unsafe) businesses who rely on txid. I just think there should be an advisory of some sort for such people. Because if we do not then it will only take a medium size pool to change the every transaction such that the hashes of each are invalidated. Leaving such systems in a great mess as described above. I believe for a sufficiently motivated (not something above the reaches of a meduim sized pool) group, this attack is a fairly trivial one to cause disruption in businesses (at least the ones that continue to rely on txid).

i really need advice on how to anticipate this malleability issue. we are using bitcoind. if we dont rely on txid, then what?

Hi,

If there is an urgent need to sent the transaction again then only double spend the transaction that you have originally spent (pointed out by Greg above).

[jaesyn]

I'm probably overlooking something:

If the ECDSA signature is only for each input of a transaction, and the hash of the transaction is malleable, then what stops a nefarious miner from changing the output script to pay to a different address than the sender intended?

[Amitabh S]

I'm probably overlooking something:

If the ECDSA signature is only for each input of a transaction, and the hash of the transaction is malleable, then what stops a nefarious miner from changing the output script to pay to a different address than the sender intended?

the signature is on all the inputs and outputs, One signature for each input. So 10 inputs =10 signatures

[thenoblebot]

Is this http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CoinDesk+%28CoinDesk+-+The+Voice+of+Digital+Currency%29 not the same situation being guarded against that has been described above (more specifically the original update) ?

Added update 2 above regarding the same.

[btc4ever]

I agree that a statement from the bitcoin devs regarding best practice when using bitcoind RPC api would be helpful.  I have read the various articles about malleability, and think I basically understand, but still a clear set of do's and don'ts would be appreciated.

In particular I have seen printed that bitcoind handles the malleability correctly.   But does that mean it is safe to store and reference the txid returned by sendtoaddress(), or not?

If not, then what is the correct procedure.   Something like:

txid = sendtoaddress( addr, amount );
details = gettransaction( txid );
timestamp = details->time;

key = addr + amount + timestamp;

Or what?


Quite frankly, to me as an outside developer watching this circus it seems like there has been a lot of finger pointing at mtgox when in fact the truth is somewhere in the middle.  There is a technical problem known about since 2011 that has not been fixed apparently because it never became a high enough priority and it meant that a lot of clients would have to be fixed.

The documentation of said issue is not exactly in your face.  For example, when reading about sendtoaddress() on several occasions I for one did not see any reference to this issue, or how to deal with it safely.   Is everyone that uses the bitcoin RPC API supposed to understand every detail of what happens under the hood?   That seems like a recipe for a lot of hidden problems...  not good in a global financial infrastructure.

I hope that now it is becoming enough of a priority, and the various clients will be fixed, and RPC users will be able to rely on txid soon enough.

Or maybe we already can, when using bitcoind and not an in-house blockchain parser we wrote ourselves during breaks from playing magic the gathering.

Like I say, clear as mud.

[thenoblebot]

Absolutely agree btc4ever .. a statement is most appropriate. But the negative side of this is to give Gox's version more credibility. I have spoken to one of the devs but he did not get my point, in spite of this being there quite a while before the so called "attacks" began. All I am saying someone should have taken notice (I don't even want any f**king credit for having posted it first as an attack - because that is what I was accused of when I kept trying to explain that this was a viable attack mechanism against entities relying on txid).

Coming to the problem as a dev perspective - either spend the same inputs twice if a payment does not go through first time or the more easier solution is to check for add,amt,time for a particular transaction.

The

txid = sendtoaddress( addr, amount );

would not work if the transaction (unconfirmed) gets mutated while being broadcast I believe. Cause that will change the txid to something else.

Hope that helps.