Enjoy Sochi Spam Starting to Stick

My last post I talked a bit about the Enjoy Sochi block chain spam from February, and to my surprise I am coming back to talk about it again.  Despite the contribution of one kind reader, I still haven't been able to get my hands on any of the old unconfirmed transactions from the February spends.  Well, it looks like I won't have to because some new transactions have been generated, and they also have started to stick in the blockchain.

I'll spare you the tower of unconfirmed transactions and instead show a detail of some of the spends:

14 July 2014 detail of some Enjoy Sochi spam

What is astonishing is that some of these satoshis that have been sent out have already been spent.  Not everyone practices good coin control.

Another interesting tidbit comes in the dissemination of these transactions.  These spams were conformed in about three separate blocks:

Enjoy Sochi Spam Balance Early July 2014

The specific blocks are block at height 309657, 309740, and 310357.  If you drill into the coinbase of each of those transactions you get a pointer to a smaller pool at bcpool.io, with a web page title of GilHASH.io (which doesn't resolve at the moment).  This of course tells us nothing about the connection between the two, which could range from being in total cahoots to having a very liberal policy on accepting any and all transactions that fit.

What are the impacts of these transactions?

That someone would go through the effort to build these two towers, and then come back and make sure over 60 of the transactions clear (out of a little over 2000 possible) poses some interesting questions about scale and denial of service.  

First, if the whole tree were transacted at about 750 UTXO per transition, that would create over one and a half million new rows for the UTXO database, and would bloat it by about a third of a gigabyte (assuming that there are about 256 bytes per UTXO in the DB).  For a forensic database it is closer to a half a gigabyte of fluff when you include the back links.  That sounds like a lot except that the current block chain is about 20GB, so that would represent about 1-2% wasted from a single spam attach.

Second, this may have been designed to make "taint" calculations more difficult.  If every wallet had one more path to calculate that links increases the commutation time by increasing the number of paths to traverse.  Even if calculated in reverse the memory requirements can go up as well.  Although if you put some heuristics in your calculations (i.e. tell your code not to check for taint on sub-bit sized coins from a small list of spammers) you can avoid the combinetric explosion.

Finally, this has an impact on block propagation.  Each of the blocks containing the spam were each nearly a megabyte in size, which is the current network limit.  Some hashing pool are giving some pushback to generating larger block themselves based on the premise that they lead to longer delays verifying the block and (more critically to the miners) downtime in calculating what the merle root of the next block will be.  The longer the delays the higher the chance an orphan block race could start across the network.

But seeing unknowns like this pop up in the Bitcoin ecosystem is educational for all.  Who knows, this little experience might actually be a good thing.