Bitstamp Theft Change Addresses and Late Transactions

The coins in the stolen address are on the move, but at the moment (block 337938) they are in a closed system with no outside coins.  But there are some other interesting transactions to examine first.

When looking at the fact that BitStamp was hacked it is natural to immediately has how were they hacked.  With the information available I don't think we can give a definitive answer, and the evidence is a little unclear at the moment.  Assuming this was an outside actor there are two simple explanations: the private keys were stolen/leaked/compromised or the outside actor was inducing the BitStamp systems to pay him out.  However there are transactions that bring those two simple conclusions into doubt.

First, if this was simple key theft then why was the 1L2Js address generating change addresses that BitStamp was able to sweep into 1Jokt (that is presumed to be BitStamp cold storage).  Here's one address:

The b68738 transaction sent over 32 BTC to the theft address and created a change address 1BtGH with over 641 mBTC.  Less than an our later at transaction d1d835 a transaction placed exactly 10 BTC into the current BitStamp cold storage address.  The change address also peeled off into more cold storage transactions.  It is unlikely the thief was being nice and putting the coins back in the vault.  This happened two more times:

Transactions 2378aa and a8c199 both created separate change addresses and sent to the same theft address (which has since been swept up into another address).  However both of the change addresses were sept into BitStamp cold storage (and those change addresses also peeled into more cold storage).  Bit that's not the strangest part.  The 19C5D and 1BtGH addresses were not single use addresses.

The 19c5D address was an input to a theft transaction and there are still just over 10 mBTC sitting in an unspent output to 1BtGH.  The 1KPeo address is at the moment a single use address.  

Why on earth would the thief create change addresses that BitStamp could use to sweep the change into cold storage?  This is evidence in favor of someone inducing the BitStamp systems to pay out to a theft address.  But you would think that BitStamp would shut their old system down after a couple of days, and we wouldn't see any more large movements into the wallet except taggers and dusters. Except nearly 4BTC is not a dusting and tagging amount:

Over $1,000USD is a bit high for an address tag, and a bit high for misdirection. This coin was also generated after the thefts occurred, so it can't be a stray transaction that got lost in the network.  My best guess is that this was a deposit account for someone that didn't get the memo to stop depositing.  If this was a deposit address their last deposit was before the hack:

