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?
Topic: Stats on malled transactions - page 7. (Read 17358 times)
Is there a way to calculate how many btcs were stolen through these malled / assumed malled transactions?
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 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?
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"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.
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.
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?
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?
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.
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.
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.
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.
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.
Pretty useless stuff for the attacker, but I can bet that some novice got scared by seeing two transactions instead of one.
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.The definition is not entirely correct as a malled tx is not a double spend.
If this trend continues wallets may have to abandon this practice until mallability issues have been resolved.
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. The definition is not entirely correct as a malled tx is not a double spend.
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.
What do you mean by double-spend?
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
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
Jump to: