Thanks for the clarity, Thomas
1 Like
While the Bitcoin integration will lay the foundation for the functionality to make external HTTP calls, it is a separate piece of work.
Since it is an exciting feature, I hope that we will be able to work on it early next year!
7 Likes
If I were to phrase how the BTC bridge works - in non-ICP terms.
Note: I am not an expert on how ICP works and I simply assume that there is a set of validators assigned to a cannister that locks up stake in the native token (Please correct if wrong!!!)
- A cannister runs a Bitcoin light client (a BTC-Relay) that allows it to verify that specific Bitcoin transactions are part of the main chain + some parsing functionality.
- When a user wants to move BTC onto ICP, she deposits this to a address generated by the cannister.
- This address is generated from a ECDSA public key that was in turn generated via an ECDSA threshold scheme.
- The validators (?) of the cannister jointly control the public key. That is, only if e.g. 2/3 sign, the BTC can be moved.
Questions that arise:
- How do you update the threshold signature scheme when the validator set changes?
- Does the ECDSA threshold implementation suffer from the same issue as the one used in tBTC (i.e., one can only check how many signatures were made, but now who) or does this implement the improvement suggested by Gennaro & Goldfeller? And is the latter improvement already feasible in practice (I have not yet seen any implementation and would be grateful for a pointer!)
- How are users protected from failures? Since there seems to be no collateral that will be used to reimburse users in case of failure, users must trust that 2/3 of the cannister validators are honest.
The challenge here is that the security model is different from the single-chain / ICP only setting. To attack ICP, validators must collude and risk losing their deposit. The value of the attack, however, is hard to measure: the ICP price would crash if a major attack happened, stake would be slashed etc. - so it is unclear how validators would measure the value of the attack.
In the case of a BTC bridge, the attack setting is different: the validators must only decide to steal the BTC. There is always a direct comparison to their stake in terms of e.g. USD value: the USD value of the total BTC locked in with the cannister deposit address - and the total value of the stake locked by the cannisterâs validators in ICP tokens. The moment the BTC is worth more, validators are incentivized to steal.
Wondering if and how this is address - and if I have at all understood the bridge / cannister design correctly.
Thanks in advance and thanks for being patient with my lack of ICP knowledge.
1 Like
I thought this thread would be interested in the update about project scope and design on the Sandboxing project tread: Security Sandboxing (Community Consideration) - #3 by diegop
4 Likes
The Internet Computer does work differently: A canister smart contract runs on a so-called subnet consisting of a set of nodes/replicas. The (decentralized) Network Nervous System (NNS) determines which replicas are part of which subnet. Since all replicas together ensure deterministic execution and state transition, they are responsible for both execution and validation. However, there is no âdepositâ of ICP. Each node is associated with a node provider, and node providers get rewarded, in ICP, for each node that contributes to the Internet Computer.
If youâd like to learn more, you can find a technical overview here.
Letâs go over your bullet points:
Technically, each replica (running the canister) runs a BTC relay, which interacts with the Bitcoin P2P network and provides the necessary information to a Bitcoin system component (running on each replica). This component makes Bitcoin-related functionality available to the canisters.
Correct.
Correct.
The replicas running the canister jointly control the private key. And yes, two thirds of the replicas must provide a signature share to construct a valid signature to move Bitcoin to another address.
Regarding your other questions, as they pertain to the threshold ECDSA feature, may I ask you to post them on the dedicated thread? The guys there will certainly be able to answer your questions in great detail. 
5 Likes
Back to this point about the potential use cases of tthis ICP-BTC integration.
DEX and Crowdfunding dApps would be natural use case.
More globally, ârotating credit savingâ groups or ROSCAS (ROSCAs: Whats in a Name?) would be a great fit.
There are millions of communities & groups putting funds together and redistributing/lending them to fund members projects in more more less sophisticated schemes, which could naturally be implemented in smart contracts (without human risks/ funds diversion) and hold the shared funds in BTC (vs local costly banks and currencies).
Every time a group or community needs to hold and use shared funds with some logic, this integration offers the right cocktail : smart canisters holding BTC (as individuals but with logic) and fast/cheaper transaction fees.
my two cents
7 Likes
Dear community!
Let us share an update on some of our recent engineering progress. We have made excellent progress with the implementation of the feature both for the Bitcoin Adapter and the BTC System Component. Just to give an example, the BTC System Component can already build the UTXO set from Bitcoin blocks and gracefully handle forks.
We will be posting progress updates more regularly in the future to keep you updated!
14 Likes
Great to hear! How does building the UTXO set work? Does each replica process every block since genesis?
3 Likes
We have not yet integrated the BTC System Component with the Adapter, thatâs still an upcoming milestone. To demonstrate the UTXO processing capabilities, our engineer for the System Component has fed all blocks up to 705992 into the BTC System Component directly and had them processed. He could show that the API for querying the UTXO set for bitcoin addresses works. This is a huge step as it shows that the core processing logic of the component works.
Does each replica process every block since genesis?
The goal is to not ingest all blocks using the regular mechanism as this puts too much load on the subnet and takes a long time. We will likely pre-process the UTXO set up to a defined block externally and encode the hash of a canonicalized version of this pre-processed set into the BTC System Component. Then we just feed the set into the component and the component can validate the correctness of the hash and bootstrap securely yet efficiently. How exactly we do this is still to be determined. Weâll keep you posted once we get there. Hope this answers your question!
9 Likes
Yes, many thanks for the detailed answer!
2 Likes
I thought folks here would be interested in this:
1 Like
Do we know how the planned Taproot and upgrade to Schnorr could affect this integration? Could it simplify the threshold scheme for instance?
1 Like
Threshold Schnorr would be a somewhat simpler protocol than threshold ECDSA is. However, we are now in the middle of the process of building threshold ECDSA and will use this for our first Bitcoin integration deployment as originally planned. This is not something one can change quickly as it would involve all stages of protocol design, security proof, protocol review, system design etc., so it would throw us back a lot in our timeline. And ECDSA will always be supported in Bitcoin.
4 Likes
So canister doesnât verify the validation of btc block for example PoW?
While I didnât mention it in my short summary above, the blocks are verified: the validity of the PoW difficulty as well as the timestamp in the block header are first checked at the networking/consensus layer and then again in the execution layer before a block is accepted.
If canister want to verify the PoW of bitcoin, icp should maintain the block header in canister. So how many block headers should icp hold? The whole chain or just the tail of BTC, for example last 100 block headers?
The IC system components themselves verify the validity of blocks and offer the functionality to retrieve UTXO sets and submit Bitcoin transactions to the canisters. So, canisters are not required to validate blocks/block headers themselves, nor will they be able to because the system wonât provide access to this data.
The system itself caches blocks until there are sufficiently many confirmations and there are no competing forks at the same block height. This means that more blocks are cached if there are forks that need to be resolved. Since forks are fairly rare in Bitcoin, the number of cached blocks will likely be small most of the time in practice.
If there is interest, I can provide a more formal/technical description of the caching process.
5 Likes
Dear community!
Let me share this weekâs highlight w.r.t. work on this feature with you. We had the first âBitcoin Community Developer Workshopâ yesterday with some of the core DFINITY folks working on the Bitcoin and threshold ECDSA features as well as many of our most active and interested community members on those topics joining online for two hours. We had around 15 forum members participating as well as 9 folks from DFINITY. The minutes will be made available early next week.
It was an extremely productive conversation where on the one hand our community members could get questions answered by DFINITY folks on details regarding the API, concepts and implementation and on the other hand DFINITY could get insights on what the community members think and what they would like to see being built in addition to what has been planned.
Let me highlight the following points that I consider major outcomes of the meeting and the projectâs status:
-
Testing against BTC mainnet and testnet - Regarding the testing of canisters that want to use Bitcoin, the community suggested that we should provide the option of letting a canister choose whether it wants to work with the Bitcoin mainnet or testnet. This would allow for easier testing of canister code without needing to perform transactions on the Bitcoin mainnet.
-
Threshold ECDSA and BTC integration - The Threshold ECDSA feature will most probably slip into 2022, but it may be possible to avoid that this also delays the rollout of the Bitcoin integration feature: Our community has suggested that we should provide them access to the Bitcoin functionality without Threshold ECDSA if it is finished earlier in order to allow for implementing against it already and mock the ECDSA functionality during development. This would help reduce the time to market for Bitcoin-related features.
-
EVM on the IC - Our community stressed the importance of being capable of running EVM code on the IC so that smart contracts authored in Solidity could be run on the IC without reimplementing them. The reasoning behind this is that it is a huge effort to rewrite substantial smart contracts and there is the risk of introducing vulnerabilities into a time-tested smart contract through such a rewrite.
We are now internally discussing those points that have been brought up and will keep you posted on updates.
Have a nice weekend!
12 Likes
About point 2., I thought the Bitcoin integration was dependent on Threshold ECDSA. How will the Bitcoin functionality work without Threshold ECDSA?
1 Like
There are some use-cases that donât depend on tECDSA, though relatively limited. The BTC API allows you to get the balance/UTXOs of bitcoin addresses, so you can, for example, deploy canisters that can programmatically do some action whenever a specific bitcoin address receives/sends BTC.
3 Likes