From 9771c5e2a8a04a68499604d8d2c2f8ac7e8594b4 Mon Sep 17 00:00:00 2001 From: Hugo Nguyen Date: Mon, 19 Apr 2021 09:19:28 -0700 Subject: replace XPUBs with keys to be more generic --- bip-hugonguyen-bsms.mediawiki | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki index 84c5f88..cf2e9c9 100644 --- a/bip-hugonguyen-bsms.mediawiki +++ b/bip-hugonguyen-bsms.mediawiki @@ -55,7 +55,7 @@ The Coordinator initiates the multisig setup. The Coordinator determines what ty ====Signer==== -The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains an Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage. +The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains a public key or an Extended Public Key (XPUB) -- to the Coordinator, verifying that its key is included in the descriptor record and persisting the descriptor record in its storage. ===Setup Process=== @@ -71,8 +71,8 @@ The Signer is any software or hardware that controls the private keys and can si =====Signer===== * The Signer initiates the multisig wallet creation session by setting the TOKEN. The Signer derives an ENCRYPTION_KEY from the TOKEN. The Signer can keep the session open until a different value for the TOKEN is set. -* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the XPUB at that derivation path. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing XPUBs for different wallets. -* The first line in the record must be the specification version (BSMS 1.0 as of this writing). The second line must be the hex-encoded TOKEN. The third line must be the KEY. The KEY is an XPUB plus its key origin information, written in the descriptor-defined format, i.e.: [{master key fingerprint}/{derivation path}]{XPUB}. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a SIG, whereas SIG is the signature generated by using the private key associated with the XPUB to sign the first four lines. The signature should follow [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], legacy format accepted. +* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the key at that derivation path. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing keys for different wallets. +* The first line in the record must be the specification version (BSMS 1.0 as of this writing). The second line must be the hex-encoded TOKEN. The third line must be the KEY. The KEY is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: [{master key fingerprint}/{derivation path}]{KEY}. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a SIG, whereas SIG is the signature generated by using the private key associated with the public key or XPUB to sign the first four lines. The signature should follow [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], legacy format accepted. * The Signer calculates the Message Authentication Code (MAC) for the record. The first 16 bytes of the MAC serves as the Initialization Vector (IV) for the encryption. * The Signer encrypts the key record with the ENCRYPTION_KEY and IV. * The Signer encodes the MAC and the ciphertext into hexadecimal format, then concatenates the results: (MAC || ciphertext). @@ -103,8 +103,8 @@ The Signer is any software or hardware that controls the private keys and can si * The Signer checks that its KEY is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the KEYs and not using shortcuts such as matching fingerprints, which is trivial to spoof. * The Signer verifies that it is compatible with the derivation path restrictions. * The Signer verifies that the wallet's first address is valid given the descriptor and the path restrictions. -* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, M, N, and the position(s) of the Signer's own XPUB in the policy script. The total number of Signers, N, is important to prevent a KEY insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor must also be available for review upon user request. -* Parties must check with each other that all Signers have the same confirmation (except for the key positions). +* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, M, N, and the position(s) of the Signer's own KEY in the policy script. The total number of Signers, N, is important to prevent a KEY insertion attack. The position is important for scripts where KEY order matters. When applicable, all positions of the KEY must be displayed. The full descriptor must also be available for review upon user request. +* Parties must check with each other that all Signers have the same confirmation (except for the KEY positions). * If all checks pass, the Signer must persist the descriptor record in its storage. This completes the setup. @@ -172,7 +172,7 @@ The TOKEN is used to encrypt the two rounds of communication between th The wallet's first address, on the other hand, can be used to verify the integrity of the multisig configuration. An attacker who tampers with the multisig configuration must also change the wallet's first address. Parties must check with each other that all Signers confirm to the same address and policy parameters to reduce the chance of tampering. ==Privacy== -Encryption helps improve the privacy of the wallet by avoiding sharing XPUBs and descriptors in plaintext. +Encryption helps improve the privacy of the wallet by avoiding sharing keys and descriptors in plaintext. If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the TOKEN, and to completely erase knowledge of the TOKEN after the multisig wallet has been set up. @@ -403,7 +403,7 @@ sh(wsh(multi(2,[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ ==Acknowledgement== -Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala and others for their feedback on the specification. +Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Andrew Chow and others for their feedback on the specification. ==References== -- cgit v1.2.3