Thanks for the clarity, Thomas
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!
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.
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
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.
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.
This post was flagged by the community and is temporarily hidden.
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