update bips submodule and build

Author: github-actions[bot]

bips

@@ -57,7 +57,7 @@ BIP authors are responsible for collecting community feedback on both the initia
 
 It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
 
-The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under <a href="#BIP_Editors" target="_blank">BIP Editors</a> below. Also see <a href="#BIP_Editor_Responsibilities__Workflow" target="_blank">BIP Editor Responsibilities & Workflow</a>. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
+The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under <a href="#bip-editors" target="_blank">BIP Editors</a> below. Also see <a href="#bip-editor-responsibilities--workflow" target="_blank">BIP Editor Responsibilities & Workflow</a>. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad.
 
 Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject.
 

web/content/1/index.md

@@ -103,7 +103,7 @@ The Signer is any software or hardware that controls the private keys and can si
 
 *  The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (`M` and `N`).
 *  The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy.
-*  If encryption is enabled, the Coordinator distributes a secret `TOKEN` to each Signer over a secure channel. The Signer can use the `TOKEN` to derive an `ENCRYPTION_KEY`. Refer to the <a href=" Encryption" target="_blank"> Encryption</a> section below for details on the `TOKEN`, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common `TOKEN` for all Signers, or to have one per Signer.
+*  If encryption is enabled, the Coordinator distributes a secret `TOKEN` to each Signer over a secure channel. The Signer can use the `TOKEN` to derive an `ENCRYPTION_KEY`. Refer to the <a href=" encryption" target="_blank"> encryption</a> section below for details on the `TOKEN`, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common `TOKEN` for all Signers, or to have one per Signer.
 *  If encryption is disabled, the `TOKEN` is set to `0x00`, and all the encryption/decryption steps below can be skipped.
 
 
@@ -242,7 +242,7 @@ Also refer to <a href="https://github.com/BlockchainCommons/Research/blob/master
 
 This specification is not backwards compatible with existing multisig implementations.
 
-BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the <a href="#Motivation" target="_blank">#Motivation</a> section.
+BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the <a href="#motivation" target="_blank">#motivation</a> section.
 
 To comply with this standard, a Signer must be able to persist the descriptor record in its storage.
 

web/content/129/index.md

@@ -51,7 +51,7 @@ While the goal of this work is explicitly not to reduce block transfer latency,
 
 <img src=bip-0152/protocol-flow.png></img>
 
