diff options
| author | Hugo Nguyen <hugh.hn@gmail.com> | 2021-05-05 20:05:08 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-05-05 20:05:08 -0700 |
| commit | f13cd8dde9e67003fcc952de02d0b63c4db5bbac (patch) | |
| tree | d8b05558c4a926ef0236560eac02c856328a35f2 | |
| parent | 0408b412f9147e402a2205b23c5ef942a75ddcb7 (diff) | |
| download | bips-f13cd8dde9e67003fcc952de02d0b63c4db5bbac.tar.xz | |
update Compatibility section
| -rw-r--r-- | bip-hugonguyen-bsms.mediawiki | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki index 9adc11d..8153ae6 100644 --- a/bip-hugonguyen-bsms.mediawiki +++ b/bip-hugonguyen-bsms.mediawiki @@ -69,7 +69,7 @@ The Signer is any software or hardware that controls the private keys and can si * The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (<tt>M</tt> and <tt>N</tt>). * The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy. -* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encryption section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer. +* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer. * If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped. =====Signer===== @@ -185,9 +185,13 @@ For signers that use QR codes to transmit data, key and descriptor records can b Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md UR Type Definition for BIP44 Accounts] and [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md UR Type Definition for Bitcoin Output Descriptors] for more details. ==Compatibility== -To comply with this standard, a Signer must be able to persist the descriptor record in its storage. +BSMS is opt-in, meaning existing multisig wallets can continue working as-is, with the caveat that current multisig solutions are full of pitfalls. Some of the problems have been described in the [[#Motivation]] section. -Existing multisig wallets should delay upgrading to the BSMS scheme until all participating Signers have added support for BSMS. +To comply with this standard, a Signer must be able to persist the descriptor record in its storage. + +Once a Signer has implemented BSMS, the user can create new multisig wallets using BSMS or migrate existing ones to BSMS. + +Existing multisig wallets should delay upgrading to BSMS until all participating Signers have implemented BSMS. ==Security== |