Weekly Dev Update #64

THORChain Weekly Dev Update for Week 64, 05–11 Oct; Bitcoin Confirmation Counting, Midgard Updates, Multi-asgard tweaks.

THORChain

Published in

THORChain

3 min readOct 16, 2020

Summary

The team worked to bring Bitcoin to an internal testnet, as well as the necessary features to support a native chain.

Confirmation Counting

ConfCounting is the practice of waiting for a number of confirmations to take place before crediting a user’s deposit. For Bitcoin, this is typically 6 confs, which appears to come from a single 2012 paper on Double Spending written by Meni Rosenfeld. However, waiting an hour for a swap to take place from Bitcoin to another asset is untenable.

The solution is to delay swaps by a number of blocks that match their value in block rewards. The maths is simple, if a number of blocks create $X in revenue for miners, then over time (assuming an efficient market) then roughly $X is the investment required for an attacker to pull off a re-organisation of those blocks. More reading on this here.

Thus THORChain first counts the revenue per Bitcoin block (currently around 6.25 ~$70k per block), then seeks to wait an equivalent number of blocks before reporting a transaction, based on its size. This means, for the vast majority of swaps under 6.25 Bitcoin, they will be processed in a single confirmation.

This raises the question of *natural* re-organisations — where the network is naturally bifurcated with two competing blocks. Firstly, since THORChain has very good coverage of the network (each node runs their own Bitcoin node), it is unlikely that all nodes will be on one side of the bifurcation. Secondly, natural re-orgs do not undo transactions, so this does not affect what THORChain sees. The Bifrost can handle natural and recover from malicious re-orgs by posting in errata transactions to the state machine in order to socialise losses and return solvency if a malicous re-org would ever occur.