Topic: Working Around Malleability : Catching the culprit (if there is one) (Read 4337 times)

What do you mean?

Did you check out this guys analysis? http://www.righto.com/2014/02/the-bitcoin-malleability-attack-hour-by.html
It's quite interesting.

How about working on a banking protocol??

Bitcoin backed banking...That scalably governs an economy better than any country

Then it'd ensure Bitcoin stabilizes at a good value...

One has to catch the culprit at the very beginning..

Why not start the coin in front of everyone?? without letting them know enough to break the system

You would certainly need a modified client. How to distinguish malled TX from regular ones?  --> https://bitcointalksearch.org/topic/rfc-detecting-malled-transactions-463945

Sorry for the late update, I think the above scheme is sufficient for finding the culprit (degree of confidence). I have a few more simplifying details that could help the process though.

Yea went through the whole thread. Nice to see how he has used grep . Good work Jan.

HOWEVER

He is trying to attempt to put a number on the double-spends/mutated txs. While it is certainly insightful, it leaves us at the mercy of the attacker when they decide to attack again !!

The above scheme/attempt I have proposed can be put into place and the pool (I have a very strong feeling it is a pool) can be identified when the attack starts again.

I am thinking of a simpler variation of the above scheme which should not rely on a custom made client. Until now nobody has come forward to help so its kind of frustrating to be dropping your brains out over this, with hardly any sleep.

Ill try to post it as soon as it comes right in my (tired) mind.

He is running a custom node, he's looking for double-spend transactions, and mutated transactions are [incorrectly] being classified as double-spend transaction.

It was suggested that you can do this analysis with a regular bitcoind node; examine the debug.log for statements about transactions that weren't admitted into your node's mempool.

As far as I understand he cannot actually see that tx's have been mutated, he just measures double-spend attempt using some double-spend detector script. https://bitcointalksearch.org/topic/m.5090986

Nice. Good to see some attempts already underway. Thanks for the reply here.

A few questions though:

1)How did this person your quoting check for malled txs ? Did he run 2 instances and compare the txs they received or did he custom implement the node to accept duplicated mutated txs ?

2)If the attacker were a pool then I think the above method (OP) would have worked ... Because letting people know who are contributing to the pool would have surely taken away the network power of broadcasting for the rogue pool .. or am I missing some logic ? (If its not a pool then obviously the above scheme would not work)

3) Also any strategy if such attacks happen again ? (Assuming by then we still dont have a fix for malleability)

this

I like the idea of actively provoking the malled txs.

Note this is not a solution to the problem as for every guy you catch two will start doing the same!

For now it seems the attacker stopped, though:
Maybe some old dragon already got him (ddos).

I see its 20 mins before from now ..wonder if the title of my post was not so clear that he missed it  ... np ill let him know and ask him to go through this thread.

Someone proposes something similar to track the culprit nodes, here: https://bitcointalksearch.org/topic/m.5124279

Maybe its miners controlled by Gox ? Perhaps lending their story more credibility.

Maybe its some mining group who is being offered more money for mutating transactions ? Considering the risks posed by cryptocurrencies to conventional centres of power.

It is most likely to be a mining pool or else would be difficult to do it at the scale where exchanges are being affected.

Whoever it is ... its a group and once we zero in on the nodes (with a degree of confidence) doing this then we are in a better situation to handle the problem.

Why would a miner(pool) alter transaction ID's? They have (huge) investment at stake. Much more likely it is some well connected node that changes transaction ID's.

One difficulty I do see with this is - it will be difficult to track at what "point/instance" the transaction gets mutated and associate it with a particular pool. Need to think more   ......

Suggestion/Alterations to the above most welcome.

UPDATE : Actually it would work .. considering the pool would help it propagate enough so that the original txid would go through rather than the malleated one. Alteast probabilistically.

So this suggestion does not involve fixing the malleability problem but rather an attempt to find out who is doing it (if at all intentionally) :

Theory : The "malleated" tx only goes through if it reaches the node (or set of nodes) that solved the block. So we should, in theory, be able to identify if one of the major/small pools is causing this problem (coz it did not cause so much of a problem earlier so it appears to be intentional).

Make very small transactions (to save money of course) with BTC and submit them to well known pools (since https://en.bitcoin.it/wiki/IP_Transactions is no longer turned on we might need volunteers  or miners who could try this out from various pools or maybe even with a custom implementation). I believe (yea assumption) that some pool is doing this on purpose, and it may very well be (yea 2nd assumption) that it is being done by some of the seed nodes (due to connectivity).

The transactions above can (or some custom implementation - see Difficulty below) be done using something similar to bitcoind because it will give the original txid which will be of help to track down later and see if it has been changed.

For every transaction we do above, check if the amount has been credited to your own second address with the same txid. If it is credited with a different txid then that is most probably your culprit(s/pool) that is causing the problem.

I say most probably because the wiki https://en.bitcoin.it/wiki/Transaction_Malleability says that it is uncommon but possible. There are well known causes of malleability, so we can't be certain at first. Repeat the above process more and more to say with some degree of certainty that the given pool is the culprit. Just as in a court of law.

Difficulty : maybe that whichever implementation of the client you use could try will connect to many peers as in the protocol. Maybe we will need a custom implementation of the code to just connect to the seeds of well known pools. Basically the idea of only connecting to the seed nodes of one particular pool at one given time. Then do the same with other pools' seed nodes sequentially.

Action : And if we so happen to find the culprit then maybe the lead developer could use use https://en.bitcoin.it/wiki/Alerts for all to stay (stop mining) away from the pool (if we happen to identify it with some degree of confidence). This way the network propagation power of the pool goes low (not all out though) and consequently,so will the number of "malleated" txs, hopefully returning to as it was before this problem surfaced.

This is a very rough idea, but I feel it can be tried, so feel free to shoot me or correct me as it seems appropriate.

Something that could perhaps be of use conceptwise (im not a programmer so maybe irrelevant links but did help me with the above idea)
https://github.com/bitcoin/bitcoin/pull/3403
https://en.bitcoin.it/wiki/IP_Transactions