spelling: globally change "implementor" to "implementer"

Although the variant "implementor" predominated for much of the late 20th
century, today "implementer" is considered standard, and the former spelling
triggers the typos spelling checker.

bip-0001.mediawiki

@@ -23,7 +23,7 @@ Because the BIPs are maintained as text files in a versioned repository, their r
 There are three kinds of BIP:
 
 * A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
-* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
+* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
 * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
 
 ==BIP Work Flow==

bip-0002.mediawiki

@@ -183,7 +183,7 @@ BIPs may include auxiliary files such as diagrams. Auxiliary files should be inc
 There are three kinds of BIP:
 
 * A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
-* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
+* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational BIPs or follow their advice.
 * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
 
 ==BIP status field==

bip-0043.mediawiki

@@ -20,7 +20,7 @@ based on algorithm described in BIP-0032 (BIP32 from now on).
 
 Although Hierarchical Deterministic Wallet structure as described by BIP32
 is an important step in user experience and security of the cryptocoin wallets,
-the BIP32 specification offers implementors too many degrees of freedom.
+the BIP32 specification offers implementers too many degrees of freedom.
 Multiple implementations may claim they are BIP32 compatible, but in fact
 they can produce wallets with different logical structures making them
 non-interoperable. This situation unfortunately renders "BIP32 compatible"

bip-0046.mediawiki

@@ -97,7 +97,7 @@ To derive the address from the above calculated public key and timelock, we crea
 
 === Message signing ===
 
-In order to support signing of certificates, implementors should support signing ASCII messages.
+In order to support signing of certificates, implementers should support signing ASCII messages.
 
 The certificate message is defined as `"fidelity-bond-cert" || "|" || cert_pubkey || "|" || cert_expiry`.
 
@@ -130,7 +130,7 @@ address             = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xksps
 // Note that as signatures contains a random nonce, it might not be exactly the same when your code generates it
 // p2pkh address is the p2pkh address corresponding to the derived public key, it can be used to verify the message
 //  signature in any wallet that supports Verify Message.
-// As mentioned before, it is more important for implementors of this standard to support signing such messages, not verifying them
+// As mentioned before, it is more important for implementers of this standard to support signing such messages, not verifying them
 message       = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
 address       = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
 p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6

bip-0061.mediawiki

@@ -149,7 +149,7 @@ The reject message is backwards-compatible; older peers that do not recognize th
 
 == Implementation notes ==
 
-Implementors must consider what happens if an attacker either sends them
+Implementers must consider what happens if an attacker either sends them
 reject messages for valid transactions/blocks or sends them random
 reject messages, and should beware of possible denial-of-service attacks.
 For example, notifying the user of every reject message received

bip-0118.mediawiki

@@ -142,7 +142,7 @@ By design, <code>SIGHASH_ANYPREVOUT</code> and <code>SIGHASH_ANYPREVOUTANYSCRIPT
 Both <code>SIGHASH_ALL</code> and <code>SIGHASH_ANYONECANPAY</code> signatures prevent signature replay by committing to one or more inputs, so replay of the signature is only possible if the same input can be spent multiple times, which is not possible on the Bitcoin blockchain (due to enforcement of [[bip-0030.mediawiki|BIP 30]]).
 With <code>SIGHASH_ANYPREVOUT</code> signature replay is possible for different UTXOs with the same <code>scriptPubKey</code> and the same value, while with <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> signature replay is possible for any UTXOs that reuse the same BIP 118 public key in one of their potential scripts.
 
-As a consequence, implementors MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable.
+As a consequence, implementers MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable.
 
 ==== Malleability ====
 

bip-0119.mediawiki

@@ -213,7 +213,7 @@ a NOP for consensus (during block validation).
 In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
 PayToBareDefaultCheckTemplateVerifyHash
 with no scriptSig data may (is recommended to) be made standard to permit relaying. Future template types may be
-standardized later as policy changes at the preference of the implementor.
+standardized later as policy changes at the preference of the implementer.
 
 ==Reference Implementation==
 
@@ -480,7 +480,7 @@ If the scriptSigs non-nullity is not cached, then the O(T) transaction could be
 times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations
 over all variable length fields in a transaction.
 
