From a5447e0c4b219acbbc1e09ccd9419e8dff94f1e8 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 21:43:36 +0000 Subject: BIP 141 & 145: Clarify sigop interaction --- bip-0141.mediawiki | 6 ++++-- bip-0145.mediawiki | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 12b0eba..543e5a2 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -114,9 +114,11 @@ The new rule is total ''block cost'' ≤ 4,000,000. Sigops per block is currently limited to 20,000. We change this restriction as follows: -''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1. +Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. +The sigop limit is likewise quadrupled to ≤ 80,000. -The new rule is total ''sigop cost'' ≤ 80,000. +In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script. +That is, CHECKSIG is counted as only 1 sigop in a witness program, despite P2SH check script's CHECKSIG becoming 4 sigops with the forementioned change. == Examples == diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index b90725e..712e422 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -24,8 +24,6 @@ The template Object is revised to include these keys: |- | costlimit || {{No}} || Number || total cost allowed in blocks |- -| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4 -|- | version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5) |} @@ -47,6 +45,10 @@ The Objects listed in the response's "transactions" key is revised to include th Transactions with witness data may only be included if the template's block version is at least 5. +===Sigops=== + +For version 5 blocks, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. + ===Block Assembly with Witness Transactions=== When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously. -- cgit v1.2.3 From b8467dfb7c1cf1ab29059f19eda91d0b8226d2fc Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 21:58:51 +0000 Subject: BIP 9: Clarify nVersion interpretation and bit order --- bip-0009.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 509a8a9..03e8727 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -51,6 +51,8 @@ With each block and soft fork, we associate a deployment state. The possible sta ===Bit flags=== +The nVersion block header field is to be interpreted as a 32-bit little-endian integer (as present), and bits are selected within this integer as values (1 << N) where N is the bit number. + Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. -- cgit v1.2.3 From b0b65ceedece12e8ea109abe1fb518c49e0e09ff Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 22:22:09 +0000 Subject: BIP 9: Add softfork deployment "name" --- bip-0009.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 03e8727..b72010d 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -24,6 +24,7 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule 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. # 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 '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning. # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. @@ -32,6 +33,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. # '''bit''' should be selected such that no two concurrent softforks use the same bit. # '''starttime''' should be set to some date in the future, approximately one month 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. # '''timeout''' should be 1 year (31536000 seconds) after starttime. -- cgit v1.2.3 From 12a2131bb425a3afb7e5d51576d43d0bc8a6d106 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 22:38:57 +0000 Subject: BIP 9: GBT specification --- bip-0009.mediawiki | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b72010d..b506aad 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -161,6 +161,35 @@ block, indexed by its parent. To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state). +===getblocktemplate changes=== + +The template request Object is extended to include a new item: + +{| class="wikitable" +!colspan=4| template request +|- +! Key !! Required !! Type !! Description +|- +| rules || {{No}} || Array of Strings || list of supported softfork deployments, by name +|} + +The template Object is also extended: + +{| class="wikitable" +!colspan=4| template +|- +! Key !! Required !! Type !! Description +|- +| rules || {{Yes}} || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value +|- +| rulesrequired || {{No}} || Array of Strings || list of softfork deployments the server requires support for +|- +| rulesenforced || {{Yes}} || Array of Strings || list of softfork deployments that are active state +|} + +The "version" key of the template is retained, and used to indicate the server's preference of deployments. +Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "rules" and (when clearing is desired) NOT listed in "rulesrequired". + ==Support for future changes== The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. -- cgit v1.2.3 From 161b39fa687d4716cd54953e840511ebba45899d Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 22:42:42 +0000 Subject: BIP 145: Update for BIP 9 --- bip-0145.mediawiki | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index 712e422..6c2a859 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -15,7 +15,7 @@ This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-00 ===Block Template=== -The template Object is revised to include these keys: +The template Object is revised to include a new key: {| class="wikitable" !colspan=4| template @@ -23,8 +23,6 @@ The template Object is revised to include these keys: ! Key !! Required !! Type !! Description |- | costlimit || {{No}} || Number || total cost allowed in blocks -|- -| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5) |} ====Transactions Object Format==== @@ -43,11 +41,11 @@ The Objects listed in the response's "transactions" key is revised to include th | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal |} -Transactions with witness data may only be included if the template's block version is at least 5. +Transactions with witness data may only be included if the template's "rulesenforced" list (see [[bip-0009.mediawiki#getblocktemplate changes|BIP 9]]) includes "segwit". ===Sigops=== -For version 5 blocks, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. +For blocks with segwit enforcement, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. ===Block Assembly with Witness Transactions=== @@ -89,6 +87,7 @@ Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", * [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core] ==See Also== +* [[bip-0009.mediawiki|BIP 9: Version bits with timeout and delay]] * [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]] * [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]] * [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]] -- cgit v1.2.3 From 2fa7fb9b5cf9a4dbe2affe44267014fc486cbcf6 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 30 Mar 2016 22:43:33 +0000 Subject: BIP 141: Specify VB name --- bip-0141.mediawiki | 2 +- bip-0145.mediawiki | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 543e5a2..647ec69 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -251,7 +251,7 @@ As a soft fork, older software will continue to operate without modification. N == Deployment == -This BIP is to be deployed by version-bits BIP9. Exact details TDB. +This BIP is to be deployed by version-bits BIP9 with the name "segwit". Exact details TDB. == Credits == diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index 6c2a859..f7a1e61 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -41,7 +41,7 @@ The Objects listed in the response's "transactions" key is revised to include th | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal |} -Transactions with witness data may only be included if the template's "rulesenforced" list (see [[bip-0009.mediawiki#getblocktemplate changes|BIP 9]]) includes "segwit". +Transactions with witness data may only be included if the template's "rulesenforced" list (see [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]) includes "segwit". ===Sigops=== -- cgit v1.2.3 From cacf39b057e15fc273b3ddea7dde78e4fb696b83 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Thu, 31 Mar 2016 14:22:36 +0800 Subject: BIP141: Sigop clarification --- bip-0141.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 647ec69..09a5556 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -80,8 +80,8 @@ If there are more than one scriptPubKey matching the pattern, the one with highe A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: -# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. -# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. +# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'') +# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. (''"P2SH witness program"'') If the version byte is 0, and the witness program is 20 bytes: * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. @@ -118,7 +118,7 @@ Sigops in the current pubkey script, signature script, and P2SH check script are The sigop limit is likewise quadrupled to ≤ 80,000. In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script. -That is, CHECKSIG is counted as only 1 sigop in a witness program, despite P2SH check script's CHECKSIG becoming 4 sigops with the forementioned change. +That is, CHECKSIG in a witness program is counted as only 1 sigop, and m-of-n CHECKMULTISIG in a witness program is counted as n sigop. This rule applies to both native witness program and P2SH witness program. == Examples == -- cgit v1.2.3 From a6cc319846c4baaecbdd489dfc3143239189b4d5 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Tue, 5 Apr 2016 13:03:34 +0800 Subject: Update bip-0141.mediawiki --- bip-0141.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 09a5556..3cbcd13 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -118,7 +118,7 @@ Sigops in the current pubkey script, signature script, and P2SH check script are The sigop limit is likewise quadrupled to ≤ 80,000. In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script. -That is, CHECKSIG in a witness program is counted as only 1 sigop, and m-of-n CHECKMULTISIG in a witness program is counted as n sigop. This rule applies to both native witness program and P2SH witness program. +That is, CHECKSIG in a witness program is counted as only 1 sigop, and CHECKMULTISIG in a witness program is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program. == Examples == -- cgit v1.2.3 From 7e99bbf958911888999e100d3d6f8738acb61928 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 23 Apr 2016 20:12:41 +0000 Subject: bip-0009: Recommend name "bipN" --- bip-0009.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index b506aad..1da083d 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -24,7 +24,7 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule 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. +# 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 '''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 '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning. # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block. -- cgit v1.2.3 From 4683a9b71424bac4d43af2236f36fdc2b0c9f470 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 23 Apr 2016 20:20:13 +0000 Subject: BIP 9 (& 145): Switch to rules/vbavailable/vbrequired GBT interface --- bip-0009.mediawiki | 8 ++++---- bip-0145.mediawiki | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 1da083d..459486f 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -180,15 +180,15 @@ The template Object is also extended: |- ! Key !! Required !! Type !! Description |- -| rules || {{Yes}} || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value +| rules || {{Yes}} || Array of Strings || list of softfork deployments, by name, that are active state |- -| rulesrequired || {{No}} || Array of Strings || list of softfork deployments the server requires support for +| vbavailable || {{Yes}} || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value |- -| rulesenforced || {{Yes}} || Array of Strings || list of softfork deployments that are active state +| vbrequired || {{No}} || Number || bit mask of softfork deployment version bits the server requires enabled in submissions |} The "version" key of the template is retained, and used to indicate the server's preference of deployments. -Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "rules" and (when clearing is desired) NOT listed in "rulesrequired". +Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". ==Support for future changes== diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index f7a1e61..bdaabc9 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -41,11 +41,11 @@ The Objects listed in the response's "transactions" key is revised to include th | hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal |} -Transactions with witness data may only be included if the template's "rulesenforced" list (see [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]) includes "segwit". +Transactions with witness data may only be included if the template's "rules" list (see [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]) includes "segwit". ===Sigops=== -For blocks with segwit enforcement, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. +For templates with "segwit" enabled as a rule, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]]. ===Block Assembly with Witness Transactions=== -- cgit v1.2.3 From 31c45b611d805a349bc27552e85ba876a5af34ba Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 23 Apr 2016 20:32:59 +0000 Subject: BIP 9, 22 & 145: Use simple Yes/No rather than templates (which don't work on GitHub) --- bip-0009.mediawiki | 8 ++++---- bip-0022.mediawiki | 28 ++++++++++++++-------------- bip-0145.mediawiki | 2 +- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 459486f..56d3d5c 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -170,7 +170,7 @@ The template request Object is extended to include a new item: |- ! Key !! Required !! Type !! Description |- -| rules || {{No}} || Array of Strings || list of supported softfork deployments, by name +| rules || No || Array of Strings || list of supported softfork deployments, by name |} The template Object is also extended: @@ -180,11 +180,11 @@ The template Object is also extended: |- ! Key !! Required !! Type !! Description |- -| rules || {{Yes}} || Array of Strings || list of softfork deployments, by name, that are active state +| rules || Yes || Array of Strings || list of softfork deployments, by name, that are active state |- -| vbavailable || {{Yes}} || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value +| vbavailable || Yes || Object || set of pending, supported softfork deployments; each uses the softfork name as the key, and the softfork bit as its value |- -| vbrequired || {{No}} || Number || bit mask of softfork deployment version bits the server requires enabled in submissions +| vbrequired || No || Number || bit mask of softfork deployment version bits the server requires enabled in submissions |} The "version" key of the template is retained, and used to indicate the server's preference of deployments. diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index 35b59be..4b33e59 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -26,9 +26,9 @@ 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#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 +| mode || No || String || MUST be "template" or omitted |} getblocktemplate MUST return a JSON Object containing the following keys: @@ -37,29 +37,29 @@ getblocktemplate MUST return a JSON Object containing the following keys: |- ! Key !! Required !! Type !! Description |- -| bits || {{Yes}} || String || the compressed difficulty in hexadecimal +| bits || Yes || String || the compressed difficulty in hexadecimal |- -| curtime || {{Yes}} || Number || the current time as seen by the server (recommended for block time) - note this is not necessarily the system clock, and must fall within the mintime/maxtime rules +| curtime || Yes || Number || the current time as seen by the server (recommended for block time) - note this is not necessarily the system clock, and must fall within the mintime/maxtime rules |- -| height || {{Yes}} || Number || the height of the block we are looking for +| height || Yes || Number || the height of the block we are looking for |- -| previousblockhash || {{Yes}} || String || the hash of the previous block, in big-endian hexadecimal +| previousblockhash || Yes || String || the hash of the previous block, in big-endian hexadecimal |- -| sigoplimit || {{No}} || Number || number of sigops allowed in blocks +| sigoplimit || No || Number || number of sigops allowed in blocks |- -| sizelimit || {{No}} || Number || number of bytes allowed in blocks +| sizelimit || No || Number || number of bytes allowed in blocks |- -| transactions || {{Yes|Should}} || Array of Objects || Objects containing [[#Transactions Object Format|information for Bitcoin transactions]] (excluding coinbase) +| transactions || 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.mediawiki|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.mediawiki|BIP 0034]]. 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). +| 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 inadvertently expend SIGOPs (which are counted toward limits, despite not being executed). |- -| coinbasetxn || {{Patch|this or ↓}} || Object || [[#Transactions Object Format|information for coinbase transaction]] +| coinbasetxn || this or ↓ || Object || [[#Transactions Object Format|information for coinbase transaction]] |- -| coinbasevalue || {{Patch|this or ↑}} || Number || total funds available for the coinbase (in Satoshis) +| 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 [[#Block Submission|Block Submission]]) +| workid || No || String || if provided, this value must be returned with results (see [[#Block Submission|Block Submission]]) |} ==== Transactions Object Format ==== diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index bdaabc9..6d3718b 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -22,7 +22,7 @@ The template Object is revised to include a new key: |- ! Key !! Required !! Type !! Description |- -| costlimit || {{No}} || Number || total cost allowed in blocks +| costlimit || No || Number || total cost allowed in blocks |} ====Transactions Object Format==== -- cgit v1.2.3 From 3cfa48d1e073090deee8864070274c54c000250a Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Sat, 23 Apr 2016 21:13:02 +0000 Subject: BIP 9: Clarify GBT "version" --- bip-0009.mediawiki | 1 + 1 file changed, 1 insertion(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 56d3d5c..66e6806 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -188,6 +188,7 @@ The template Object is also extended: |} The "version" key of the template is retained, and used to indicate the server's preference of deployments. +If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". ==Support for future changes== -- cgit v1.2.3 From cc4a94c1c04284fc8eca3f83b8d139711fa2a345 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Mon, 25 Apr 2016 00:18:39 +0000 Subject: BIP 9 & 145: rules/force mutation --- bip-0009.mediawiki | 13 +++++++++++++ bip-0145.mediawiki | 3 +++ 2 files changed, 16 insertions(+) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 66e6806..95dd740 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -191,6 +191,19 @@ The "version" key of the template is retained, and used to indicate the server's If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". +The mutable key defined by BIP 23 is expanded to optionally include one new mutation: + +{| class="wikitable" +!colspan=4| mutations +|- +! Value !! Significance +|- +| rules/force || the miner may ignore rules it does not understand, if the template is to be used as-is (not modified by the client) +|} + +Servers should only signal this mutation when they have verified a client behaving this way will not produce invalid blocks. +This includes verifying the client's supported rules (listed in the template request) are not lacking of a rule that would change serialisation. + ==Support for future changes== The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index 6d3718b..0448b6c 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -25,6 +25,9 @@ The template Object is revised to include a new key: | costlimit || No || Number || total cost allowed in blocks |} +The "rules/force" mutation MUST NOT be enabled for blocks including transactions with witness data unless the client has indicated in the template request that it also supports the "segwit" rule. +In particular, note that even if the template's "rules" list includes "segwit", but none of the transactions have witness data, the server MAY use the "rules/force" mutation to support old miners. + ====Transactions Object Format==== The Objects listed in the response's "transactions" key is revised to include these keys: -- cgit v1.2.3 From 162e2e002568dc8f1b4a85180d903366f74f40c4 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 11 May 2016 17:45:08 +0000 Subject: Replace "rules/force" mutation with a "cannot be ignored" prefix to rule names --- bip-0009.mediawiki | 14 +++++--------- bip-0145.mediawiki | 5 +++-- 2 files changed, 8 insertions(+), 11 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 95dd740..0e1d7bd 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -191,15 +191,11 @@ The "version" key of the template is retained, and used to indicate the server's If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". -The mutable key defined by BIP 23 is expanded to optionally include one new mutation: - -{| class="wikitable" -!colspan=4| mutations -|- -! Value !! Significance -|- -| rules/force || the miner may ignore rules it does not understand, if the template is to be used as-is (not modified by the client) -|} +Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. +Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. +If a client does not understand a rule without the prefix, it may use it unmodified for mining. +On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). +A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. Servers should only signal this mutation when they have verified a client behaving this way will not produce invalid blocks. This includes verifying the client's supported rules (listed in the template request) are not lacking of a rule that would change serialisation. diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index 0448b6c..b04c9e6 100644 --- a/bip-0145.mediawiki +++ b/bip-0145.mediawiki @@ -25,8 +25,9 @@ The template Object is revised to include a new key: | costlimit || No || Number || total cost allowed in blocks |} -The "rules/force" mutation MUST NOT be enabled for blocks including transactions with witness data unless the client has indicated in the template request that it also supports the "segwit" rule. -In particular, note that even if the template's "rules" list includes "segwit", but none of the transactions have witness data, the server MAY use the "rules/force" mutation to support old miners. +The '!' rule prefix MUST be enabled on the "segwit" rule for templates including transactions with witness data. +In particular, note that even if the client's "rules" list lacks "segwit", server MAY support old miners by producing a witness-free template and omitting the '!' rule prefix for "segwit" in the template's "rules" list. +If the GBT server does not support producing witness-free templates after its activation, it must also use the '!' rule prefix in the "vbavailable" list prior to activation. ====Transactions Object Format==== -- cgit v1.2.3 From 5e6f3ba3bef783807191f8dccdf5bec1bcbfdabc Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Wed, 11 May 2016 21:54:09 +0000 Subject: bip-0009: Remove n/a paragraph --- bip-0009.mediawiki | 3 --- 1 file changed, 3 deletions(-) diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 0e1d7bd..162b264 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -197,9 +197,6 @@ If a client does not understand a rule without the prefix, it may use it unmodif On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction). A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified. -Servers should only signal this mutation when they have verified a client behaving this way will not produce invalid blocks. -This includes verifying the client's supported rules (listed in the template request) are not lacking of a rule that would change serialisation. - ==Support for future changes== The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account. -- cgit v1.2.3