BitGo bug reveals patterns in Bitstamp transactions

Interesting - 6 months ago or so I was monitoring all transactions on a handful of altcoins' blockchains in regards to which transactions were going in and out of exchanges. Because the number of transactions per block were a number of orders of magnitude lower than bitcoin, it was far easier to keep an accurate index of which addresses belong to a given exchange without relying on a bug in BitGo.

I kept a running tally of coins in/out per hour, 6 hours, and day. I could with fairly high certainty predict most large dumps 5-30 minutes before they occurred (delay before deposit is confirmed) and then immediately sell myself while placing a buy order for 5-10% lower depending on the size of the deposit.

I also started tracking the exact deposit addresses being used - and more importantly, which ones get reused (a crazy high percent) - which let me correlate market behavior to an individual's actions. For example, address X just had a very large deposit. 6 blocks later, there is a market sell order placed for the exact amount deposited and this same behavior happens every time coins are deposited to the given address.

I can then basically add a trigger to automatically pre-empt the likely incoming dump with one of my own and then buy back for 5% less.

The biggest problem was the market cap and transaction volume was just too small to make much money relative to the risk. However if one could do this same analysis with bitcoin, it could be extremely profitable.

CTO of BitGo here. I wouldn't call this a bug, per se, but it's a known issue that we plan to fix. The BitGo API is agnostic where the change output(s) are placed -- this is just an issue with the client-side SDK.

The primary reason we haven't changed it sooner is that BitGoD (which Bitstamp uses), currently relies on the change output being last to determine which output of a transaction is change when listing transactions. This was needed due to missing functionality in our back-end transaction indexer which has been remedied in the last few weeks.

The other reason we don't consider it a huge deal is that, until there is much more adoption of multi-sig, it's still going to be relatively easy to determine which output is change (it's likely the only one that starts with a "3").

So what is "the change bug"? This article doesn't really attempt to explain it.

So, let me understand this. Blocktrail noticed a similar problem in their application "several months ago." But they didn't post anything about it then. Instead, they opted to fix it quietly for themselves and not share that knowledge with the community.

Then, an opportunity pops up to take a shot at a competitor and they jump on it. Sure, Blocktrail submitted a pull request, 48 hours ago.

This doesn't look very genuine.

While I am ok worth their not publishing this data, I would much prefer something on the lines of, "we will publish this data in 30 days once the waters have cooled down."

The data is in the blockchain. You can identify and fix the bug but this is still giving an advantage to the people who are going to compile this data for themselves.