Skip to content

Fix broken anchor links in BIP 0342, BIP 0022, BIP 0023 #2091

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
EthanHeilman wants to merge 1 commit into
base: master
Choose a base branch
from
+14 −14
Open

Fix broken anchor links in BIP 0342, BIP 0022, BIP 0023 #2091

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions bip-0022.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,15 +24,15 @@ 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"
!colspan=4|template request
|-
! 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
|}
Expand Down
16 changes: 8 additions & 8 deletions bip-0023.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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===

Expand Down Expand Up @@ -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:
Expand Down
8 changes: 4 additions & 4 deletions bip-0342.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,8 +47,8 @@ Additionally, the new tapscript <code>OP_SUCCESS</code> 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.
Expand Down Expand Up @@ -104,8 +104,8 @@ The following rules apply to <code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</

===Common Signature Message Extension===

We define the tapscript message extension ''ext'' to [[bip-0341.mediawiki#common-signature-message|BIP341 Common Signature Message]], indicated by ''ext_flag = 1'':
* ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#design|BIP341]]
We define the tapscript message extension ''ext'' to [[bip-0341.mediawiki#user-content-common-signature-message|BIP341 Common Signature Message]], indicated by ''ext_flag = 1'':
* ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki#user-content-design|BIP341]]
* ''key_version'' (1): a constant value ''0x00'' representing the current version of public keys in the tapscript signature opcode execution.
* ''codesep_pos'' (4): the opcode position of the last executed <code>OP_CODESEPARATOR</code> 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.

Expand Down