How ICP’s Bitcoin Integration Secures Private Keys
ICP’s native Bitcoin integration unlocks smart contract capabilities for Bitcoin while eliminating the need for cross-chain bridges.
Direct Bitcoin integration on the ICP enables canisters, which are advanced smart contracts, to interact with the Bitcoin network at the protocol level. This allows the canisters to directly receive, hold, and send BTC on Bitcoin mainnet without using intermediaries and third-party blockchain bridges, which are riddled with a plethora of security issues. The Global Web3 Security Report suggests that in 2022, nearly $1.89 billion was lost due to just12 incidents involving these bridges.
With the Bitcoin integration, canisters on ICP can securely read from and write to the Bitcoin ledger.
(1) Canisters can read the state of the Bitcoin blockchain through a Bitcoin light node running on the Internet Computer protocol. To this end, nodes in the ICP network obtain blocks directly from the Bitcoin network and extract and process the contained transactions. This keeps them up to date with the current Unspent Transaction Output (UTXO) set of the complete Bitcoin network. This UTXO information is offered to canisters via an API, thereby enabling canisters to access information like the balance and UTXOs of Bitcoin addresses. In other words, canisters can query the balance and UTXOs of any Bitcoin address, including addresses they control. This allows them to determine the spendable balance (and UTXOs) of a Bitcoin address by looking at the state of the blockchain.
(2) To write to the Bitcoin network, canisters can securely sign Bitcoin transactions and submit them to the Bitcoin network. Secure signing is done via a novel threshold ECDSA protocol referred to as chain-key ECDSA. Signed transactions are submitted through the protocol-level integration. This results in ICP replicas submitting the transaction to many connected Bitcoin nodes.
Where are the Private Keys stored on ICP?
Now that canisters can also write (sign and submit) transactions, does it also mean that they store the private keys?
Holding the private keys in the canister’s state might potentially expose them to malicious nodes within the ICP network, which could grant access to the user’s digital assets. To prevent this, ICP uses threshold cryptography so that private keys are never entirely stored on any single node or a canister. Threshold cryptography allows a secret (like a private key) to be split into multiple parts, known as secret shares or shares. A certain number (at least the threshold) of these shares are needed to reconstruct the secret or use it to sign a message.
Thus, rather than storing the entire private key in one location, it is divided into multiple parts, the secret shares, held by all nodes within a high-replication subnet, i.e., a subnet with a larger number of nodes than a regular app subnet. Furthermore, these secret shares are periodically reshared among the nodes to protect against a possible compromise of shares. Resharing means that new shares are created from the current shares using a cryptographic protocol. Once re-shared, the previously-valid shares become obsolete, rendering them useless to any malicious actor who might have obtained them.
When writing to the Bitcoin network, Bitcoin transactions are signed using threshold signing, which means that if a sufficient number of nodes in the subnet agree to sign, each node uses their respective key share to help jointly sign the transaction. At least as many key shares as the threshold are required to compute the signature.
This ensures that the key is unavailable to any entity as a whole and to an attacker who controls a smaller number of nodes than the threshold. In the case of ICP, upon a canister transaction request, the nodes use their shares to sign Bitcoin transactions jointly rather than recreating the original private key. This signing protocol assumes that more than two thirds of the nodes are honest, and less than one third compromised.
ICP’s non-Custodial approach for ckBTC and Bitcoin Integration
Most protocols designed for collaboratively computing ECDSA signatures using key shares distributed among participants assume either zero robustness or liveliness, a synchronous network, or both. With no robustness, the protocol could lose its capacity to generate digital signatures when a single node crashes or does not participate. Consequently, assuming a synchronous network implies that simple message delays could lead to the signing protocol failing and no signature being produced, thus the protocol is susceptible to attacks against availability.
ICP is designed to be fault tolerant, ensuring that the protocol works in an asynchronous communication network, i.e., it can tolerate message delays without failing. As long as less than a third of the nodes are compromised, faulty, or crashed, the entire system remains effectively functional, i.e. continues operating with a reduced throughput. And if a node in a subnet fails, ICP picks a spare node to replace the faulty node.
