Bridging Bitcoin To Avalanche: A Technical Overview

Earlier this week, we announced support for bridging native Bitcoin on the Avalanche Bridge. The Bitcoin bridging support leverages much of the same technology and design of the original Avalanche Bridge architecture over viewed here. Notably, there is a new Intel SGX (Software Guard Extensions) application designed to support cross-chain Bitcoin transfers. Intel SGX is a set of security instructions that enable the construction of private, tamper-proof secure enclaves. It is a key enabling technology that allows the Avalanche Bridge to execute securely without any one party ever having access to secret keys. The bridge application executing in the SGX enclave relies on an expanded set of third-party indexers and verifiers known as “Wardens”. The eight wardens securing the bridge are: Halborn, Avascan, Bware Labs, Ankr, Chainstack, Protofire, Blockdaemon, and Ava Labs. In addition to the Warden functions described in the previous Avalanche Bridge overview, the Wardens have now been extended to index the Bitcoin blockchain.

See how to bridge Bitcoin to Avalanche using the Core extension:

BTC.b

When Bitcoin is bridged to Avalanche, it is represented by an ERC20 token on the Avalanche C-chain with the symbol BTC.b. The “.b” indicates that the token was bridged from the Bitcoin network, just as Avalanche Bridge tokens bridged from Ethereum end in “.e”. Each BTC.b token is fully backed by a Bitcoin locked by the bridge enclave application. The BTC.b token contract can be found on Snowtrace here, and the bridge enclave application Bitcoin address can be viewed here.

Bridging Flow

To initiate bridging from Bitcoin to Avalanche, a transaction is sent on Bitcoin from the new Core Wallet that transfers BTC to the bridge address controlled only by the SGX enclave. The bridge is designed to only support Pay-To-Witness-Public-Key-Hash output types on Bitcoin. In order to ensure that the BTC transfer has this output type and meets all of the bridging requirements, users should always use the bridge UI in the Core Wallet extension that is built to provide a quick and easy bridging experience. Once this transaction is accepted into a block on Bitcoin and receives the necessary number of confirmations, it will be indexed by the Warden nodes and reported to the Intel SGX application for processing. The SGX enclave only processes transfers when it receives approvals from at least 6 of the 8 Warden nodes. At this point, the SGX application mints (creates) the equivalent amount of BTC.b to the user wallet that sent the initiating Bitcoin transaction. More details on how the user wallet addresses are determined are explained in the next section. Similarly, when moving BTC.b from Avalanche back to Bitcoin, the user sends a transaction on Avalanche that calls the “unwrap” method of the BTC.b contract, which burns (destroys) the BTC.b tokens. The Warden nodes will index this transaction, and it will be processed by the SGX enclave by sending the equivalent amount of native BTC back to the user’s wallet on Bitcoin.

Address Derivation

Extending the Avalanche Bridge to support cross-chain Bitcoin transfers required unique solutions to technical problems specific to Bitcoin. A key feature of the Avalanche Bridge is that the same user wallet is used on all networks. For ERC20 transfers from Ethereum to Avalanche, this is straightforward because both blockchains use the EVM (Ethereum Virtual Machine) address format, so the bridge is able to mint wrapped tokens to the same address that initiated the transfer by providing the collateral on Ethereum. Bitcoin, however, uses an entirely different address scheme. In order to determine the Avalanche address that corresponds to a Bitcoin address that provided collateral to the bridge, the Wardens recover the public key of the user wallet from the signed transaction on the Bitcoin network and use it to derive the Avalanche C-chain address. This way, the funds on both networks are controlled by the same private key or mnemonic phrase, and that secret never leaves the sole possession of the user’s wallet. Similarly, when a user goes to transfer funds from Avalanche back to Bitcoin, the user’s Bitcoin address is derived from the public key recovered from the Avalanche transaction that burns the wrapped asset.

An additional challenge to using this address derivation approach is the fact that almost all Bitcoin wallets are hierarchical deterministic (HD) wallets that use different public and private keys for each UTXO received. This is in contrast to the EVM account model, where wallets use the same private key for all transactions. HD wallets are incompatible with the Avalanche Bridge because users expect their funds to arrive at a single Avalanche address rather than be split across multiple addresses. In order to provide an intuitive user experience, the Core Wallet extension provides Bitcoin wallet functionality, and also provides the user interface for bridging Bitcoin over to Avalanche. The Bitcoin wallet within the Core extension uses the same private key as used for the C-chain address on Avalanche, allowing for easy bridging between the two chains from within a single wallet. While HD wallets provide additional privacy on Bitcoin by using new addresses for each transaction, we found using a single address wallet a very reasonable trade off to enable more seamless bridging, given that all EVM based chains, including the Avalanche C-chain and Ethereum, follow this model.

Bitcoin Transaction Construction

