Stats on malled transactions

[Jan]

I am running a custom node that does real-time double spend analysis. I took a look at the log file over the last few days to see what was going on now that we have a lot of focus on malleable transactions.

Note that my custom node counts mutations on the same transaction as a double spend, which it isn't.

Detected double spends by date:

2014-01-29 470
2014-01-30 460
2014-01-31 460
2014-01-29 470
2014-01-30 460
2014-01-31 0
2014-02-01 39
2014-02-02 18
2014-02-03 97
2014-02-04 918
2014-02-05 461
2014-02-06 406
2014-02-07 769
2014-02-08 1260
2014-02-09 2618
2014-02-10 14576
2014-02-11 16960
2014-02-12 393
2014-02-13 219
2014-02-14 54

Needless to say that things got hectic yesterday with 14576 "double spends" which I am pretty sure are malled transactions.

We seem to be approaching the total number of transactions which is about 60k a day. So it seems that someone is having a lot of fun.

I will be changing my software to do real malled transaction detection to get some more accurate numbers.

Edit 1: added stats for 2014-02-11
Edit 2: added stats for 2014-02-12
Edit 3: added stats for 2014-02-13
Edit 4: added stats for 2014-02-14

[maaku]

What do you mean by double-spend?

[Jan]

What do you mean by double-spend?

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

[nibyokwy]

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

it will result in one though if the user has also tried to spend the change output of the original transaction that was voided by the malleable one. this seems to be happening quite a lot based on network chatter. probably because the client allows spending the change while it's unconfirmed.

[Jan]

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

it will result in one though if the user has also tried to spend the change output of the original transaction that was voided by the malleable one. this seems to be happening quite a lot based on network chatter. probably because the client allows spending the change while it's unconfirmed.

Correct. All wallets allowing spending unconfirmed coins-sent-to-self (bitcoin-qt included) are potentially affected.
If this trend continues wallets may have to abandon this practice until mallability issues have been resolved.

[Rampion]

Yes, those are very probably "mutated" transactions - I'm getting those "double spend attempts" on every and each transactions I've been transmitting since yesterday.

Pretty useless stuff for the attacker, but I can bet that some novice got scared by seeing two transactions instead of one.

[dexX7]

Hey Jan,

thanks for sharing. Is there a way to get those stats without any modifications from bitcoind? Would be nice, if you could keep this thread updated as it looks like the amount of attempted double spends still increases.

[nomailing]

These stats are really disconcerting.
The priority of the core devs should be to fix the malleability issue once and for all. It shouldn't be a problem to get a majority of the network to agree to some patch. I think everyone would agree that it would be good for Bitcoin to just disallow transaction malleability.

Also it would solve the problems with mtgox withdrawals. Of course, in principle, it is a bug in the mtgox wallet. But this shouldn't be the time to accuse each other. Just solve the issue in the protocol and everyone will be fine and we would all have a better Bitcoin after all this mess.

[Loozik]

2014-01-29 470
2014-01-30 460
2014-01-31 460
2014-01-29 470
2014-01-30 460
2014-01-31 0
2014-02-01 39
2014-02-02 18
2014-02-03 97
2014-02-04 918
2014-02-05 461
2014-02-06 406
2014-02-07 769
2014-02-08 1260
2014-02-09 2618
2014-02-10 14576
                ---------
                23 482 BTC stolen? all from gox?

[Jan]

Hey Jan,

thanks for sharing. Is there a way to get those stats without any modifications from bitcoind? Would be nice, if you could keep this thread updated as it looks like the amount of attempted double spends still increases.

I don't know how to get the stats from bitcoind, but looking into my debug.log I see a bunch of messages containing "was not accepted into the memory pool"
Many of those may be mutated transactions.
You can get a feel of how many there are by executing this (on a unix box):

Code:

grep "was not accepted into the memory pool" debug.log  | wc -l

In the meantime I can report that it has intensified. For today I have observed 16k "double spends", and there are still 9 hours left of "my today" (CET)

I will continue updating this thread as long as there is something interesting to report.

[Jan]

2014-01-29 470
2014-01-30 460
2014-01-31 460
2014-01-29 470
2014-01-30 460
2014-01-31 0
2014-02-01 39
2014-02-02 18
2014-02-03 97
2014-02-04 918
2014-02-05 461
2014-02-06 406
2014-02-07 769
2014-02-08 1260
2014-02-09 2618
2014-02-10 14576
                ---------
                23 482 BTC stolen? all from gox?

No. Those numbers are assumed transaction mutations on the bitcoin network over the last few days

[Loozik]

No. Those numbers are assumed transaction mutations on the bitcoin network over the last few days

Is there a way to calculate how many btcs were stolen through these malled / assumed malled transactions?

[btcinsight]

Two transactions with different hashes and with overlapping inputs.
The definition is not entirely correct as a malled tx is not a double spend.

it will result in one though if the user has also tried to spend the change output of the original transaction that was voided by the malleable one. this seems to be happening quite a lot based on network chatter. probably because the client allows spending the change while it's unconfirmed.

Correct. All wallets allowing spending unconfirmed coins-sent-to-self (bitcoin-qt included) are potentially affected.
If this trend continues wallets may have to abandon this practice until mallability issues have been resolved.

I had a similar issue about one year ago. I was using bitcoind offline to issue several transactions, and probably some were taking change from the previous ones.

Afterwards, I took all the generated txs with getrawtransaction and went broadcast them through a connected computer on blockchain.info/pushtx.

I then saw that some were refused due to already spent outpoints, and I think it might be the very problem you are talking about.

But as long as there is no real attack, just rescanning to reference the mutated txid for subsequent spendings should be sufficient right?

[Jan]

No. Those numbers are assumed transaction mutations on the bitcoin network over the last few days

Is there a way to calculate how many btcs were stolen through these malled / assumed malled transactions?

I can't think of a way to do that, and frankly I wouldn't care. It seems that someone is trying to mutate all transactions right now, not only those from MtGox.

[dexX7]

Is there a way to calculate how many btcs were stolen through these malled / assumed malled transactions?

This is not an useful stat to determine the amount of lost-due-to-whatever-reason coins and you'd need to ask the exchange or service provider for any data.

Don't worry, the amount of attempted double spends is irrelevant.

[Loozik]

Don't worry, the amount of attempted double spends is irrelevant.

Just trying to find out if the exchange I am using will go bust 

[dexX7]

I don't know how to get the stats from bitcoind, but looking into my debug.log I see a bunch of messages containing "was not accepted into the memory pool"
Many of those may be mutated transactions.
You can get a feel of how many there are by executing this (on a unix box):

Code:

grep "was not accepted into the memory pool" debug.log  | wc -l

This did not yield any result, however there are more than 58k appearances of "ERROR: CTxMemPool::accept() : inputs already spent" and 28k for "nonstandard transaction type" since Jan 07, 2014. Maybe I'll give it a try later and group those by date. Thanks.

[btcash]

This did not yield any result, however there are more than 58k appearances of "ERROR: CTxMemPool::accept() : inputs already spent" and 28k for "nonstandard transaction type" since Jan 07, 2014. Maybe I'll give it a try later and group those by date. Thanks.

Do you know where these  28k for "nonstandard transactions come from? Normal nodes do not relay them. At least that is what I thought.

[StarenseN]

following

[FoBoT]

is this the same issue being discussed about blockchain wallet TM spam?
bitcointalk.org/index.php?topic=459874.0

also this is the same issue?
bitcointalk.org/index.php?topic=459845.0

this spam will hurt credibility of bitcoin and it seems to be related with all the exchange withdrawal slowdowns?