There has been incredible work implementing descriptor wallets, PSBTs, offline signing, HWWs; and GUI support for it all into Bitcoin Core. It has been incredibly exciting to watch!
My goal is to financially support developers to implement offline multisignature wallets into Bitcoin Core. I believe we are almost there.
I am here to humbly try to attempt to describe what I see, as a user and through talks with other developers, as the work that is needed to implement secure, offline multisignature wallets in Bitcoin Core.
- A standard for Coordinating Multisignature Wallets, with an authentication scheme. This is being discussed here.
BlockchainCommons has done a lot of work around this:
Online Node Coordinator sends a ‘Policy Request’ to Offline Co-Signers, if acceptable, co-signers send a ‘Keyset’, and then get an ‘Account Map’ back.
Policy Request = empty descriptor
Keyset = BIP48 path
Account Map = descriptor w/ no xprvs in it
AND/OR
Co-Signers send array of descriptors for all script types (BCR-2020-015) to Coordinator, Coordinator selects necessary descriptor and creates wallet, then sends ‘Account Map’ back.
Concerns: lack of complete standardization. use of BIP48. Names still up in the air. @Sjors also discussed the possibility of a ‘Wallet Composer File’ that could compose a wallet interactively, use future-proof syntax (can the signer decompile miniscript?), and support other capabilities. Not sure how much work has been done on this.
1 A) The authentication:
Just trust on first use, with warnings if data changes? @benma has done great research and reporting on this:
To receive securely, the offline signers need to be able to verify the following:
The receive address, which has to encode the hash of an ordinary multisig redeem script with no other spending conditions The key of the hardware wallet, which has to be one of the public keys in the redeem script The keypath of the displayed address in order to avoid ransom attacks if no restrictions are enforced by the hardware wallet The number of cosigners in order to prevent an attacker from adding more The threshold of required signatures to not be higher or lower than intended The xpubs of the cosigners in order to prevent an attacker from swapping them
The above is written for hardware wallets, but I believe any BIP written and code implemented should be for both HWWs and offline Core wallets. With descriptor wallets, I believe a lot of the above authentication can be automated by the info in the Account Map that all offline co-signers have.
To send securely, the offline signers need to be able to verify the following:
The recipient’s address, displayed and confirmed by the user like with singlesig The change address, having the same cosigners and threshold in an ordinary multisig script with no other spending conditions The change goes to an address at a keypath recoverable by the user
I think all the above is very important, since there have been many instances of devices not properly implementing the above security measures, so having a BIP for devices/software to comply with would be important. @Sjors and @achow101 have been doing a ton of work integrating HWWs. This looks like it will be merged soon: (https://github.com/bitcoin/bitcoin/pull/16546). After that, the UI will be worked on (https://github.com/bitcoin-core/gui/pull/4), and there is a currently-closed PR for HWW multisig functionality on top (https://github.com/bitcoin/bitcoin/pull/16895). Perhaps some of this code can be re-used for multisig with Core on offline computers, but I am not sure.
I believe having this ability would be an extensive security gain (being able to create a multisig wallet with Core on offline computers through the GUI).
- Represent multiple derivation paths with one descriptor (https://github.com/bitcoin/bitcoin/issues/17190)
Single descriptors make creating, backing up, and restoring multisignature wallets much simpler. For example:
To create a multisignature wallet in Bitcoin Core, you can currently:
- Create wallet
- Dump
hdseed - Create address, dump xpriv
- Repeat Steps 1-3 N times
- Create multisig wallet using descriptor containing all N xprvs (M of N multisig)
- Use the N
hdseeds along with Account Map as backup
However, the above wallet can not create change addresses. You need to create (backup and restore) a second descriptor for change addresses, even though most of the descriptor is the same, except for the derivation path at the end. This can be very time consuming/confusing for end users, especially when backing up by paper/hand.
For a comprehensive offline multisignature wallet, I believe this change needs to be implemented. Currently in Yeti, we bypass this by recommending coin control and only sending entire UTXO’s (which is a pretty bad user experience and short term solution we have chosen).
Some users like setting custom change descriptors (for example, for sending to an application for mixing change) so I believe this should be able to be done behind expert options, and perhaps this makes a single descriptor less controversial.
- QR code scanner (https://github.com/bitcoin/bitcoin/issues/9913)
QR codes are the most secure way to pass data between airgapped signers. I currently have a $300 bounty on implementing this. BlockchainCommons has a standard (BCR-2020-005) that is compatible with PSBTs (multiple QR codes checksummed; or a single animated QR code), and has a C++ reference implementation (https://github.com/BlockchainCommons/bc-ur).
- After the above (1-3) is finished, I believe implementing offline multisignature wallets into Bitcoin Core will be possible.
I am not trying to influence consensus (this should just be wallet code), and ultimately it is of course up to the developers and the community if these are changes that are good for Bitcoin, and if the above is how it should be implemented. I am just trying to put all the thoughts/discussions down in one place.
Developers who might be interested: @Sjors @gwillen @instagibbs @achow101
—–BEGIN PGP SIGNED MESSAGE—– Hash: SHA512
I, Robert Spigler, am offering a $1,500 bounty for implementing 1, 2, 3, and 4 (standard for coordination of co-signers, single descriptors, QR codes, and offline multisignature wallets) in Bitcoin Core.
This does not include the already existing $300 bounty for #3 (QR codes).
The bounty will be split between developers as I see most fair (author and substantial reviews/discussions).
The bounty has no expiration and will be paid in bitcoin.
The date is 2021-02-02. —–BEGIN PGP SIGNATURE—–
iQIzBAEBCgAdFiEEf4WKHNGE9pWzsby0UsewL8eQ8/AFAmAaJz0ACgkQUsewL8eQ 8/CVqw//ZOQkDabWlYxqcf669FqvsWRK/q/mNidaBor9gVwFiXZsBP1j7knGgpvZ WCpek6JpMU4b1ZA2jobbSAKcaEarUiBRMVoXWnHmeg0igJmNhZyhL9D4lvy1kUBd 3F8KhqZ0yIlAzGRWu6+CKOVlTMQFwS/giAgoWeQCa8a4Nx0WjbhtyMWvXQmXlbnJ 7zjN3nfJDi7CYxMGGyfnLLJSCdUGt205PIwphwI9OR2TJVwfl6rRLR1rzakCHOOa zvd6Ud0mGCHiJMvlWv5Qyk6KGm4O9XTVPYWU9DkWq1Jahv4MtZvb+n1DsgT6ZQxF gNZVOp+iuigEmgWe1Qw8wsiWjubJrVBhWcg3cFfchmRYefMo6+53RCYM8+VnbYEm VFts1rmMtLex8UTfrXX4FAla1WdPhlNFCNIlNnabBMTrck7WUTQdO07eNc6kI/wz QXBAbuLqIp3FEhLcsv9oZQIkQmtAwN2235aN+B0J7bFLaegBg2E+Ur3lIlDPKZvo U1r+NgDfNf9ZkA8rKJxRENCH5o46SbxI6gPYVTVY8NAy8pj2RFcGMYg1a0DEW1G2 zy/3/4Umud5Mr92ggkJWbKKe7HWqypYEXWhc+vo5fOoCY5XTJza0hOyiW+5vHKMM YGS81OAQfIV/MJFffSJ581uU6th1s+7g9nWjeT9vGqTSJbNd1P4= =Xm2a —–END PGP SIGNATURE—–