-The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed <a href="#Implementation_Notes" target="_blank">later</a>. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a `sendcmpct` message. In this mode, peers send new block announcements with the short transaction IDs already (via a `cmpctblock` message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a `getblocktxn`/`blocktxn` roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
+The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed <a href="#implementation-notes" target="_blank">later</a>. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a `sendcmpct` message. In this mode, peers send new block announcements with the short transaction IDs already (via a `cmpctblock` message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a `getblocktxn`/`blocktxn` roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
 
 The "low-bandwidth" mode is enabled by setting the first boolean to 0 in a `sendcmpct` message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK `getdata` request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a `getblocktxn`/`blocktxn` roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used.
 

web/content/152/index.md

@@ -140,13 +140,13 @@ BIPs should be written in mediawiki or markdown format.
 
 Each BIP should have the following parts:
 
-*  Preamble -- Headers containing metadata about the BIP (<a href=" BIP header preamble" target="_blank">see below</a>).
+*  Preamble -- Headers containing metadata about the BIP (<a href=" bip-header-preamble" target="_blank">see below</a>).
 
 
 *  Abstract -- A short (~200 word) description of the technical issue being addressed.
 
 
-*  Copyright -- The BIP must be explicitly licensed under acceptable copyright terms (<a href=" BIP licensing" target="_blank">see below</a>).
+*  Copyright -- The BIP must be explicitly licensed under acceptable copyright terms (<a href=" bip-licensing" target="_blank">see below</a>).
 
 
 *  Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms.

web/content/2/index.md

@@ -57,7 +57,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
 <h3> BNF grammar </h3>
 
 
-(See also <a href="#Simpler syntax" target="_blank">a simpler representation of syntax</a>)
+(See also <a href="#simpler-syntax" target="_blank">a simpler representation of syntax</a>)
 
 ```
  bitcoinurn      = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
@@ -82,7 +82,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit
 * label: Label for that address (e.g. name of receiver)
 * address: bitcoin address
 * message: message that is shown to the user after scanning the QR code
-* size: amount of base bitcoin units (<a href=" Transfer amount/size" target="_blank">see below</a>)
+* size: amount of base bitcoin units (<a href=" transfer-amountsize" target="_blank">see below</a>)
 * send: used to send bitcoin, rather than to request them
 * (others): optional, for future extensions
 
@@ -132,7 +132,7 @@ Make it possible for later generations to improve our work, to mend our errors,
 
 
 This section is non-normative and does not cover all possible syntax.
-Please see the <a href="#BNF grammar" target="_blank">BNF grammar</a> above for the normative syntax.
+Please see the <a href="#bnf-grammar" target="_blank">BNF grammar</a> above for the normative syntax.
 
 [foo] means optional, &lt;bar&gt; are placeholders
 

web/content/20/index.md

@@ -93,7 +93,7 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must
 
 * label: Label for that address (e.g. name of receiver)
 * address: bitcoin address
-* message: message that describes the transaction to the user (<a href=" Examples" target="_blank">see examples below</a>)
+* message: message that describes the transaction to the user (<a href=" examples" target="_blank">see examples below</a>)
 * (others): optional, for future extensions
 
 

web/content/21/index.md

@@ -51,7 +51,7 @@ Block template creation can be influenced by various parameters:
 
 |Key|Required|Type|Description|
 |-|-|-|-|
-|capabilities|No|Array of Strings|SHOULD contain a list of the following, to indicate client-side support: <a href="#Optional: Long Polling" target="_blank">"longpoll"</a>, "coinbasetxn", "coinbasevalue", <a href="/23" target="_blank">"proposal"</a>, <a href="/23" target="_blank">"serverlist"</a>, "workid", and any of the <a href="/23" target="_blank">mutations</a>|
+|capabilities|No|Array of Strings|SHOULD contain a list of the following, to indicate client-side support: <a href="#optional-long-polling" target="_blank">"longpoll"</a>, "coinbasetxn", "coinbasevalue", <a href="/23" target="_blank">"proposal"</a>, <a href="/23" target="_blank">"serverlist"</a>, "workid", and any of the <a href="/23" target="_blank">mutations</a>|
 |mode|No|String|MUST be "template" or omitted|
 
 
@@ -65,12 +65,12 @@ getblocktemplate MUST return a JSON Object containing the following keys:
 |previousblockhash|Yes|String|the hash of the previous block, in big-endian hexadecimal|
 |sigoplimit|No|Number|number of sigops allowed in blocks|
 |sizelimit|No|Number|number of bytes allowed in blocks|
-|transactions|Should|Array of Objects|Objects containing <a href="#Transactions Object Format" target="_blank">information for Bitcoin transactions</a> (excluding coinbase)|
+|transactions|Should|Array of Objects|Objects containing <a href="#transactions-object-format" target="_blank">information for Bitcoin transactions</a> (excluding coinbase)|
 |version|Yes|Number|always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with <a href="/34" target="_blank">BIP 0034</a> for version 2)|
 |coinbaseaux|No|Object|data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by <a href="/34" target="_blank">BIP 0034</a>. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertently expend SIGOPs (which are counted toward limits, despite not being executed).|
-|coinbasetxn|this or ↓|Object|<a href="#Transactions Object Format" target="_blank">information for coinbase transaction</a>|
+|coinbasetxn|this or ↓|Object|<a href="#transactions-object-format" target="_blank">information for coinbase transaction</a>|
 |coinbasevalue|this or ↑|Number|total funds available for the coinbase (in Satoshis)|
-|workid|No|String|if provided, this value must be returned with results (see <a href="#Block Submission" target="_blank">Block Submission</a>)|
+|workid|No|String|if provided, this value must be returned with results (see <a href="#block-submission" target="_blank">Block Submission</a>)|
 
 
 <h4> Transactions Object Format </h4>

web/content/22/index.md

@@ -49,15 +49,15 @@ Something can be said to have BIP 23 Level 1 support if it implements at least:
 *  <a href="http://json-rpc.org/wiki/specification" target="_blank">JSON-RPC 1.0</a>
 *  <a href="/22" target="_blank">BIP 22 (non-optional sections)</a>
 *  <a href="/22" target="_blank">BIP 22 Long Polling</a>
-*  <a href=" Basic Pool Extensions" target="_blank">BIP 23 Basic Pool Extensions</a>
-*  <a href=" Mutations" target="_blank">BIP 23 Mutation "coinbase/append"</a>
-*  <a href=" Submission Abbreviation" target="_blank">BIP 23 Submission Abbreviation "submit/coinbase"</a>
-*  <a href=" Mutations" target="_blank">BIP 23 Mutation "time/increment"</a> (only required for servers)
+*  <a href=" basic-pool-extensions" target="_blank">BIP 23 Basic Pool Extensions</a>
+*  <a href=" mutations" target="_blank">BIP 23 Mutation "coinbase/append"</a>
+*  <a href=" submission-abbreviation" target="_blank">BIP 23 Submission Abbreviation "submit/coinbase"</a>
+*  <a href=" mutations" target="_blank">BIP 23 Mutation "time/increment"</a> (only required for servers)
 
 
 It can be said to have BIP 23 Level 2 support if it also implements:
-*  <a href=" Mutations" target="_blank">BIP 23 Mutation "transactions/add"</a>
-*  <a href=" Block Proposals" target="_blank">BIP 23 Block Proposals</a>
+*  <a href=" mutations" target="_blank">BIP 23 Mutation "transactions/add"</a>
+*  <a href=" block-proposals" target="_blank">BIP 23 Block Proposals</a>
 
 
 <h3>Basic Pool Extensions</h3>

web/content/23/index.md

@@ -99,7 +99,7 @@ The bitcoinaddress body MUST be either a base58 P2SH or P2PKH address, bech32 Se
 The following keys are defined generally and apply to any URI regardless of payment instructions:
 
 * label: Label for the recipient (e.g. name of receiver)
-* message: message that describes the transaction to the user (<a href=" Examples" target="_blank">see examples below</a>)
+* message: message that describes the transaction to the user (<a href=" examples" target="_blank">see examples below</a>)
 * pop: a URI which the Bitcoin Wallet may return to in order to provide the application which initiated the payment with proof that a payment was completed.