summaryrefslogtreecommitdiff
path: root/bip-0022.mediawiki
diff options
context:
space:
mode:
Diffstat (limited to 'bip-0022.mediawiki')
-rw-r--r--bip-0022.mediawiki16
1 files changed, 6 insertions, 10 deletions
diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki
index 9efc8f0..793b5f3 100644
--- a/bip-0022.mediawiki
+++ b/bip-0022.mediawiki
@@ -1,5 +1,3 @@
-{{bip}}
-
<pre>
BIP: 22
Title: getblocktemplate - Fundamentals
@@ -20,7 +18,7 @@ Instead of sending a simple block header for hashing, the entire block structure
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#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#Block Proposal|"proposal"]].
Block template creation can be influenced by various parameters:
{| class="wikitable"
@@ -28,7 +26,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#Block Proposal|"proposal"]], [[BIP 0023#Logical Services|"serverlist"]], "workid", and any of the [[BIP 0023#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#Block Proposal|"proposal"]], [[bip-0023.mediawiki#Logical Services|"serverlist"]], "workid", and any of the [[bip-0023.mediawiki#Mutations|mutations]]
|-
| mode || {{No}} || String || MUST be "template" or omitted
|}
@@ -53,9 +51,9 @@ getblocktemplate MUST return a JSON Object containing the following keys:
|-
| transactions || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (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 [[BIP 0034]] for version 2)
+| version || {{Yes}} || Number || always 1 or 2 (at least for bitcoin) - clients MUST understand the implications of the version they use (eg, comply with [[bip-0034.mediawiki|BIP 0034]] 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 [[BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertantly expend SIGOPs (which are counted toward limits, despite not being executed).
+| 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 [[bip-0034.mediawiki|BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertantly expend SIGOPs (which are counted toward limits, despite not being executed).
|-
| coinbasetxn || {{Patch|this or ↓}} || Object || [[#Transactions Object Format|information for coinbase transaction]]
|-
@@ -230,7 +228,7 @@ What is the purpose of "workid"?
* If servers allow all mutations, it may be hard to identify which job it is based on. While it may be possible to verify the submission by its content, it is much easier to compare it to the job issued. It is very easy for the miner to keep track of this. Therefore, using a "workid" is a very cheap solution to enable more mutations.
Why should "sigops" be provided for transactions?
-* Due to the [[BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).
+* Due to the [[bip-0016.mediawiki|BIP 0016]] changes regarding rules on block sigops, it is impossible to count sigops from the transactions themselves (the sigops in the scriptCheck must also be included in the count).
==Reference Implementation==
@@ -239,6 +237,4 @@ Why should "sigops" be provided for transactions?
* [https://github.com/bitcoin/bitcoin/pull/936/files bitcoind (minimal server)]
==See Also==
-* [[BIP 0023|BIP 23: getblocktemplate - Pooled Mining]]
-
-[[Category:BIP|D]]
+* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]