Minor Text Corrections in BIP-0014 and BIP-0342 #1872

1. 
   vtjl10 commented at 8:42 am on June 19, 2025: none

   Description:
   This pull request updates minor wording in BIP-0014 and BIP-0342 for clarity and consistency.

   • Corrects “commitish” to “commit hash” in BIP-0014
   • Fixes a typo (“unparseable”) in BIP-0342
2. Update bip-0014.mediawiki 6f36acbe77
3. Update bip-0342.mediawiki e781cf0aca
4. jonatack added the label Typo-to-be-collected on Jun 19, 2025
5. in bip-0014.mediawiki:72 in 6f36acbe77 outdated

   68@@ -69,7 +69,7 @@ Here bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal
   69 * Version numbers in the form of Major.Minor.Revision (2.6.41)
   70 * Repository builds using a date in the format of YYYYMMDD (20110128)
   71 
   72-For git repository builds, implementations are free to use the git commitish. However the issue lies in that it is not immediately obvious without the repository which version precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement.
   73+For git repository builds, implementations are free to use the git committish. However the issue lies in that it is not immediately obvious without the repository which version precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement.
   

   ---

   ---

   

   murchandamus commented at 10:38 pm on June 19, 2025:

   I don’t think this says “commit hash”.
6. in bip-0342.mediawiki:63 in e781cf0aca

   59@@ -60,7 +60,7 @@ Validation of such inputs must be equivalent to performing the following steps i
   60 * An <code>OP_SUCCESSx</code> could be turned into a functional opcode through a softfork. Unlike <code>OP_NOPx</code>-derived opcodes which only have read-only access to the stack, <code>OP_SUCCESSx</code> may also write to the stack. Any rule changes to an <code>OP_SUCCESSx</code>-containing script may only turn a valid script into an invalid one, and this is always achievable with softforks.
   61 * Since <code>OP_SUCCESSx</code> precedes size check of initial stack and push opcodes, an <code>OP_SUCCESSx</code>-derived opcode requiring stack elements bigger than 520 bytes may uplift the limit in a softfork.
   62 * <code>OP_SUCCESSx</code> may also redefine the behavior of existing opcodes so they could work together with the new opcode. For example, if an <code>OP_SUCCESSx</code>-derived opcode works with 64-bit integers, it may also allow the existing arithmetic opcodes in the ''same script'' to do the same.
   63-* Given that <code>OP_SUCCESSx</code> even causes potentially unparseable scripts to pass, it can be used to introduce multi-byte opcodes, or even a completely new scripting language when prefixed with a specific <code>OP_SUCCESSx</code> opcode.</ref>.
   64+* Given that <code>OP_SUCCESSx</code> even causes potentially unparsable scripts to pass, it can be used to introduce multi-byte opcodes, or even a completely new scripting language when prefixed with a specific <code>OP_SUCCESSx</code> opcode.</ref>.
   

   ---

   ---

   

   murchandamus commented at 10:41 pm on June 19, 2025:

   While “parsable” is preferred, “parseable” is a recognized alternative spelling of it. https://en.wiktionary.org/wiki/parsable

   ---

   

   jonatack commented at 0:36 am on June 20, 2025:

   Agree, the current text is fine.
7. 
   murchandamus commented at 10:44 pm on June 19, 2025: contributor

   Neither of these two changes is a significant improvement.
8. 
   jonatack commented at 0:41 am on June 20, 2025: member

   @vtjl10 Thank you for your proposal. We usually no longer directly merge PRs of this type, as we have been seeing a high frequency of them, they generally require more time than they are worth, and they create unneeded notifications for subscribers to this repository. (There may be exceptions for higher-value proposals by longstanding reviewers of this repository.) We instead batch this type of changes into an occasional cleanup pull by the editors that might mention the authors of some of the more valuable typos found. Thanks again.
9. jonatack closed this on Jun 20, 2025

   ---

Contributors
vtjl10 murchandamus jonatack

Labels
Typo-to-be-collected