diff options
| -rw-r--r-- | README.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 214 | ||||
| -rw-r--r-- | bip-0009/states.png | bin | 0 -> 24827 bytes | |||
| -rw-r--r-- | bip-0068.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0133.mediawiki | 48 |
5 files changed, 165 insertions, 105 deletions
diff --git a/README.mediawiki b/README.mediawiki index 3c6b227..02a5a76 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -452,6 +452,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Process | Draft |- +| [[bip-0133.mediawiki|133]] +| feefilter message +| Alex Morcos +| Standard +| Draft +|- | [[bip-0140.mediawiki|140]] | Normalized TXID | Christian Decker diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 78298f0..856db7a 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -18,130 +18,136 @@ This document specifies a proposed change to the semantics of the 'version' fiel BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled. -In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66, which further removed nVersion = 2 as valid option. As will be shown further, this is unnecessary. +In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary. ==Specification== -===Mechanism=== +Each soft fork deployment is specified by the following per-chain parameters (further elaborated below): -'''Bit flags''' -We are permitting several independent soft forks to be deployed in parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is not currently in use for any other ongoing soft fork. Miners signal intent to enforce the new rules associated with the proposed soft fork by setting bit 1<sup>B</sup> in nVersion to 1 in their blocks. +# 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 '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. The recommended value is 1916 (95%) for mainnet and 1512 (75%) for testnets. +# 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. -'''High bits''' -The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP34 and BIP66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible. +No two deployments may use the same bit if they have overlapping starttime-timeout periods. -'''States''' -With every softfork proposal we associate a state BState, which begins -at ''defined'', and can be ''locked-in'', ''activated'', -or ''failed''. Transitions are considered after each -retarget period. +The starttime should be set to some date in the future, coordinates with software release date. This is to prevent +triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the +starttime. Setting it to 3 years after the starttime would allow around 9 deployments to be initiated every year. -'''Soft Fork Support''' -Software which supports the change should begin by setting B in all blocks -mined until it is resolved. +====States==== - if (BState != activated && BState != failed) { - SetBInBlock(); - } +With each block and soft fork, we associate a deployment state. The possible states are: + +# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment. +# '''STARTED''' for blocks past the starttime. +# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion. +# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. +# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached. +# '''ABANDONED''' for all blocks after the FAILED retarget period. + +====Bit flags==== + +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. This leaves two future +upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and others. +Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) +requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all +bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in +LOCKED_IN phase, so uptake is visible + +====New consensus rules==== + +The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. -'''Success: Lock-in Threshold''' -If bit B is set in 1916 (1512 on testnet) or -more of the 2016 blocks within a retarget period, it is considered -''locked-in''. Miners should continue setting bit B, so uptake is -visible. +====State transitions==== - if (NextBlockHeight % 2016 == 0) { - if (BState == defined && Previous2016BlocksCountB() >= 1916) { - BState = locked-in; - BActiveHeight = NextBlockHeight + 2016; +<img src="bip-0009/states.png" align="middle"></img> + +The genesis block has state DEFINED for each deployment, by definition. + + State GetStateForBlock(block) { + if (block.height == 0) { + return DEFINED; } - } -'''Success: Activation Delay''' -The consensus rules related to ''locked-in'' soft fork will be enforced in -the second retarget period; ie. there is a one retarget period in -which the remaining 5% can upgrade. At the that activation block and -after, miners should stop setting bit B, which may be reused for a different soft fork. - - if (BState == locked-in && NextBlockHeight == BActiveHeight) { - BState = activated; - ApplyRulesForBFromNextBlock(); - /* B can be reused, immediately */ - } - -'''Failure: Timeout''' -A soft fork proposal should include a ''timeout''. This is measured -as the beginning of a calendar year as per this table (suggest -adding three to the current calendar year when drafting the soft fork proposal): - -{| -! Timeout Year -! >= Seconds -! Timeout Year -! >= Seconds -|- -|2018 -|1514764800 -|2026 -|1767225600 -|- -|2019 -|1546300800 -|2027 -|1798761600 -|- -|2020 -|1577836800 -|2028 -|1830297600 -|- -|2021 -|1609459200 -|2029 -|1861920000 -|- -|2022 -|1640995200 -|2030 -|1893456000 -|- -|2023 -|1672531200 -|2031 -|1924992000 -|- -|2024 -|1704067200 -|2032 -|1956528000 -|- -|2025 -|1735689600 -|2033 -|1988150400 -|} - -If the soft fork still not ''locked-in'' and the -GetMedianTimePast() of a block following a retarget period is at or -past this timeout, miners should cease setting this bit. - - if (NextBlockHeight % 2016 == 0) { - if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) { - BState = failed; +All blocks within a retarget period have the same state. This means that if +floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every +deployment. + + if ((block.height % 2016) != 0) { + return GetStateForBlock(GetParent(block)); } - } -After another retarget period (to allow detection of buggy miners), -the bit may be reused. +Otherwise, the next state depends on the previous state: + + switch (GetStateForBlock(GetAncestorAtHeight(block, block.height - 2016))) { + +We remain in the initial state until either we pass the start time or the timeout. GetMedianTimePast in the code below +refers to the median nTime of the 11 blocks preceeding a given block. + + case DEFINED: + if (GetMedianTimePast(block) >= timeout) { + return FAILED; + } + if (GetMedianTimePast(block) >= starttime) { + return STARTED; + } + return DEFINED; + +When in STARTED state, we tally the bits set, and can transition to LOCKED_IN if we pass the threshold. Alternatively, +the timeout can trigger. Note that a block's state never depends on its own nVersion; only on that of its ancestors. + + case STARTED: { + int count = 0; + walk = block; + for (i = 0; i < 2016; i++) { + walk = walk.parent; + if (walk.nVersion & 0xE0000000 == 0x2000000 && (walk.nVersion >> bit) & 1 == 1) { + count++; + } + } + if (count >= threshold) { + return LOCKED_IN; + } + if (GetMedianTimePast(block) >= timeout) { + return FAILED; + } + } + +After a retarget period of LOCKED_IN or FAILED, we automatically transition to ACTIVE and ABANDONED, respectively. + + case LOCKED_IN: + return ACTIVE; -'''Warning system''' -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 lock-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. + case FAILED: + return ABANDONED; + +And ACTIVE and ABANDONED are terminal states, which a deployment stays in once they're reached. + + case ACTIVE: + return ACTIVE; + + case ABANDONED: + return ABANDONED; + } + } '''Forks''' It should be noted that the states are maintained along block chain branches, but may need recomputation when a reorganization happens. -===Support for future changes=== +'''Implementation''' +Given that the state for a specific block/deployment combination is completely determined by its ancestry before the +current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)), +it is possible to implement the mechanism above efficiently by caching the resulting state of every multiple-of-2016 +block, indexed by its parent. + +====Warning mechanism==== + +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). + +==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-0009/states.png b/bip-0009/states.png Binary files differnew file mode 100644 index 0000000..7b3139e --- /dev/null +++ b/bip-0009/states.png diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index fd17ea5..8c566b0 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -220,7 +220,7 @@ This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona. This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB. -BIP68 MUST be deployed together with BIP113. It is also recommended to deploy BIP112 at the same time. +It is recommended to deploy BIP112 and BIP113 at the same time. ==Compatibility== diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki new file mode 100644 index 0000000..b5146e3 --- /dev/null +++ b/bip-0133.mediawiki @@ -0,0 +1,48 @@ +<pre> + BIP: 133 + Title: feefilter message + Author: Alex Morcos <morcos@chaincode.com> + Status: Draft + Type: Standards Track + Created: 2016-02-13 +</pre> + +==Abstract== + +Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. + +==Motivation== + +The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. + +However, there are limitations to the effectiveness of these approaches. The reject filter is reset after every block which means transactions that are inv'ed over a longer time period will be rerequested and there is no method to prevent requesting the transaction the first time. Furthermore, inv data is sent at least once either to or from each peer for every transaction accepted to the mempool and there is no mechanism by which to know that an inv sent to a given peer would not result in a getdata request because it represents a transaction with too little fee. + +After receiving a feefilter message, a node can know before sending an inv that a given transaction's fee rate is below the minimum currently required by a given peer, and therefore the node can skip relaying an inv for that transaction to that peer. + +==Specification== + +# The feefilter message is defined as a message containing an int64_t where pchCommand == "feefilter" +# Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte. +# The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters. +# Inv's generated from a mempool message are also subject to a fee filter if it exists. +# Feature discovery is enabled by checking protocol version >= 70013 + +==Considerations== +The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to your mempool are not relayed and the funcionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited. + +Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool. + +There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementaion quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times. + +If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-nofeefilter" to make sure it is exposed to all possible txid's. + +==Backward compatibility== + +Older clients remain fully compatible and interoperable after this change. The sending of feefilter messages can be disabled by unsetting the "-feefilter" option. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7542 + +==Copyright== +This document is placed in the public domain. |
