diff options
| -rw-r--r-- | bip-0009.mediawiki | 33 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0145.mediawiki | 13 |
3 files changed, 45 insertions, 9 deletions
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 509a8a9..b506aad 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. @@ -51,6 +53,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. @@ -157,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. diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 09676f8..e10ff53 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -120,9 +120,11 @@ The new rule is ''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 == @@ -273,7 +275,7 @@ As a soft fork, older software will continue to operate without modification. N == Deployment == -This BIP will be deployed by "version bits" BIP9 using bit TBD. +This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit TBD. For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD). diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki index b90725e..f7a1e61 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,10 +23,6 @@ The template Object is revised to include these keys: ! Key !! Required !! Type !! Description |- | 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) |} ====Transactions Object Format==== @@ -45,7 +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 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=== @@ -87,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)]] |