-For CTV, the Denial-of-Service exposure and validation costs are relatively clear. Implementors must be careful
+For CTV, the Denial-of-Service exposure and validation costs are relatively clear. Implementers must be careful
 to correctly code CTV to make use of existing caches and cache the (new for CTV) computations over scriptSigs.
 Other more flexible covenant proposals may have a more difficult time solving DoS issues as more complex computations may
 be less cacheable and expose issues around quadratic hashing, it is a tradeoff CTV makes in favor of cheap and secure

bip-0123.mediawiki

@@ -25,7 +25,7 @@ This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU A
 
 ==Motivation==
 
-Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them.
+Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to support them.
 
 In order to have a BIP process which more closely reflects the interoperability requirements, it is necessary to categorize BIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.
 

bip-0135.mediawiki

@@ -274,7 +274,7 @@ mechanisms (top bits 010 and 011).
 The following guidelines are suggested for selecting the parameters for a fork:
 
 # '''name''' SHOULD be selected such that no two forks, concurrent or otherwise, ever use the same name.
-# '''bit''' SHOULD be selected such that no two concurrent forks use the same bit. Implementors should make an effort to consult resources such as [2] to establish whether the bit they wish to use can reasonably be assumed to be unclaimed by a concurrent fork, and to announce their use ('claim') of a bit for a fork purpose on various project mailing lists, to reduce chance of collisions.
+# '''bit''' SHOULD be selected such that no two concurrent forks use the same bit. Implementers should make an effort to consult resources such as [2] to establish whether the bit they wish to use can reasonably be assumed to be unclaimed by a concurrent fork, and to announce their use ('claim') of a bit for a fork purpose on various project mailing lists, to reduce chance of collisions.
 # '''starttime''' SHOULD be set to some date in the future, approximately one month after a software release date which includes the fork signaling.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
 # '''timeout''' is RECOMMENDED to be 1 year (31536000 seconds) after starttime.
 # '''windowsize''' SHOULD be set large enough to allow reception of an adequately precise signal. A good high-resolution value would be 2016 blocks as used in BIP9. It is NOT RECOMMENDED to use a windowsize less than 100 blocks.

bip-0152.mediawiki

@@ -195,7 +195,7 @@ Compact blocks version 2 is almost identical to version 1, but supports segregat
 
 # Note that this spec does not change the requirement that nodes only relay information about blocks which they have fully validated in response to GETDATA/GETHEADERS/GETBLOCKS/etc requests. Nodes which announce using CMPCTBLOCK message and then receive a request for associated block data SHOULD ensure that messages do not go unresponded to, and that the appropriate data is provided after the block has been validated, subject to standard message-response ordering requirements. Note that no requirement is added that the node respond to the request with the new block included in eg GETHEADERS or GETBLOCKS messages, but the node SHOULD re-announce the block using the associated announcement methods after validation has completed if it is not included in the original response. On the other hand, nodes SHOULD delay responding to GETDATA requests for the block until validation has completed, stalling all message processing for the associated peer. REJECT messages are not considered "responses" for the purpose of this section.
 
-# As a result of the above requirements, implementors may wish to consider the potential for the introduction of delays in responses while remote peers validate blocks, avoiding delay-causing requests where possible.
+# As a result of the above requirements, implementers may wish to consider the potential for the introduction of delays in responses while remote peers validate blocks, avoiding delay-causing requests where possible.
 
 ==Justification==
 

bip-0174.mediawiki

@@ -762,7 +762,7 @@ the key.
 
 ===Handling Duplicated Keys===
 
-Keys within each scope should never be duplicated; all keys in the format are unique. PSBTs containing duplicate keys are invalid. However implementors
+Keys within each scope should never be duplicated; all keys in the format are unique. PSBTs containing duplicate keys are invalid. However implementers
 will still need to handle events where keys are duplicated when combining transactions with duplicated fields. In this event, the software may choose
 whichever value it wishes.<ref>'''Why can the values be arbitrarily chosen?''' When there are duplicated keys, the values that can be chosen will either be
 valid or invalid. If the values are invalid, a signer would simply produce an invalid signature and the final transaction itself would be invalid. If the

bip-0340.mediawiki

@@ -289,7 +289,7 @@ The reference implementation is for demonstration purposes only and not to be us
 
 == Changelog ==
 
-To help implementors understand updates to this BIP, we keep a list of substantial changes.
+To help implementers understand updates to this BIP, we keep a list of substantial changes.
 
 * 2022-08: Fix function signature of lift_x in reference code
 * 2023-04: Allow messages of arbitrary size