NNS Proposal: Direct Integration with Bitcoin
Summary: A proposal to enable users and canisters on the Internet Computer to transact wrapped bitcoin directly without the use of a centralised intermediary or an intermediary protocol. This is achieved by IC replicas running Bitcoin nodes.
Rationale: Bitcoin is the primary onramp and store of value in the cryptocurrency space. Enabling canisters and users on the IC to transact bitcoin is a necessary function of the IC. Integrating Bitcoin is necessary for DeFi protocols to operate. Integration of Bitcoin will also allow the IC to compete with “Layer 2” protocols like the Lightning Network.
“Wait...so IC replicas will basically have Bitcoin core running as well? Or will they all talk to a smaller set of Bitcoin core nodes? If each replica doesn't have its own Bitcoin core nodes, centralization risks. If they do...seems we're now tying Bitcoin consensus into IC”
“subnets will be able to hold and control real Bitcoin/Ether, it is of paramount importance to ensure that Bitcoin/Ether are neither lost (for example because the subnet failed and cannot be recovered) nor stolen (for example because sufficiently many node providers collude to extract the secret key material).”
“Given the need to replicate the BTC chainstate into the IC, how will this affect the subnets capacity?”
“The subnets will store the UTXOs (roughly 4-10 GB in size depending on data representation) and not hold on to the blocks themselves. So, the Bitcoin integration is not expected to have a significant impact on subnet capacity.”
Proposal: The proposal documentation is complicated and challenging to understand. In part this appears to be a result of the complicated nature of the solution it presents. The team’s engagement with community discussion is necessary for understanding the content of the proposal. Furthermore, as the proposal does not refer to an immediate integration but an elongated timeline for work to be performed, we can't infer the complete accuracy of its representation of the logic to be implemented.
“Canisters must be able to have a Threshold ECDSA public key from which their Bitcoin addresses are derived. Threshold ECDSA is a separate feature going through community voting concurrently with this feature. Functionality (2) requires that we ingest Bitcoin blocks into the Internet Computer, validate them, and track the Bitcoin blockchain. Once blocks have a sufficient amount of work in successor blocks on the blockchain, transactions and their UTXOs can be extracted and served to canisters upon request.”
According to THLO:
“Since the IC replicas pull in blocks from the Bitcoin network directly, the security depends on the correct functioning of both the IC and the Bitcoin network (but not on anything else).”
“. . .there will be dedicated adapters on the replicas fetching blocks directly from the Bitcoin/Ethereum P2P networks.”
The proposal will require every replica to run a Bitcoin node [Inferring from the 4GB - 10GB storage consumption this will be a recent history of UTXOs and an SPV node]. A design based on an external relay was not pursued due to the addition of a trusted layer. A design described as an “oracle canister on all subnets where Bitcoin functionality is made available” was abandoned due to technical challenges. This second alternative presumably involved running a bitcoin node in a canister.
“This is the first time we’re able to tokenize Bitcoin without trusted custodians and without the over-collateralized stake-backed model that is not capital efficient. It will not only unlock this asset for the IC, but after the Ethereum integration, IC-wrapped BTC could then be used in Ethereum DeFi.” - Norton Wang
The proposal showcases the limitations of the IC. Rather than run inside a canister, a Bitcoin node is to be run on each replica. This raises some questions about the IC developing opinions and will lead to an appeal to a slippery slope argument: When do replicas stop integrating other blockchains? As a result, the solution feels inelegant.
That said, no major concerns have been raised by the community and there is broad enthusiasm for what this functionality will enable.
cycle_dao will vote Yes on this proposal