Multi: switch from k-of-n/n-of-n to t-of-k/k-of-k

Suggested by Murchandamus

ch12.asciidoc

@@ -95,7 +95,7 @@ full. They cannot be divided or partially spent.
 
 Quorum of Control:: Multisignature constraints in scripts impose a
 quorum of authorization, predefined in the multisignature scheme. The
-M-of-N requirement is enforced by the consensus rules.
+requirement is enforced by the consensus rules.
 
 Timelock/Aging:: Any script clause containing a relative or absolute
 timelock can only be executed after its age exceeds the time specified.

chapters/authorization-authentication.adoc

@@ -323,10 +323,10 @@ image::../images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
 ((("transactions", "advanced", "multisignature
 scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting",
 "multisignature scripts", id="Smulti07")))((("multisignature
-scripts")))Multisignature scripts set a condition where N public keys
-are recorded in the script and at least K of those must provide
-signatures to spend the funds. This is also known as a K-of-N scheme,
-where N is the total number of keys and K is the threshold of signatures
+scripts")))Multisignature scripts set a condition where _k_ public keys
+are recorded in the script and at least _t_ of those must provide
+signatures to spend the funds. This is also known as a "M-of-N" scheme,
+where M is the total number of keys and N is the threshold of signatures
 required for validation. For example, a 2-of-3 multisignature is one
 where three public keys are listed as potential signers and at least two
 of those must be used to create signatures for a valid transaction to
@@ -335,9 +335,9 @@ spend the funds.
 [TIP]
 ====
 Some Bitcoin documentation, including earlier editions of this book,
-uses the term M-of-N for traditional multisignature.  However, it's hard
-to tell "M" and "N" apart when they're spoken, so we use the alternative
-K-of-N.  Both phrases refer to the same type of signature scheme.
+uses the term "m-of-n" for traditional multisignature.  However, it's hard
+to tell "m" and "n" apart when they're spoken, so we use the alternative
+t-of-k.  Both phrases refer to the same type of signature scheme.
 ====
 
 At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 3
@@ -353,14 +353,14 @@ P2SH in <<p2sh>>.   All other scripts are consensus limited to 20 keys
 per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
 script may include multiple of those opcodes.
 
-The general form of a output script setting an K-of-N multisignature
+The general form of a output script setting a t-of-k multisignature
 condition is:
 
 ----
-K <Public Key 1> <Public Key 2> ... <Public Key N> N OP_CHECKMULTISIG
+t <Public Key 1> <Public Key 2> ... <Public Key k> k OP_CHECKMULTISIG
 ----
 
-where N is the total number of listed public keys and K is the threshold
+where _k_ is the total number of listed public keys and _t_ is the threshold
 of required signatures to spend the output.
 
 An output script setting a 2-of-3 multisignature condition looks like
@@ -448,7 +448,7 @@ OP_0 <Signature B> <Signature C>
 
 Some people believe this oddity was a bug in the original code for
 Bitcoin, but a plausible alternative explanation exists.  Verifying
-K-of-N signatures can require many more than K or N signature checking
+t-of-k signatures can require many more than t or k signature checking
 operations.  Let's consider a simple example of 1-in-3, with the
 following combined script:
 

chapters/signatures.adoc

@@ -659,11 +659,11 @@ available at the time of writing.
 [[schnorr_threshold_signatures]]
 ==== Schnorr-based scriptless threshold signatures
 
-Scriptless multisignature protocols only work for n-of-n signing.
+Scriptless multisignature protocols only work for k-of-k signing.
 Everyone with a partial public key that becomes part of the aggregated
 public key must contribute a partial signature and partial nonce to the
 final signature.  Sometimes, though, the participants want to allow a
-subset of them to sign, such as k-of-n where k participants can sign for
+subset of them to sign, such as t-of-k where a threshold (t) number of participants can sign for
 a key constructed by n participants.  That type of signature is called a
 _threshold signature_.
 
@@ -695,7 +695,7 @@ than a non-participant who didn't have a share.
 
 A secure secret sharing scheme prevents participants from learning
 anything about the secret unless they combine the minimum threshold
-number of shares.  For example, Alice can choose a threshold (_k_) of
+number of shares.  For example, Alice can choose a threshold of
 +2+ if she wants any two of Bob, Carol, and Dan to be able to
 reconstruct her secret.  The best known secure secret sharing algorithm
 is _Shamir's Secret Sharing Scheme_, commonly abbreviated SSSS and named
@@ -715,7 +715,7 @@ To see how multisignatures and verifiable secret sharing works for
 Alice, Bob, and Carol, imagine they each wish to receive funds that can
 be spent by any two of them.  They collaborate as described in
 <<schnorr_multisignatures>> to produce a regular multisignature public
-key to accept the funds (n-of-n).  Then each participant derives two
+key to accept the funds (k-of-k).  Then each participant derives two
 secret shares from their private key--one for each of two the other
 participants. The shares allow any two of them to reconstruct the
 originating partial private key for the multisignature. Each participant

tools/discouraged.sh

@@ -5,7 +5,7 @@ for f in $( git ls-files | grep -v "$0" ) ; do
   # 1. Find discouraged words
   # 2. Ignore things that look like json or code (Bitcoin Core RPCs use many discouraged words)
   egrep -if <( sed "1,/[S]TART DISCOURAGED WORDS/d" "$0" ) "$f" \
-    | grep -v "[\"'][a-zA-Z]\+[\"']" \
+    | grep -v "[\"'][a-zA-Z-]\+[\"']" \
     | if grep . ; then
       echo "DISCOURAGED WORDS FOUND IN $f"
     fi
@@ -37,3 +37,7 @@ BIP [0-9]
 witness field
 witness element
 feerate
+m-of-m
+m-of-n
+n-of-n
+k-of-n