bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-07-06 17:46:00 +00:00
Code Issues Releases Wiki Activity

spelling: globally change "implementor" to "implementer"

Browse Source 
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.
This commit is contained in:
Jon Atack
2025-02-13 11:56:14 -06:00
parent 3c7b0d6498
commit 468e9759ba
12 changed files with 14 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
bip-0152.mediawiki
View File

@@ -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==