From 835e7107b88c6db6c9680f2d51ea4fd025a02957 Mon Sep 17 00:00:00 2001 From: Ethan Heilman Date: Fri, 23 Jan 2026 19:55:12 -0500 Subject: [PATCH] Fix broken anchor links --- bip-0022.mediawiki | 4 ++-- bip-0023.mediawiki | 16 ++++++++-------- bip-0342.mediawiki | 8 ++++---- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index 62159a68..8abcf2c0 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -24,7 +24,7 @@ This BIP is licensed under the BSD 2-clause license. A JSON-RPC method is defined, called "getblocktemplate". It accepts exactly one argument, which MUST be an Object of request parameters. -If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#Block Proposal|"proposal"]]. +If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#user-content-Block_Proposal|"proposal"]]. Block template creation can be influenced by various parameters: {| class="wikitable" @@ -32,7 +32,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: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[bip-0023.mediawiki#Block Proposal|"proposal"]], [[bip-0023.mediawiki#Logical Services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#Mutations|mutations]] +| capabilities || No || Array of Strings || SHOULD contain a list of the following, to indicate client-side support: [[#Optional: Long Polling|"longpoll"]], "coinbasetxn", "coinbasevalue", [[bip-0023.mediawiki#user-content-Block_Proposal|"proposal"]], [[bip-0023.mediawiki#user-content-Logical_Services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#user-content-Mutations|mutations]] |- | mode || No || String || MUST be "template" or omitted |} diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index 14512c6a..7708a135 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -27,15 +27,15 @@ Something can be said to have BIP 23 Level 1 support if it implements at least: * [http://www.ietf.org/rfc/rfc1945.txt RFC 1945] * [http://json-rpc.org/wiki/specification JSON-RPC 1.0] * [[bip-0022.mediawiki|BIP 22 (non-optional sections)]] -* [[bip-0022.mediawiki#Optional: Long Polling|BIP 22 Long Polling]] -* [[#Basic Pool Extensions|BIP 23 Basic Pool Extensions]] -* [[#Mutations|BIP 23 Mutation "coinbase/append"]] -* [[#Submission Abbreviation|BIP 23 Submission Abbreviation "submit/coinbase"]] -* [[#Mutations|BIP 23 Mutation "time/increment"]] (only required for servers) +* [[bip-0022.mediawiki#user-content-Optional_Long_Polling|BIP 22 Long Polling]] +* [[#user-content-Basic_Pool_Extensions|BIP 23 Basic Pool Extensions]] +* [[#user-content-Mutations|BIP 23 Mutation "coinbase/append"]] +* [[#user-content-Submission_Abbreviation|BIP 23 Submission Abbreviation "submit/coinbase"]] +* [[#user-content-Mutations|BIP 23 Mutation "time/increment"]] (only required for servers) It can be said to have BIP 23 Level 2 support if it also implements: -* [[#Mutations|BIP 23 Mutation "transactions/add"]] -* [[#Block Proposals|BIP 23 Block Proposals]] +* [[#user-content-Mutations|BIP 23 Mutation "transactions/add"]] +* [[#user-content-Block_Proposals|BIP 23 Block Proposals]] ===Basic Pool Extensions=== @@ -87,7 +87,7 @@ This is accomplished by calling getblocktemplate with two keys: The block data MUST be validated and checked against the server's usual acceptance rules (excluding the check for a valid proof-of-work). If it is found to be in violation of any of these rules, the server MUST return one of the following: * Null if it is acceptable as-is, with the same workid (if any) as provided. Note that this SHOULD NOT invalidate the old template's claim to the same workid. -* A String giving the reason for the rejection (see [[bip-0022.mediawiki#appendix-example-rejection-reasons|example rejection reasons]]). +* A String giving the reason for the rejection (see [[bip-0022.mediawiki#user-content-appendix-example-rejection-reasons|example rejection reasons]]). * A "delta" block template (with changes needed); in this case, any missing keys are assumed to default to those in the proposed block or, if not applicable, the original block template it was based on. This template MAY also include a "reject-reason" key with a String of the reason for rejection. It is RECOMMENDED that servers which merely need to track the proposed block for later share/* submissions, return a simple Object of the form: diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index d073b701..164f5f78 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -47,8 +47,8 @@ Additionally, the new tapscript OP_SUCCESS opcodes allow introducin The rules below only apply when validating a transaction input for which all of the conditions below are true: * The transaction input is a '''segregated witness spend''' (i.e., the scriptPubKey contains a witness program as defined in [[bip-0141.mediawiki|BIP141]]). -* It is a '''taproot spend''' as defined in [[bip-0341.mediawiki#design|BIP341]] (i.e., the witness version is 1, the witness program is 32 bytes, and it is not P2SH wrapped). -* It is a '''script path spend''' as defined in [[bip-0341.mediawiki#design|BIP341]] (i.e., after removing the optional annex from the witness stack, two or more stack elements remain). +* It is a '''taproot spend''' as defined in [[bip-0341.mediawiki#user-content-design|BIP341]] (i.e., the witness version is 1, the witness program is 32 bytes, and it is not P2SH wrapped). +* It is a '''script path spend''' as defined in [[bip-0341.mediawiki#user-content-design|BIP341]] (i.e., after removing the optional annex from the witness stack, two or more stack elements remain). * The leaf version is ''0xc0'' (i.e. the first byte of the last witness element after removing the optional annex is ''0xc0'' or ''0xc1''), marking it as a '''tapscript spend'''. Validation of such inputs must be equivalent to performing the following steps in the specified order. @@ -104,8 +104,8 @@ The following rules apply to OP_CHECKSIG, OP_CHECKSIGVERIFYOP_CODESEPARATOR before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed. Opcodes in parsed but unexecuted branches count towards this value as well.