Drivechains work by utilizing a mechanism called a two-way peg (2WP).


Drivechains work by using a mechanism called a two-way peg (2WP). Bitcoins are transferred to sub-chains by sending and locking bitcoins to a special P2SH address. The sub-chain client observes the main-chain and sees when coins are transferred into a sub-chains client that the user controls. Once the coins are locked and a sufficient length of time has passed to make a Bitcoin reorg sufficiently unlikely, the coins may be used on the sub-chain.

The drivechains client does this using merged mining. In merged mining, drivechains miners work on the Bitcoin main-chain and sub-chains. The drivechains block is assembled first and hashed, with the hash inserted into the coinbase transaction of the Bitcoin block. (The hash will be ignored by the Bitcoin network.) If the Bitcoin difficulty is achieved, the Bitcoin block is assembled and sent out on the network. The drivechains block is then assembled with information from the related Bitcoin block, thereby proving that sufficient work was done to secure the drivechains. The first version of Drivechains uses the Namecoin merged mining algorithm. Future versions will use more advanced merged mining algorithms.

Drivechains rely on simplified payment verification (SPV) proofs to move coins from sub-chains back to the main-chain.

The drivechains client assumes the miner will be honest and will not attempt to steal any coins. To counteract this potentially dangerous assumption, withdrawals from the sub-chain are done infrequently so that drivechains clients can watch for miner fraud.

When sending bitcoins to sub-chains, coins are sent to a P2SH address under special “anyone can spend” circumstances. Miners agree, via soft fork, to not allow the coins to be spent unless special rules are followed. The universal drivechains address acts as a lockbox. Bitcoins go in and cannot be spent unless special rules are followed.

When sending coins back to the main-chain, the drivechains client creates a transaction that destroys the sub-chains coins and requests that coins be sent to a specific destination on the main-chain. Once the Bitcoin coinjoin transaction has been created, the transaction ID is included in the sub-chains block header. The coinjoin transaction is then included in the coinbase transaction of a Bitcoin block. Miners then wait a significant length of time before voting on the coinjoin transaction. If miners vote to accept the coinjoin transaction – miners are expected to confirm that the transaction has not been altered by referencing the sub-chain – the actual coinjoin transaction is included in the main-chain. The master drivechains address is then seen to send coins to the coinjoined destinations.

To prevent miners from redirecting the bitcoins to a destination of their choosing, a second soft fork is deployed. The soft fork requires miners to reference the sub-chains in question and ensure that the coinjoin transaction ID matches the transaction that is included inside a block. In the event of a mismatch, miners will refuse to mine on the altered chain.