Direct Bitcoin integration on ICP enables containers (high-level smart contracts) to interact with the Bitcoin network at a protocol level, which makes it possible for containers to receive, hold, and send BTC directly on the Bitcoin mainnet without the use of intermediaries and third-party blockchain bridges that have numerous security issues.
The Global Web3 Security Report shows that by 2022, just 12 incidents involving these chain bridges resulted in nearly $1.89 billion in losses.
With Bitcoin integration, containers on ICP can securely read and write to the Bitcoin ledger.
1. The container can read the state of the Bitcoin blockchain through a Bitcoin light node running on the Internet Computer Protocol. To do this, nodes in the ICP network obtain blocks directly from the Bitcoin network and extract and process the transactions contained in them, which enables them to keep abreast of the current unspent transaction output (UTXO) set of the complete Bitcoin network.
This UTXO information is provided to the container via an API, giving the container access to information such as the balance and UTXO of a Bitcoin address. In other words, containers can query the balance and UTXO of any Bitcoin address, including addresses they control, which allows them to determine the spendable balance (and UTXO) of a Bitcoin address by looking at the state of the blockchain.
2. To write to the Bitcoin network, the container can securely sign Bitcoin transactions and submit them to the Bitcoin network. The secure signing is done through a novel threshold ECDSA protocol (called chain key ECDSA). The signed transaction is submitted through protocol-level integration, which causes the ICP replica to submit the transaction to many connected Bitcoin nodes.
Where are private keys stored on ICP?
Now containers can also write (sign and commit) transactions, does that mean they store private keys as well?
Storing private keys in container state could expose them to malicious nodes in the ICP network, granting access to the user's digital assets. To prevent this, ICP uses threshold encryption technology so that private keys are never fully stored on any single node or container.
Threshold cryptography allows a secret (like a private key) to be split into multiple parts, called secret shares or shares, with a certain number (at least a threshold) of these shares required to reconstruct the secret or use it to sign a message.
Therefore, instead of storing the entire private key in one place, it is split into multiple parts, i.e. secret shares, held by all nodes within a high-replication subnet (i.e. a subnet with more nodes than a regular application subnet).
Furthermore, these secret shares are periodically re-shared between nodes to prevent possible leaks of the shares. Re-sharing means creating new shares 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 obtain them.
When written to the Bitcoin network, Bitcoin transactions are signed using threshold signatures, meaning that if a sufficient number of nodes in a subnet agree to sign, each node will help co-sign the transaction using their own key shares, with at least as many key shares as the threshold required to compute the signature.
This ensures that the keys are unavailable to any monolithic entity as well as to attackers who control less than a threshold number of nodes. In the case of ICP, nodes use their shares to jointly sign Bitcoin transactions based on container transaction requests instead of recreating the original private key. This signing protocol assumes that more than two-thirds of the nodes are honest and less than one-third of the nodes are compromised.
ICP’s non-custodial approach to ckBTC and Bitcoin integration
Most protocols designed to collaboratively compute ECDSA signatures using a distributed secret key share between participants assume zero robustness or liveness, a synchronized network, or both. Without robustness, the protocol may lose its ability to generate digital signatures when a single node crashes or stops participating.
Therefore, assuming a synchronous network means that a simple message delay may cause the signing protocol to fail and fail to generate a signature, and the protocol is therefore vulnerable to availability attacks.
ICP is designed to be fault-tolerant, ensuring that the protocol works in asynchronous communication networks, i.e., it can tolerate message delays without failing, and as long as less than one-third of the nodes are compromised, fail, or crash, the entire system remains operational, i.e., continues to operate at a reduced throughput.
If a node in the subnet fails, ICP selects a spare node to replace the failed node.
Further reading:
Bitcoin Integration: Technical Overview
ckBTC is Bitcoin on Web3
Taking security seriously: Two of the top ICP features evaluated by Trail of Bits
IC content you care about
Technology Progress | Project Information | Global Activities
Collect and follow IC Binance Channel
Get the latest news
