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
Description:
This pull request updates minor wording in BIP-0014 and BIP-0342 for clarity and consistency.
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.
I don’t think this says "commit hash".
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>.
While "parsable" is preferred, "parseable" is a recognized alternative spelling of it. https://en.wiktionary.org/wiki/parsable
Agree, the current text is fine.
Neither of these two changes is a significant improvement.
@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.