Merge pull request #1610 from achow101/new-glossary-terms

New glossary terms

_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<!--noref--> 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"
 
 {% enditemplate %}
 
@@ -85,4 +85,4 @@ Result:
 * [SetBan][rpc setban]: {{summary_setBan}}
 * [ClearBanned][rpc clearbanned]: {{summary_clearBanned}}
 
-{% endautocrossref %}
+{% endautocrossref %}

_includes/devdoc/guide_block_chain.md

@@ -317,6 +317,22 @@ a hard or soft fork. For example, "increasing the block size above 1 MB
 requires a hard fork." In this example, an actual block chain fork is
 not required---but it is a possible outcome.
 
+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. Multiple soft forks such as BIP30 have
+been activated via a flag day where the new rule began to be enforced at a 
+preset time or block height. Such forks activated via a flag day are known as
+[User Activated Soft Forks][/en/glossary/uasf]{:#term-uasf}{:.term} (UASF) as
+they are dependent on having sufficient users (nodes) to enforce the new rules
+after the flag day.
+
+Later soft forks waited for a majority of of hash rate (typically 75% or 95%) 
+to signal their readiness for enforcing the new consensus rules. Once the signalling
+threshold has been passed, all nodes will begin enforcing the new rules. Such
+forks are known as [Miner Activated Soft Forks][/en/glossary/masf]{:#term-masf}{:.term} (MASF)
+as they are dependent on miners for activation.
+
 **Resources:** [BIP16][], [BIP30][], and [BIP34][] were implemented as
 changes which might have lead to soft forks. [BIP50][] describes both an
 accidental hard fork, resolved by temporary downgrading the capabilities

_includes/devdoc/guide_p2p_network.md

@@ -10,10 +10,13 @@ http://opensource.org/licenses/MIT.
 {% autocrossref %}
 
 The Bitcoin network protocol allows full nodes
-([peers][peer]{:#term-peer}{:.term}) to collaboratively maintain a
+(peers) to collaboratively maintain a
 [peer-to-peer network][network]{:#term-network}{:.term} for block and
-transaction exchange. Many SPV clients also use this protocol to connect
-to full nodes.
+transaction exchange. Full nodes download and verify every block and transaction
+prior to relaying them to other nodes. Archival nodes are full nodes which
+store the entire blockchain and can serve historical blocks to other nodes.
+Pruned nodes are full nodes which do not store the entire blockchain. Many SPV 
+clients also use the Bitcoin network protocol to connect to full nodes.
 
 Consensus rules do not cover networking, so Bitcoin programs may use
 alternative networks and protocols, such as the [high-speed block relay