Minor edit

1 files changed, 6 insertions, 6 deletions

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index afa4f47..855c5ed 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 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.
+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 <tt>KEY</tt> is included in the descriptor record and persisting the descriptor record in its storage.
 
 ===Setup Process===
 
@@ -71,7 +71,7 @@ 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 <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
-* 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 Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
 * The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
 * The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
@@ -100,10 +100,10 @@ The Signer is any software or hardware that controls the private keys and can si
 * 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 can support the descriptor or descriptor template.
-* 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 checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, 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 <tt>KEY</tt> 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 <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor must also be available for review upon user request. 
+* The Signer verifies that the wallet's first address is valid.
+* 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 <tt>KEY</tt> 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 <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template 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 <tt>KEY</tt> positions).
 * If all checks pass, the Signer must persist the descriptor record in its storage.
 
@@ -184,7 +184,7 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 
 This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
 
-The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards.
+The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> for multiple wallet creation sessions.
 
 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.