Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days - weeks
Experience Level: Intermediate/Advanced
Size: USD 5’000 in ICP (at time of distribution)
The Internet Computer can be used to create Bitcoin wallets, where the private key never exists physically, but signatures are generated by a secure multi-party computation among the nodes of a fiduciary subnet. However, for some very high-value custody applications, we might want to increase the security even further.
Bitcoin Script allows to require multiple signatures to spend a UTXO. Hence, we can create a wallet (or even a version of ckBTC) that consists of multiple canisters running on different fiduciary subnets, requesting signatures derived from different master keys (Currently, we only have two master keys deployed, key_1 and test_key_1).
Hence, the node providers of multiple subnets would need to collude to steal assets.
The wallet should be able to generate P2WSH addresses to send funds to.
No single canister (or subnet) should be able to transfer funds.
The wallet should have a user interface
It is ok (for now) that a single user principal can orchestrate the transfer of funds.
I’m excited to see the new bounty introduced by DFINITY! It’s an excellent opportunity for developers to explore the fascinating world of Bitcoin wallets on the Internet Computer.
As some of you may know, I’ve been working on a project called B3Wallet, a decentralized multi-chain wallet that leverages the power of the Internet Computer. With B3Wallet, the private key never physically exists, and signatures are generated through secure multi-party computation among nodes of a fiduciary subnet.
In addition to B3Wallet, I’ve also developed a set of libraries called b3_utils, which provide useful functionalities to make wallet creation on the Internet Computer easier and more efficient. You can find the libraries on docs.rs/b3_utils and use them as a starting point for your own implementations.
Now, with this new bounty, we have the opportunity to take security to the next level. By creating a wallet that consists of multiple canisters running on different fiduciary subnets and requiring multiple signatures to spend a UTXO, we can enhance the security even further. The node providers of multiple subnets would need to collude to steal assets, making it an incredibly robust solution.
If you’re interested in contributing to this exciting project or want to collaborate, I invite you to explore B3Wallet and the libraries that you can find in the project. Let’s work together to build innovative and secure Bitcoin wallets on the Internet Computer!
Looking forward to seeing your submissions and contributions.
Hey @b3hr4d I was curious to know if you continued working on this bounty and planned to submit something soon or not. I could give it a hand to make it happen on the B3Wallet, but I’m a quite a noob in rust. Otherwise I might just give it a try in Motoko in my own.
@domwoe since there is no submission yet, is the deadline for this bounty also open?
This wallet uses two canisters to generate 2x2 multisig P2SWH bitcoin addresses. The main canister is written in rust and contains all the logic to generate the addresses and build the transactions. The second canister is written in Motoko and only serves as an intermediate to generate the second public key and signature. The principal of the user is used as the derivation path in order to have a specific address and signature for each user. You can find more information on how this works in the readme.
Thank you for the extensive readme with flow diagrams!
With the current design, wouldn’t it be enough to compromise the subnet the wallet canister is on? It seems the wallet canister is able to request both signatures. One directly, and the other by calling the fiduciary canister/
Oopsie. Yeah that’s what I’ve done indeed. But you made me realized that if a subnet is compromised, not only the signatures can be generated on that subnet, but the code of the canister itself can be changed…
So what if I orchestrate the transfer of funds in my front-end instead:
Frontend->Canister Subnet 1: generate transaction and sighashes, generate first signature
Frontend->Canister Subnet 2: generate second signature, send the transaction on the btc network