BIP 8: Move recommendation for "name" to "Selection guidelines"

Author: luke-jr

bip-0008.mediawiki

@@ -34,7 +34,7 @@ Block time is somewhat unreliable and may be intentionally or unintentionally in
 
 Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
-# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
+# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier.
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
 # The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
 # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
@@ -44,7 +44,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 
 The following guidelines are suggested for selecting these parameters for a soft fork:
 
-# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
+# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.