@Inch_Deen Few folks flagged your comments as “off topic.” It is my job to please ask you keep on topic or ask on more relevant threads. I do not think anybody will answer your questions because they are not really about BTC integration. Have you checked other more relevant threads? I hope you take this with the intent I mean it: just a reminder to a user to let them know how developer forum self-organizes.
(sidenote: effective ICP annual inflation is around 4-5% currently. I would not call that “huge”)
Hi bitbruce
ckBTC has not been launched yet, the DFINITY team is still working on it.
Manu and Leo presented a glimpse of it on November 23, see Global R&D - November 2022 - YouTube, from 39:33.
I am not a software developer. However, a software developer friend of mine explained the bridge concept to me in an understandable way. Bridge, which claims to establish the connection between two blockchains, does not actually make any connection. It burns assets on one blockchain platform and creates virtual the same assets on the other blockchain. Integration is when assets in one blockchain are transferred to the other blockchain in their original form. I hope BTC integration of ICP works like this.
ICP does both. The former using ckBTC, and tha later using chian key cryptography. But even the bridge one is better than in other bridges, it removes a middleman and uses ICP blockchain consensus rather than a trusted middleman to do it.
That’s exactly the key point. A bridge is an additional component that you need to trust. Neither the Bitcoin integration nor ckBTC (which has not been released yet!!) rely on a bridge at all because IC nodes can interact with the Bitcoin P2P network directly.
It looks to me like the state of the Bitcoin canister has grown from ~39.55GB to 40.2GB in a week, or ~93MB per day.
This would mean the canister is growing at 33.9GB per year.
Is it safe to assume that single canister stable storage limits will be continuously lifted (and can be done so safely) to stay ahead of any needs of the BTC integration?
Is there anything you envision that could speed up this storage required growth rate?
In addition to Timo’s answer, I’ll also add that the Bitcoin canister is currently quite wasteful with its use of memory and there are a number of optimizations that can be done to reduce its memory footprint. These weren’t a priority prior to launch, but can become a priority depending on how the UTXO set grows.
A Zero-Knowledge Roll Up (ZKRU) for transactions is possible on the Bitcoin network.
ZKRU introduces additional code vulnerabilities. However, if done correctly enables a tradeoff of speed and cost for the security of Bitcoin network verified transactions. I am not suggesting that the ckBTC design is bad. In fact, it is cheaper and less likely to introduce code that can be hacked. Furthermore, ckBTC is a prerequisite for what I would envision as a zkBTC on the IC. However, it does not inherit the BTC network security. BTC network security is likely a large draw for BTC holders. In addition to the smart contract example provided it would also require a wallet extension which can capture self-custodied BTC signatures needed in order to transact zkBTC on the IC.
I am a beginner in this space and my next lines of investigation will be:
How does the ZKRU post data?
Will capturing bitcoin wallet signatures be sufficient?
How do we make it compressed (only the minimal amount of transfer required)?
I will attempt building a ZKRU on a BTC testnet and then plan to attempt to build a canister for the processes I am doing off chain. I thought I would share because I am currently in the middle of many projects.
Folks, Proposal: 98062 - IC Dashboard has been executed, which allows us to re-upload the Bitcoin testnet state in a verifiable way. Prior to this proposal, the Bitcoin testnet state was unverifiable. The Bitcoin testnet API will not be available for the next 3-5 hours until the upload is complete.
Update: The new verified state has been uploaded and the Bitcoin testnet API is now available again.
Is there a working group or something like it for Bitcoin integration, ckBTC, Ethereum integration, and generally the third-party-chain integration process more broadly?
Seeking to understand in more detail the timeline and some of the features and security assumptions to make design decisions for a protocol on the IC.
