Topic: [IMP] Malleability : Attack scheme (Read 5493 times)

Unless the bad guy has a lot of bitcoins whose value drops, due to the malleability !

Edit: Hmm. actually, maybe the bad guys found out that they win a lot more by dropping the price and buying now when price is low, than using the malleability to trick exchanges?

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 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.

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.

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.

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

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?

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).

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

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

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?

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).

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).

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?

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.

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

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.

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"

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!

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 ?

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.