BIP118: remove subliminal advertising of Simplicity

Author: ajtowns

bip-0118.mediawiki

@@ -54,7 +54,7 @@ This proposal only supports ANYPREVOUT signatures via script path spends, and do
 This is for two reasons: first, not supporting key path spends allows this proposal to be independent of the core changes included in [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]; second, it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent.
 </ref> (<code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, and <code>CHECKSIGADD</code>) for public keys that have a length of 33 bytes and a first byte of <code>0x01</code> or the public key which is precisely the single byte vector <code>0x01</code><ref>'''Use of 0x01 public key type'''
 Because <code>OP_0</code> leaves an empty vector on the stack it would not satisfy [[bip-0342.mediawiki|BIP 342]]'s rules for unknown public key types. As such, it is convenient to use one of <code>OP_1..OP_16</code> or <code>OP_1NEGATE</code> as a way to reference the taproot internal key.
-To keep things as simple as possible, we simply use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.
+To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.
 </ref>.
 These keys are termed '''BIP 118 public keys'''.
 
@@ -67,9 +67,9 @@ The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by r
 
 ==== Public key ====
 
-To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
+To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
 
-To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply remove the <code>0x01</code> prefix and use the remaining 32 bytes.
+To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the <code>0x01</code> prefix and use the remaining 32 bytes.
 
 ==== Signature message ====
 
@@ -161,7 +161,7 @@ Depending on the changes to the inputs, this might conflict with the original tr
 
 Further, for a chain of transactions using the same <code>scriptPubKey</code> and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions.
 
-This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can simply be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.
+This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.
 
 However child transactions that are authorised by a <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code> signature will need new signatures if their inputs are malleated in this way.
 This risk may be mitigated somewhat by using [[bip-0068.mediawiki|BIP 68]]/[[bip-0112.mediawiki|BIP 112]] relative time locks before spending a UTXO that had been authorised via an ANYPREVOUT signature with <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code>: a relative timelock can ensure that the inputs have enough confirmations that they can only be replaced in the event of a large block reorg.