Would Lightning also be supported with this Bitcoin integration.
Maybe also have a look at Tangem, which can control btc with their cold card & app.
Actually, your interpretion is pretty accurate.
Indeed, a canister’s Bitcoin funds are reflected on the Bitcoin blockchain, and it can implement any logic that dictates when it sends Bitcoin and how much. The recipient may be a regular Bitcoin user — or another canister!
So it looks like each replica has an instance of the Bitcoin Adapter? Does that mean each replica is communicating directly with Bitcoin peers over the internet? And each replica (through the adapter) would be validating UTXOs?
So a subnet with 7 replicas would have 7 Bitcoin Adapters, one per replica?
I am trying to assess the decentralization here, and I’m hoping each replica will have to independently obtain and validate UTXOs and match them with the other replicas during consensus.
And yes, each replica will validate the UTXOs.
A couple of questions
1- Given the need to replicate the BTC chainstate into the IC, how will this affect the subnets capacity? Will this mean higher requirements for nodes?
2- How is the second part different from lightning network?
Thanks for your questions!
Let me try to answer them:
1 - The subnets will store the UTXOs (roughly 4-10 GB in size depending on data representation) and not hold on to the blocks themselves. So, the Bitcoin integration is not expected to have a significant impact on subnet capacity.
2 - I’m not sure what you mean by “second part” but there are several differences between a lightning channel and a Bitcoin smart contract on the IC. In short, the Lightning network offers bidirectional payment channels for off-ledger transactions. Bitcoin smart contracts on the IC offer arbitrary smart contract logic for Bitcoin that (potentially) any user can interact with.
Smart contracts on the IC further do not have the shortcomings often associated with the Lightning network such as the risk of a fraudulent force close or the risk of establishing “hubs” that constitute endpoints of large number of channels (whose failure may have a detrimental effect on the whole network).
Thank you for this. The second part referred to this "(2) Transactions on the Bitcoin network are inherently slow and expensive " on the scope of the project ".
Hey folks, looks like questions are still coming in. Do folks prefer we push back the NNS motion to let more questions/iterations come in?
I want to make sure we strike a balance of moving fast but letting people have their say.
In case of a subnet subset collusion and a non authorized transaction is signed – can the malicious parties be detected ? if so - can a token economics disadvantage can be added to slash these node providers (maybe staked ICP) ?
One last question: are there dApps already just waiting for this integration? If yes, it would have been great to ask and see how precisely they’d want to use it. That could help check if a critical point isn’t missing.
Bitcoin is a store of value. It’s not building the new decentralized Internet. [$ICP]
Update: we are on track to submit NNS motion proposal on Wednesday September 15, at 15:00 UTC.
I see that you outline the design of the API within the execution environment, but not yet how this will be expressed on the level of the System API towards the actual Wasm canisters. Is there a design for that as well already? Will it be new synchronous Wasm calls? If so, how will the data be represented as Wasm types? Or will the functionality be exposed using the virtual management canister (same as secure randomness and ECDSA signatures)? If so, can you give the candid interface of that? Or is that simply future engineering work?
The current plan is to expose the functionality using the virtual management canister; however, there is no firm decision on that. And yes, figuring out the most suitable candid interface is part of future engineering work.
I suggest that you ask this question in the Threshold ECDSA Signatures thread.
If there is a trace proving that multiple node providers colluded, their nodes could be removed (via NNS voting).
Good question! While there is a lot of interest in this integration, we’d love to hear more from the community what functionality they would use personally or build applications around.
Please feel free to drop ideas and wishes right here in the forum!
I’m most excited for an all-in-one crypto wallet that can hold BTC, ETH, other Ethereum tokens, ICP, and other IC tokens. This wallet will be integrated with Internet Identity, and will have advanced features like social recovery and other features that are impractical to do on decentralized blockchains currently because of their computational cost.
I probably won’t build this, but I hope someone else does.
NNS Motion Proposal for BTC Integration is live!:
I am getting worried about the security of canisters running on non-system subnets, that hold large amounts of monetary value.
I’m not sure enough security precautions have been taken to feel confident that canisters running alongside possibly malicious canisters will be safe.
I did not realize that each canister was running within the same process on each replica within a subnet, at least that seems to be the case.
Perhaps a prerequisite to this project moving forward is process sandboxing, so that even if malicious canisters break out of the Wasm environment, they’ll be stopped by the process boundary.
See here for more information: Enable Canisters to Hold ICP - #30 by lastmjs