New glossary terms

[achow101]

Added the following new glossary terms:

• UASF
• MASF
• Node
• Full node
• Archival node
• Pruned node
• Block size limit

Closes #1605, #1539, #1240

If this is accepted, please pay the bounty to 1AjFwHanPewurVms4Z3ExtapHmKWF6aTVS

[harding]

I think it would be best to combine all the node entries into a single entry (node.yaml) and use synonyms so that they appear in the glossary but all link to the same entry. A section could be added to the developer documentation to describe the different roles a node can fulfill.

I'm also mildly opposed to adding the UASF and MASF entries since we don't go into the details of either miner signaling nor flag days in the developer documentation, which is what this glossary primarily serves. For example, I think it's particularly important to make clear that all successful forks, not just UASFs, are ultimately enforced by users and for that I think we need more text written and at least one link to be provided in the links section of each entry.

Block size limit should probably link to https://bitcoin.org/en/developer-reference#serialized-blocks , which is where we describe the rule in our documentation.

This patch should fix this CI error:

diff --git a/_includes/devdoc/bitcoin-core/rpcs/rpcs/listbanned.md b/_includes/devdoc/bitcoin-core/rpcs/rpcs/listbanned.md
index ba33c7da..3242587b 100644
--- a/_includes/devdoc/bitcoin-core/rpcs/rpcs/listbanned.md
+++ b/_includes/devdoc/bitcoin-core/rpcs/rpcs/listbanned.md
@@ -48,7 +48,7 @@ The `listbanned` RPC {{summary_listBanned}}
 - n: "→ →<br>`ban_reason`"
   t: "string"
   p: "Required<br>(exactly 1)"
-  d: "Set to one of the following reasons:<br> `node misbehaving` if the node was banned by the client because of DoS violations<br> `manually added` if the node was manually banned by the user"
+  d: "Set to one of the following reasons:<br> `node misbehaving`<!--noref--> if the node was banned by the client because of DoS violations<br> `manually added` if the node was manually banned by the user"
 
 {% enditemplate %}

[achow101]

I removed the archival node, pruned node, and full node terms. Instead I added an extra description in the devguide under the intro for the P2P network section.

I added the link for block size limit.

I'm not sure about what to do with UASF and MASF. Maybe add something here: https://bitcoin.org/en/developer-guide#consensus-rule-changes ?

[harding]

@achow101 thanks for the updates! The node and block size commits LGTM (but I haven't previewed yet). For the xASF commit, I think that's the right place for it. Maybe something like the following text just above the final paragraph in that section that begins with "Resources".

Consensus rule changes may be activated in various ways. During Bitcoin's first two years, Satoshi Nakamoto performed several soft forks by just releasing the backwards-compatible change in a client that began immediately enforcing the new rule. At least one Nakamoto soft fork (where the block size limit was added) was performed as a flag day, as was the BIP30 soft fork, where the new rule began to be enforced at a preset time or block height.

Later soft forks waited for 95% of hash rate to signal readiness for users to begin enforcing the new rules, called [Miner Activated Soft Forks][/en/glossary/masf]{:#term-masf}{:.term} (MASF). By 2017, miners had not signaled readiness for the BIP141 MASF even after more than 6 months, so several community members proposed [User Activated Soft Forks][/en/glossary/uasf]{:#term-uasf}{:.term} (UASF) that would either remove the wait for miner signaling or make it optional---a return to flag day soft forks, although potentially with more sophistication.

Note I put the two links above inside code tics here so that GitHub Markdown renders them for you to copy/paste, but they should be just in regular text in the doc so they get turned into links. Also, I haven't previewed that change myself; the tests should catch it if it doesn't render properly or if the link is broken, but somebody should preview it just to be sure.

[wbnns]

@achow101 Hey, awesome work here, too - I think all that remains before final review is the xASF change. @harding Thanks for checking this stuff out.

[achow101]

Updated with paragraphs describing UASFs and MASFs

[harding]

One nitpick, otherwise untested ACK.

[harding]

I'm not sure BIP16 is a good example of a flag day activation, given that it had explicit miner voting as a prerequisite, even though I think the measurement was performed outside the node code and then a flag day was coded in rather than using the later ISM method. Maybe just mention BIP30?

[wbnns]

@achow101 Thanks again for working on this (and @harding too for a good bit of review).

Unless others object, this will be merged on Thursday, May 25th.

[wbnns]

@achow101 Merged; Bounty paid together with #1611. 👍