Then their deposit was used to tumble out some payment to another account prior to the attack as well. (BitStamp is reported to have it's own mixer/tumbler available for customer use.  I haven't used BitStamp and obviously can't open an account to verify at the moment.)

Better evidence of it being a long standing deposit can be seen with BlockTrail's summary of the address.  It is very spiky and goes to zero a lot, so it's not a long term holding address but a transactional one.

So the simple explanations are out the window.  The two leading explanations in my mind are that the theft stole the keys and the software and stood up their own instance of the hot wallet to do the theft, or that the compromised services at BitStamp are still up and running.  Either one of these could have been done by an inside agent or an outside agent.  Odds are BitStamp won't say much until the relevant law enforcement agencies has had their turn to examine the evidence.

Bitstamp Hot Wallet Theft - 2 to 5 Jan 2015

From 4 Jan to 6 Jan 2015 Bitstamp experienced a loss of nearly 19,000 Bitcoins from it's operational hot wallet (CoinDesk has a nice writeup about the issue).  A reddit thread identified what it believed to be the destination address for the stolen coins: 1L2JsXHPMYuAa9ugvHGLwkdstCPUDemNCf.  Evidence on the blockchain is consistent with this allegation.

First, this address was not seen prior to 4 Jan 2015, and within 24 hours it had amassed nearly a 18,000 BTC balance.

A graph of the transactions that involve the alleged address shows a lot of interaction between other addresses.

Older transactions tend to be to the right of this graph, and they form peel chains that in some cases are combined multiple times into one transaction.  It is interesting to note that some of the transactions form exact sums of the collected coins.  To the left of the graph we start to see some of the "dusters" putting dust amounts into the 1L2J wallet.

One of the concerns on the reddit thread was that the cold storage may be leaking.  If the address found in another comment is to be believed, then their cold storage is not leaking.

If anything coins are being moved into cold storage based on the uptick on 4 Jan 2015, so there is no evidence of a cold storage leak.

So how could this happen?  (Warning, baseless speculation follows).  There are two ways this could be done, first the private keys of the input addresses could have been leaked.  This would be consistent with their request to stop deposits.  The other possibility is that the attackers somehow are inducing their software to send all the bitcoins to an address of their choosing.

What would indicate private key compromise is continued activity and continued theft.  While we see continued activity on 6 January 2015 it appears to be of the "dust tagging" variety.  Consider this peel chain:

100 bits are peeled off four times from the same source address.  This is not consistent with the earlier transactions where the change addresses were single use interior addresses.

Second, there is evidence of deposit addresses not being cleared out after the bulk of the movements occured. Consider the address 18unRBGev1pkTo35zqCtCscSWUg4r9RNrh that looks to be a P2Pool payout address.

There were five deposits that were stolen durring the hack, but 2 addresses appear to be untouched on the 6th of January.  If the hacker had the private keys (along with bitstamp) then there would be a race to cash in those deposits.  If bitstamp was worried about a private key theft surely they would aggressively sweep it within the hour, instead of waiting nearly 8.

So why didn't BitStamp simply pull the plug the moment they were sure they were hacked?  Maybe they did and this was just the remaining transactions propagating through the system.  Or perhaps they were attempting to sweep what they could to their cold storage.  There was over 6,000 BTC of movement into cold storage near the tail end of the hack, representing $1.5 Million of value saved.

It could have been worse.

This analysis was performed when the blockchain was at height 337832, so any transactions after that block are not reflected in this post.

December 2014 FBI Silk Road Auction

Last week the FBI conducted it's second auction for the assets they seized from the "Silk Road" and "Dread Pirate Roberts."  The first auction was for approximately 26,000 bitcoins in June.  This auction was for 50,000 BTC.  This leaves 94,000 BTC to be auctioned off, likely in two more auctions.

This analysis was performed when the blockchain was approximately 334040 blocks high, so coins spent after that block will appear as green circles representing unspent outputs or "coins" as I call them.  The orange and yellow blocks are transactions, and the coins are the lines between the transactions, with earlier transactions above latter transactions, hence the tope end of the line is the output and the bottom part is the input.

FBI Bitcoin Stash

According to Forbes, the bitcoins seized from the "Dread Pirate Roberts" were spent to the address 1FfmbH...ppPH and were later moved to 1i7cZd...Dwgw.  This move was co-incident with the first silk road auction.  One coin held 100,000 BTC and the next over 44,000 BTC.

Sale to Bitcoin Investment Trust

On the 9th of December the Bitcoin Investment Trust announced via twitter that they won 48,000 BTC in the auction.  This announcement was made after they had received the coins from the FBI. On the day before the twitter announcement the presumed FBI stash started seeing a number of transactions consistent with this claim, so it will be presumed in this analysis that those coins went to the Bitcoin Investment Trust (BIT). The first transactions consisted of a series of "Bit Nickel" (0.05 BTC) transactions to address that would later hold larger value coins.  This occurred from blocks #333429 to #333433.

It is interesting to note that these test transactions came from both the $100k coin and the $44k coin from the June transactions concurrent with the first auction, not the transactions resulting from one of those stashed coins.  After those transactions were seen on the blockchian and presumably confirmed by the BIT the FBI then sent the balance of the sale in a single translation on block #33435. 

While it might be tempting to presume that the BIT controlled each of the paid out coins and did whatever the felt was appropriate the grouping of the transactions indicates to me they had some fiduciary duties they were fulfilling since each transaction below the initial payout tells a different story.  First let's look at the leftmost transaction.

This chain tells a very simple story of a small payout to 1M76b6...HjBS (which is a single use address at the moment), and then a movement into a p2sh address 39T3BB...goZL for the remainder.  The 39T3 address was topped off with another BTC from another thread that I presume to be sourced from the BIT, since that chain also fed the address we see in the second set of transactions.

Apart from a relatively small payout of about 147 BTC this group creates a very nice peel chain into the p2sh address 3LzDzK...7TJc.  This address has some significant holdings, with just under half of it coming from transactions not originating from this peel chain.  Presumably this is BIT cold storage, but I have nothing to pin that on other than intuition.  Finally the right two transactions tell yet a third story.

First, we see that one of the auction coins has yet to be spent after about a week.  The other 10K of coins went into a small (by this auction's standard) payout of 100 BTC and then the remainder went into a fairly complex series of transactions that this blog post won't go into.  Presumably it was the machinations of the BIT hot wallet, but it could have just as easily been a client putting their balance into a bitcoin mixer.  I have no way to tell on this one.

Sale to Tim Draper

According to Coin Telegraph Tim Draper won the remaining 2000 BTC in this auction.  We can see transactions consistent with this claim in transactions closely related to the BIT transactions.  This payout occurring after the transfers to the Bitcoin Investment Trust, so this also would bit the narrative that BIT's blocks were the highest bid blocks and were thus completely dispersed first.  Unlike the top bidder's sale the transaction went straight to a single address with no test transactions.  Perhaps BIT included that provision in their winning bid.  Howeve things worked out well for Tim Draper in the first auction without a test transaction and his proceeds represent less than a tenth of what he received last time.

Within a day the coin was the split into four bundles of 500 BTC a piece, ready for cold storage. This would have been 9:30 in the evening Silicon Valley time, so it could have been a transaction set up later in the day on the west coast. These were single signature addresses as opposed to the (presumably) multi-sig addresses BIT used. We shouldn't presume that these don't have multi-factor protections, it is just that those protections are not evident on the blockchain.

Conclusion

It is really interesting to be able to plow through the bitcoin transaction logs and identify the events that are being reported in major news outlets.  That is what I see as one of the greatest strengths of the blockchain: a publicly auditable record.  If only we could get some of those too-big-to-fail banks on a blockchain style ledger.  It might make it harder for management to shrug their shoulders and claim ignorance for what their rouge traders are doing.

Finally, I would like to apologize for the lack of updates.  Between my day job, a major conference, and several important family events my todo list ran much longer than my time and energy available.  But like a trail of breadcrumbs that the birds might eat, the trail will come in a very irregular schedule.

Reinvestment of Crowdsale Donations (AngelShares AGS Part 2)

Last week I wrote about the AngleShares AGS Campaign.  A 200 day pre-sale where every day 0.25% of the tokens were handed out based on that days bitcoin (BTC) donations.  A similar sale was conducted in what were initially called ProtoShares (PTS), resulting in a 50/50 split between protoshares patrons and bitcoin patrons.  One interesting finding was that the "buy daily from one wallet" purchasing pattern was evident in the transaction structures.

Reinvesting Shares

This week I present what I think is the most relevant finding: individuals who received compensation from the campaign used that compensation to re-buy into AngleShares.  Sometimes one specific payout went entirely into the reinvestment.  I was introduced to this concern by reading this post on bitsharestalk.org while researching the original crowdsales.  This forum is kind of the bitcointalk.org for AngleShares, ProtoShares, and BitSharesX. You should read the whole thread before or after this blog post.  It's a fun one.

In that thread only one direct re-buy was posted. In my analysis of the blockchain I discovered 5 distinct distributions that resulted in bitcoin being re-donated to the campaign.  There were a lot more transaction paths between the two, but once a transaction chain goes through a tumbler it takes a bit more analysis to prove that either side of the connection could have been possible, and then more analysis to determine how likely that connection is.  And all but these 5 connections didn't pass a simple eyeball test because the excluded paths were tenuously connected by a small BTC transaction interior to a tumbler network.  I also stopped examining connections that were more than 9 transactions deep.  At that point I felt the likelihood they were no longer controlled by the initial receiver was too high to warrant analysis.

Syncad/Keyhotee

The first connected transaction I found was the most obvious.  SynaptiCAD, who according to the spreadsheets were the contractors responsible for a piece of software called Keyhotee, took their March payment and after a couple of months started buying angelshares with it.

Keyhotee 12 Mar 2014 distribution

This graph shows only the first two buys.  There were a total of about 12 single bitcoin buys in this buy daily chain, and about 41BTC remains unspent at the bottom of the chain from their last buy on 6 Jun 2014.  This one is the most directly connected buy.

Hypertas

The four other reinvestments came through a company called Hypertas, which according to the bitsharestalk thread is a company responsible for the payroll and payments for some of the operational expenses.  They have posted a spreadsheet detailing the individual withdraws, which proved invaluable in validating my analysis.

The first connected payment occurred on 24 March 2014.

Angelshares 24 Mar 2014 Distribution Partial Graph

Hypertas controlled and split the bitcoin until a retainer was paid to Stan on 2 May 2014.  Stan then proceeded to reinvest most of the payment.  On 7 May there was a transaction that sent 4 BTC to some other transaction that I am fairly confident was not related to an angelshares buy, but a total of 5.93 BTC was reinvested.

On 11 May a second connected payment started, and it involved two separate accounts according to the spreadsheet.

Angelshares 11 May 2014 Distribution Partial Graph

The left branch starting with the 7f86af transaction was attributed to a "admin retainer".  The branch on the right ultimately was payed out to Stan.  The transactions highlighted in blue include inputs not from this payout.  I'll come back to this later.  Stan also payed out 8.03 from this transaction to another developer working on infrastructure and services for BitSharesX.  Although it's not clear why it came from Stan's coins.

On 31 May a third connected payment started.  This contains the transactions in question in the bitsharestalk forum.

Angleshares 31 May 2014 Distribution partial graph

This graph had two external inputs as well.  The 686d96 transaction had input from what I appears to be a tumbler/mixer of some sort, such as SharedCoin.  The 40ee80 transaction includes about a half a bitcoin from the previous graph, attributable to Stan.  Again this graph shows multiple operations payouts. The left belonging to the admin retainer accout (which has coins mixed from Stan at 40ee80).  The second belongs to Cason, who invests their entire payment over three days.

The final connected transaction discovered is from 24 Jun 2014.

Angleshares 24 Jun 2014 Distribution partial graph

This graph is very simple compared to the previous two.  Stan received a distribution with which he re-invested the entire amount over 7 days.  There were no external inputs or outputs.

It's All Connected

The kicker for all of this, of course, is that it is all connected. If we load all the hypertas graphs together we get one large map of Angelshares buys where the sources come almost exclusively from Angleshares distributions, with two small inputs form a daily buy tree that originated from a tumbler output.  Some of the reinvested buy trees combine BTC from multiple distributions.

Composite Angleshares/Hypertas reinvestment graph

If you read the bitshares thread you will see, after wading through a legal story, metaphor, and a picture of a greek ship, that there is an important public statement form Stan:

As for recycling of AGS, we have said we would not do that.  Period.  We have also said that once we pay employees or vendors for their services, the money is theirs to do with what they please.  It does not surprise us that people working in this industry would want to donate some or all of their earnings to the cause and we have publicly encouraged this from the very beginning. [https://bitsharestalk.org/index.php?topic=4958.msg65351#msg65351]

These graphs support the claim that it is the employees and vendors were the ones paying for the shares.  Stan did not come out and say that he himself had repurchased in the past and that he expected to repurchase in the future. But it should be noted that the transactions in the forum post were not related to any of Stan's purchases but belongs to Cason.  There is also no indication of how much external bitcoin the employees brought in either (the 0bb534 transaction indicates at least Stan brought in external bitcoin).  There is nothing necessarily illegal or unethical in these behaviors, it can be viewed using your salary to buy stock on the open market for the company you for.  Since this was an unregulated sale there were no requirements for aggressive reporting on purchases like this.

Conclusion

By analyzing the transitions in the bitcoin blockchain and combining that with publicly shared ledgers we were able to validate a claim made on a message board that reinvestment into a public crowd funding campaign was occurring.  The reinvestment appeared to be consistent with claims by the management that employees paying with bitcoin that was their salary or other compensation were responsible for the reinvestment.  One of the reinvesting employees, however, turned out to be the manager/officer making that claim.

There are also two points that need further clarification: what is the admin retainer account, and what happened with the 6b32ef transaction on 1 Jun 2014 where Stan payed for an expense attributed to Hypertas.  These seem benign, but are worthy of explanation from Stan and Hypertas.  [Edited to add: in the comments Stan clarified that the admin retainer goes to his wife for admin tasks performed, and the 6b32ef was Stan paying out of his own pocket while hypertas bitcoin wallet issues were being resolved, and he was later reimbursed.]

For my next post we will dive into college football and follow up on one of the entertaining stories from bitcoin's ride at the top of the market.

A Different Kind of Crowd Sale: AngleShares AGS Campaign

After last week's post on Ethereum and SwarmCoin I was tipped off by BitSharesHub to another interesting crowd sale: the BitShares AGS Campaign.  There are several facets to this presale, enough for two weeks of content.  This week I will focus on the crowd sale itself.

Structure

The structure of the crowdsale itself was very novel.  Strictly speaking you weren't buying anything, but you were making donations.  Based on the donations amount you would receive an appropriate portion of the tokens. I'll leave the legal analysis for the lawyers on that one.  That wasn't the novelty, the novelty was the distribution mechanism as well as the piggybacked BITX sale.

The sales itself resulted in two separate token issuances, one for BitShares AGS and one for BitShares X.  The distinction is quite involved, and their FAQ has all the details.  Shares were sold for both Bitcoin as well as ProtoShares (PTS).  This analysis only deals with the bitcoin side of the equation.

Bitshares has also been very transparent with their use of the donations received.

BitShares BTC Spent

This chart shows the cumulative amount of BTC spent from the donations address.  Each and every one of these downward dips in the chart is explained on a google docs spreadsheet.  The largest one day drop is the result of moving 2,200 BTC into cold storage.  The addresses for these cold storage draws as well as all other expenses are documented on the sheet so the shareholders can easily verify the cold storage is still there and that the other expenses went to the intended addresses for the intended amounts.

The chart of received funds shows a varied level of interest based on what was available for sale.  For the most part, the AGS shares were sold from 1 Jan 2014 (block# 278062 or so) to about 18 Jul 2014 (block# 311410 or so).  BitShares X were sold as part of the same crowd sale, but only up until 28 Feb 2014 (block#288406 or so).  Based on this overlapping offering the donations were front loaded:

BitShares BTC Received 

This chart shows only received bitcoin and does not include any of the spent funds. The bend in the curve occurs almost exactly at the moment the BitShares X tokens were snapshotted for distribution. You will also an uptick in the days leading up to the snapshot, corresponding to the announcement of the cutoff date, and then the buy rate levels off at a rate less than the initial sale period, which it sustains almost until the end.

Compare this to the cumulative coins received for SwarmCoin:

SwarmCoin BTC Received 

About a third of the SwarmCoin sales occurred in the first few blocks of public availability.  There was a slight uptick near the end but nothing like that initial wall of sales.  To me there is a rational explanation for this behavior: there was no distinction made in the SwarmCoin sale between bitcoin spent on the first day or bitcoin spent on the last day, all donations were equal during the public sale. 

The BitShares sale was structurally distinct, they paid out shares on a daily basis.  So a coin spent on day one or day two may have different values.  Based on this structure spending twenty coins on one day of the sale was almost certainly worse share wise than speeding one coin on twenty different days of the sale.  And many traders leveraged this specific "buy daily" strategy.  The would set up a pool to buy with and spend that over a number of days, either until they ran out of money, they lost interest, or the crowd sale ended.  Here is one transaction tree that showed one trader spending a fixed amount of coins from the same address on each day until the address was emptied.

Representative Daily Buy Tree

Many traders used this technique, as there are several of these towers in the transaction graph.  This is one of the shorter trees, and there are several some longer ones. I thought that this was one of the most interesting finding of all, that a particular trading strategy can be demonstrably and conclusively shown from blockchain data.

Conclusion

Usually when you do IPO type offerings you have pick two of the following three characteristics:  the total value raised, the total number of shares released, and the timeframe of the sale.  The SEC makes you attempt to hit the first two within a certain range, and fixes the last one to be a single point in time.  The market almost immediately shows how broken that thinking is, often by rewarding institutional investors. Mostly because one of the few reliable ways to comply with regulations is to engage in a "road show" of these institutional investors so you can establish the parameters and hit them.

Bitshares I feel made a good compromise to this structure by fixing only the total coins released and taking a unique spin on the timeframe of the sale. By allocating shares on a rolling basis the investors can be more sure of the size of their stake without the uncertainty of a long purchase window.  The downside is that when there is a material event that occurs during the sale (in this case the BITX snapshot), the value of the shares can take significant shifts to the downside as well as the upside.

This isn't my only significant finding.  Next week I have something so share that I found in the transaction graphs that is even more interesting than the "buy daily" trading pattern.

Also, if there are any other blockchain "events" you would like me to examine, send me a tip to my email (danno.ferrin@shemnon.com) or to my twitter account (@Numisight).  Currently I am only equipped to examine the bitcoin blockchain, but a particularly juicy tip may motivate me to improve my tooling.

A Tale of Two Bitcoin Presales: Swarm and Ethereum

One is done, and one has passed a major milestone.  One has a lot of bitcoin, and one has a whole lot of bitcoin. But the more interesting differences are under the covers of these two presales.  The two presales I am talking about are Swarm and Ethereum.

Swarm

Swarm ran it's first phase of the crowd sale from 17 Jun until 20 July.  A second phase was canceled based on feedback from early backers.They accepted payment via bitcoin and counterparty.  I will only be examining the bitcoin donations.

SwarmCoin fundraiser balance over time

One notable fact is that the input address was not created specifically for the fundraiser, either that or other parties were allowed to donate to the fundraiser before it was made generally available.  17 Jun 2014 (UTC) corresponds roughly to block number 306221.  This is where the large spike in donations occurred.  Note that there was a relatively quiet period on the donation address just before.  Donations ended on 20 Jul 2014 and no other donations have been seen.

Swarm coin appears to be either converting their BTC to fiat or storing their coin on an exchange of some sort.  Here is a representative donation graph (the 12GZL7... address is the SwarmCoin BTC exodus address).

Five Representative Swarm Coin purchases

Because the transactions are promptly gathered together into a transaction (usually with other than SwarmCoin addresses) and repackaged into other coins for other users, this indicates to me that some sort of an exchange is being used (although I am not sure which one).  The downside of this arrangement is it hides the real point in time balance of the swarm coin project.  The only people sure of their balance are them and their exchange.  This also shifts the security of the coins to the security of the accounts at the exchange.

Ethereum Phase 1

Ethereum started their crowd sale on 22:00 22 Jul 2014 and will continue through 2 Sep 2014.  The first two weeks were offered at a flat rate, and the remainder of the sale will see a gradual taper in the price.  The taper began on 6 Aug 2014.  This corresponds from blocks about 312027 to  314039.

Ethereum Pre-Sale through 5 Aug

Ethereum has quite a different shape than the swarm coin graph.  First, the balances are stored on the blockchain and are not siphoned off to some off-chain account.  This was done in the name of transparency.  Second, the exodus address had a whole lot less activity prior tot he sale.  Likely limited to software testing.

We also see that there are two distinct interest waves instead of one.  An initial wave over the first day or two spiked the sale up over 6000 coins.  A second, more produced wave near the ending of the flat sale occurred accouting for nearly half the crowd sale to date.

The transactions are all fairly boring.

The actual purchase transaction is in blue, with the two orange transactions belonging to the wallet the purchase came from.  The yellow transaction is done by ethereum.  One hundred bits are stored off into a constantly changing address and the balance is placed into the exedous address.  I am not sure why they set it up this way at this point.  The scripts on either side don't show any strangeness and are quite typical.  Perhaps we will see later or they are creating a pile of dust bunny coins to pay transaction fees with.

Since the balance is stored on blockchain the Ethereum crew is using an underused security feature of bitcoin: Multisig addresses.  The exodus address is 36PrZ1KHYMpqSyAQXSG8VwbUiq2EogxLo2, where the leading 3 means it is a pay to script hash address.  Because it is pay to script has the script needs to provide the script only at redemption time we don't know how secure the keys are.  To pay to one of these address we only need to know the address, not the content of the script that it pays out to.  Generally speaking these are multi-sig addresses, but they don't need to be.  For all we know the address is a pay to bearer script.

So until we see a coin cashed out of the 36PrZ address we won't know what the script is. Fortunately for us one such transaction has already been done in block 311815.  [I have yet to see a block explorer that decodes this properly, I will update that link to the first one who does]. From the script we can see that it is a 3 of 4 signature address, and I believe that the addresses are 14E2JwZLCEpKnjPuMsMciGLfBZ6no23skT, 159Hhu9oi9ti1X8fU8JN1SQAt7DVA8PgFR, 1LfztD3YYFrn3zjw1aQT3cGu3CjjZFq7q3, and 1KxmHFVLbfqWtTNpUQmDJdhhpGmyW8JBDH.  I may be wrong on the addresses, it appears a different (newer?) ECDSA curve is specified in the public key.

Conclusion

I like the way the Ethereum pre-sale is going better than the Swarm pre-sale.  My main reason is that they are keeping the balance on the blockchain where community members can audit it, rater than as some database row in an unknown exchange.  I know there are a lot of privacy advocates out there who want to strip the blockchain of all of the useful auditing abilities.  But there is too much value in a publicly traceable ledger of income and expenses.  Imagine if the Bitcoin Foundation shared publicly or with it's members the addresses of it's wallet.  That would go a long way to instill trust.

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.