diff options
Diffstat (limited to 'bip-hugonguyen-bsms.mediawiki')
| -rw-r--r-- | bip-hugonguyen-bsms.mediawiki | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki index 0ce18c5..9e7ec7c 100644 --- a/bip-hugonguyen-bsms.mediawiki +++ b/bip-hugonguyen-bsms.mediawiki @@ -87,7 +87,7 @@ The Signer is any software or hardware that controls the private keys and can si * The Coordinator verifies that the key records have compatible specification versions. * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>. * If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record. -* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction. +* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. The third line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction. * The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>. * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>. @@ -99,10 +99,10 @@ The Signer is any software or hardware that controls the private keys and can si * The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>. * The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext. * The Signer verifies that it can support the included specification version. -* The Signer verifies that it is compatible with the derivation path restrictions. * The Signer verifies the descriptor’s <tt>CHECKSUM</tt>. * The Signer verifies that it can support the descriptor. * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> 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). @@ -214,8 +214,8 @@ H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5 * Coordinator ** <tt>my_multisig_wallet.bsms</tt>: <pre>BSMS 1.0 -/0/*,/1/* wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p +/0/*,/1/* bc1qqqen0mj98v3mpr5esh4g22llu0wj4c6y2wj3q7l5tcqlr5au4nesyfh7rr</pre> ===Mode: <tt>STANDARD</tt> Encryption=== |