Title: Hard Fork to Return Seized Silk Road Bitcoin to Ross Ulbricht Author: Satoshi Nakamoto Status: Draft Type: Standards Track Created: 2016-07-20
On October 1, 2013, an attacker exploited Ross Ulbricht’s Bitcoin wallet and drained 29,655 BTC from Ulbricht’s accounts. Later, the attacker drained an additional 144,336 BTC from the wallet, stealing a total of 173,991 BTC. At time of theft, this represented over 1.5% of the total bitcoins in circulation.
This raises a major security risk. The threat is not from the client protocol per se – but from the magnitude of the illicit redistribution of funds.
The attacker moved the stolen bitcoin to two different addresses: 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX and 1i7cZdoE9NcHSdAL5eGjmTJbBVqeQDwgw. The funds have been transferred several times since then. It is critical that this hard fork be performed ASAP to avoid the risk of further transactions before Ulbricht’s bitcoin can be recovered.
At a predetermined fork time, all unspent transaction outputs (UTXOs) originating from the attacker’s addresses (including UTXOs from subsequent transactions) will be compiled in a set.
A custom version number will be applied in the block header to identify this block for future validation. The block contains a single transaction that consumes every UTXO in the identified set. The custom validation involves bypassing the
The transaction will have two outputs. One output returns the total seized amount (173,991 BTC) to a Bitcoin address controlled by Ross Ulbricht. Because the total value of the UTXOs originating from the attacker’s addresses is necessarily larger than the original stolen value, an
extraBalance will be created as the second output. This balance will be used to compensate any “legitimate” transactions that may be affected by the fork. Tim Draper, for example.
extraBalance output is a multisig pubkey script. The pubkeys will be controlled by a group of trustees.
This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing the custom validation block.
Simplified Payment Verification software is also affected. This should be seen as a positive, because it gives every end user a vote. Anyone who opposes this change, or doesn’t know about it, or simply forgets to update their client software, can excise themselves from the network. Thus, hard forks are the most democratic means of consensus on earth today.