Another big component of the Bitcoin bridge support involves management of Bitcoin unspent transaction outputs (UTXOs). As opposed to the EVM which uses an account based model, when sending a bitcoin transaction, explicit inputs and outputs must be specified. This presented a challenge because the Intel SGX enclave application has no knowledge of UTXOs, only the secret keys which control its wallets. In order to construct a Bitcoin transaction for a given amount when a user is moving funds from Avalanche back to Bitcoin, the enclave first asks a single Warden to propose which UTXOs to use as inputs for the new transaction. Once the enclave has these UTXOs from a single Warden, it then asks all of the Wardens to validate the UTXO selection and construct the raw transaction consuming the given UTXOs and creating the outputs it specifies. The enclave will only move forward with processing a transfer back to Bitcoin if at least 6 of 8 Wardens agree on the proposed UTXOs and construct the same raw transaction. In the unexpected event that the wardens do not agree on the UTXOs chosen by the single proposer, a different Warden is selected to propose which UTXOs should be spent and the process is repeated. Once the wardens agree on a set of proposed UTXOs and construct the raw transaction, the transaction is signed by the enclave and broadcasted out to the Bitcoin network through the Wardens. Very importantly, the key used to sign the transactions is never exposed anywhere outside of the enclave.

Bridge Fees

The fees associated with bridging Bitcoin to Avalanche and back follow a very similar model to bridging from Ethereum described in the Avalanche Bridge FAQ here. However, estimating the Bitcoin transaction fee for transactions sent by the bridge presented a unique challenge due to Bitcoin’s UTXO model. Compared to the EVM, where the transaction fee is proportional to the “weight” of the transaction (i.e. how much gas it used in it’s operations), Bitcoin transaction fees are proportional to the transaction size, which depends on how many UTXOs it both consumes and creates. Determining the exact bridging cost requires that the bridge knows the amount of BTC being sent, and the set of UTXOs that will be used to cover that amount. Neither of this information is available beforehand. One transaction sending 1.0 BTC to Bob might have twice the transaction fee of a different transaction sending 1.0 BTC to Alice if the 1.0 BTC being sent to Bob was split across many smaller UTXOs. To provide users of the bridge a predictable and consistent fee rate, we implemented a model where the bridge fee charged is based on an expected BTC transaction fee, computed by using the average size of the UTXOs controlled by the bridge, and how much BTC is being transferred. If the expected fee charged to the user is slightly more than the actual BTC transaction fee, the extra amount charged goes into a bridge pool that can be used to cover the difference for when an expected fee is slightly less than the actual BTC transaction fee. In a sense, it can be thought of as a “leave a penny, take a penny system” that provides a more predictable user experience when bridging back to Bitcoin. In order to maintain the health of the system, it is configured to have a slight expected positive inflow, and the state of the pool is constantly monitored.

UTXO Management

One component we kept in mind when designing how the bridge manages its set of UTXOs is how to avoid the accumulation of dust. Dust UTXOs are UTXOs that control a very small amount of value, potentially even less than the fee it would cost to move them. Having a large number of dust UTXOs is undesirable because it results in higher BTC transaction fees as described above. The bridge takes a relatively simple two-pronged approach to minimizing dust. First, there is a minimum transfer size of 0.00125 BTC (subject to change) when bridging from Bitcoin to Avalanche. Any UTXOs sent to the bridge smaller than this size are ignored and will not be processed. Second, when constructing Bitcoin transactions to fulfill transfers from Avalanche back to Bitcoin, the bridge uses a “target change amount”. This means that when a Warden is selecting which UTXOs to propose for a new transaction, it will intentionally include additional inputs such that the change amount recycled back to the bridge in the new transaction will not be dust itself.

It was also important to consider how Wardens should select which UTXOs to propose to be spent in Bitcoin transactions. In order to incentivize transactions sent by the bridge to be included in a Bitcoin block, the Wardens prefer to spend any unconfirmed change UTXOs in subsequent bridge transactions. This way, if the Bitcoin fee rate increases, earlier transactions sent by the bridge should still be included in blocks following the child-pays-for-parent model. If there are no unconfirmed change UTXOs, the wardens will aggregate the oldest remaining UTXOs until the sufficient amount is met for the transfer. While this may not strictly minimize transaction size and fees, it provides a simple approach for the bridge to work through the UTXOs it controls and ensures smaller UTXOs will eventually be folded into larger ones.

Conclusion

We are very excited to continue to support the development of the Avalanche DeFi ecosystem by adding support for Bitcoin to the Avalanche Bridge. The use of Intel SGX technology put the bridge in a unique position to address the various technical challenges of supporting Bitcoin transfers, and we can’t wait to see where the community takes it from here.

Bridging Bitcoin To Avalanche: A Technical Overview was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.