diff options
| -rw-r--r-- | README.mediawiki | 14 | ||||
| -rw-r--r-- | bip-0001.mediawiki | 11 | ||||
| -rw-r--r-- | bip-0009.mediawiki | 224 | ||||
| -rw-r--r-- | bip-0009/states.png | bin | 0 -> 30632 bytes | |||
| -rw-r--r-- | bip-0038.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0044.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0047.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0050.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0068.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0069.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0073.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0112.mediawiki | 204 | ||||
| -rw-r--r-- | bip-0113.mediawiki | 43 | ||||
| -rw-r--r-- | bip-0133.mediawiki | 48 |
14 files changed, 303 insertions, 258 deletions
diff --git a/README.mediawiki b/README.mediawiki index ce40a64..02a5a76 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -216,12 +216,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Justus Ranvier | Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational -| Draft +| Final <!-- 50 series reserved for a group of post-mortems --> |- | [[bip-0060.mediawiki|60]] @@ -301,12 +301,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Gavin Andresen | Standard | Final -|- +|- style="background-color: #cfffcf" | [[bip-0073.mediawiki|73]] | Use "Accept" header for response type negotiation with Payment Request URLs | Stephen Pair | Standard -| Draft +| Final |- | [[bip-0074.mediawiki|74]] | Allow zero value OP_RETURN in Payment Protocol @@ -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-0001.mediawiki b/bip-0001.mediawiki index 4f91a39..44fbe8b 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -85,9 +85,9 @@ Each BIP should have the following parts: ==BIP Formats and Templates== -BIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that BIP. +BIPs should be written in mediawiki or markdown format. -==BIP Header Preamble== +===BIP Header Preamble=== Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. @@ -129,9 +129,10 @@ The Created header records the date that the BIP was assigned a number, while Po BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete. -Auxiliary Files -BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). +===Auxiliary Files=== + +BIPs may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that BIP. Auxiliary files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). ==Transferring BIP Ownership== @@ -175,6 +176,6 @@ This document was derived heavily from Python's PEP-0001. In many places text wa ==Changelog== -10 Oct 2015 - Added clarifications about sumission process and BIP number assignment. +10 Oct 2015 - Added clarifications about submission process and BIP number assignment. 01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc. diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index 78298f0..49e6adf 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -18,135 +18,147 @@ 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 '''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. +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. A later deployment using the same bit is possible as long as the starttime is after the previous one's +timeout or activation, though it is recommended to have a pause in between to detect buggy software. -'''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. +Setting the timeout to 3 years after the starttime allows at least 9 new deployments per 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. + +====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. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available. +This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those +for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). +When a block nVersion does not have top bits 001, it is treated as if all +bits are 0 for the purposes of deployments. + +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on +consensus rules. -'''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. +====New consensus rules==== - if (NextBlockHeight % 2016 == 0) { - if (BState == defined && Previous2016BlocksCountB() >= 1916) { - BState = locked-in; - BActiveHeight = NextBlockHeight + 2016; +The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. + +====State transitions==== + +<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(block.parent); + } + +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 a block and its 10 predecessors. The expression GetMedianTimePast(block.parent) is +referred to as MTP in the diagram above, and is treated as a monotonic clock defined by the chain. + + case DEFINED: + if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + if (GetMedianTimePast(block.parent) >= starttime) { + return STARTED; + } + return DEFINED; + +After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set, +and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their +version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 for testnet (75% of 2016). +The transition to FAILED takes precendence, as otherwise an ambiguity can arise. +There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the +other one simultaneously transitions to STARTED, which would mean both would demand setting the bit. + +Note that a block's state never depends on its own nVersion; only on that of its ancestors. + + case STARTED: { + if (GetMedianTimePast(block.parent) >= timeout) { + return FAILED; + } + 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; + } } - } -After another retarget period (to allow detection of buggy miners), -the bit may be reused. +After a retarget period of LOCKED_IN, we automatically transition to 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 LOCKED_IN: + return ACTIVE; -'''Forks''' +And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached. + + case ACTIVE: + return ACTIVE; + + case FAILED: + return FAILED; + } + } + +'''Implementation''' 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=== +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 and safely 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. '''Modified thresholds''' -The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. +The 1915 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore. '''Conflicting soft forks''' At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes. diff --git a/bip-0009/states.png b/bip-0009/states.png Binary files differnew file mode 100644 index 0000000..09312a1 --- /dev/null +++ b/bip-0009/states.png diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 6107e0a..650b7d0 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -210,6 +210,9 @@ Added to alpha version of Casascius Bitcoin Address Utility for Windows availabl Click "Tools" then "PPEC Keygen" (provisional name) +==Other implementations== +* Javascript - https://github.com/bitcoinjs/bip38 + ==Test vectors== ===No compression, no EC multiply=== diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index 6012ff5..64358d8 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -267,7 +267,7 @@ is required and a pull request to the above file should be created. * [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]]) * [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]]) * [[https://maza.club/encompass|Encompass]] ([[https://github.com/mazaclub/encompass|source]]) - +* [[https://www.crypzo.com/|Crypzo]] ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 1a05730..bdac681 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -291,6 +291,10 @@ The sender transmits their payment code in base58 form to the calculated Bitmess In order to use Bitmessage notification, the recipient must have a Bitmessage client which listens at the address which the senders will derive and is capable of relaying received payment codes to the Bitcoin wallet. +==Test Vectors== + +* [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]] + ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index a595321..4f48fca 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -2,7 +2,7 @@ BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen <gavinandresen@gmail.com> - Status: Draft + Status: Final Type: Informational Created: 2013-03-20 </pre> 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-0069.mediawiki b/bip-0069.mediawiki index 0eca369..4094126 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -162,6 +162,8 @@ Outputs: * [[https://github.com/bitcoinjs/bip69/blob/master/index.js|BitcoinJS]] * [[https://github.com/bitcoinjs/bip69/blob/master/test/fixtures.json|BitcoinJS Test Fixtures]] * [[https://www.npmjs.com/package/bip69|NodeJS]] +* [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/transaction.js#L120-L142|Blockchain.info public beta]] +* [[https://github.com/btcsuite/btcutil/blob/master/txsort/txsort.go|Btcsuite]] ==Acknowledgements== diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index a020fb5..41c89a3 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -2,7 +2,7 @@ BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> - Status: Draft + Status: Final Type: Standards Track Created: 2013-08-27 </pre> diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index cb9f206..336f9fc 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -229,117 +229,109 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. - - /* If this flag set, CTxIn::nSequence is NOT interpreted as a - * relative lock-time. */ - static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31); - - /* If CTxIn::nSequence encodes a relative lock-time and this flag - * is set, the relative lock-time has units of 512 seconds, - * otherwise it specifies blocks with a granularity of 1. */ - static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22); - - /* If CTxIn::nSequence encodes a relative lock-time, this mask is - * applied to extract that lock-time from the sequence field. */ - static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; +<pre> +/* Below flags apply in the context of BIP 68 */ +/* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. */ +static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31); + +/* If CTxIn::nSequence encodes a relative lock-time and this flag + * is set, the relative lock-time has units of 512 seconds, + * otherwise it specifies blocks with a granularity of 1. */ +static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22); + +/* If CTxIn::nSequence encodes a relative lock-time, this mask is + * applied to extract that lock-time from the sequence field. */ +static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; - case OP_NOP3: - { - if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { - // not enabled; treat as a NOP3 - if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { - return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); - } - break; +case OP_NOP3: +{ + if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { + // not enabled; treat as a NOP3 + if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { + return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); } - - if (stack.size() < 1) - return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); - - // Note that elsewhere numeric opcodes are limited to - // operands in the range -2**31+1 to 2**31-1, however it is - // legal for opcodes to produce results exceeding that - // range. This limitation is implemented by CScriptNum's - // default 4-byte limit. - // - // Thus as a special case we tell CScriptNum to accept up - // to 5-byte bignums, which are good until 2**39-1, well - // beyond the 2**32-1 limit of the nSequence field itself. - const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); - - // In the rare event that the argument may be < 0 due to - // some arithmetic being done first, you can always use - // 0 MAX CHECKSEQUENCEVERIFY. - if (nSequence < 0) - return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); - - // To provide for future soft-fork extensibility, if the - // operand has the disabled lock-time flag set, - // CHECKSEQUENCEVERIFY behaves as a NOP. - if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) - break; - - // Compare the specified sequence number with the input. - if (!checker.CheckSequence(nSequence)) - return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); - break; } - - bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const - { - // Relative lock times are supported by comparing the passed - // in operand to the sequence number of the input. - const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; - - // Fail if the transaction's version number is not set high - // enough to trigger BIP 68 rules. - if (static_cast<uint32_t>(txTo->nVersion) < 2) - return false; - - // Sequence numbers with their most significant bit set are not - // defined by BIP68. Testing that the transaction's sequence - // number do not have this bit set prevents using this property - // to get around a CHECKSEQUENCEVERIFY check. - if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) - return false; - - // Mask off any bits that do not have BIP68 consensus-enforced meaning - // before doing the integer comparisons of ::VerifySequence. - const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG - | CTxIn::SEQUENCE_LOCKTIME_MASK; - - if (!::VerifySequence(txToSequence & nLockTimeMask, - CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG, - nSequence & nLockTimeMask)) - return false; - - return true; - } - - static bool VerifySequence(int64_t txToSequence, int64_t nThreshold, const CScriptNum& nSequence) - { - // There are two kinds of nLockTime: lock-by-blockheight - // and lock-by-blocktime, distinguished by whether - // nSequence < nThreshold (CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG). - // - // We want to compare apples to apples, so fail the script - // unless the type of nSequence being tested is the same as - // the nSequence in the transaction. - if (!( - (txToSequence < nThreshold && nSequence < nThreshold) || - (txToSequence >= nThreshold && nSequence >= nThreshold) - )) - return false; - - // Now that we know we're comparing apples-to-apples, the - // comparison is a simple numeric one. - if (nSequence > txToSequence) - return false; - - return true; - } + if (stack.size() < 1) + return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); + + // Note that elsewhere numeric opcodes are limited to + // operands in the range -2**31+1 to 2**31-1, however it is + // legal for opcodes to produce results exceeding that + // range. This limitation is implemented by CScriptNum's + // default 4-byte limit. + // + // Thus as a special case we tell CScriptNum to accept up + // to 5-byte bignums, which are good until 2**39-1, well + // beyond the 2**32-1 limit of the nSequence field itself. + const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5); + + // In the rare event that the argument may be < 0 due to + // some arithmetic being done first, you can always use + // 0 MAX CHECKSEQUENCEVERIFY. + if (nSequence < 0) + return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); + + // To provide for future soft-fork extensibility, if the + // operand has the disabled lock-time flag set, + // CHECKSEQUENCEVERIFY behaves as a NOP. + if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) + break; + + // Compare the specified sequence number with the input. + if (!checker.CheckSequence(nSequence)) + return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); + + break; +} + +bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const +{ + // Relative lock times are supported by comparing the passed + // in operand to the sequence number of the input. + const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence; + + // Fail if the transaction's version number is not set high + // enough to trigger BIP 68 rules. + if (static_cast<uint32_t>(txTo->nVersion) < 2) + return false; + + // Sequence numbers with their most significant bit set are not + // consensus constrained. Testing that the transaction's sequence + // number do not have this bit set prevents using this property + // to get around a CHECKSEQUENCEVERIFY check. + if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) + return false; + + // Mask off any bits that do not have consensus-enforced meaning + // before doing the integer comparisons + const uint32_t nLockTimeMask = CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK; + const int64_t txToSequenceMasked = txToSequence & nLockTimeMask; + const CScriptNum nSequenceMasked = nSequence & nLockTimeMask; + + // There are two kinds of nSequence: lock-by-blockheight + // and lock-by-blocktime, distinguished by whether + // nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG. + // + // We want to compare apples to apples, so fail the script + // unless the type of nSequenceMasked being tested is the same as + // the nSequenceMasked in the transaction. + if (!( + (txToSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked < CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) || + (txToSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG && nSequenceMasked >= CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) + )) + return false; + + // Now that we know we're comparing apples-to-apples, the + // comparison is a simple numeric one. + if (nSequenceMasked > txToSequenceMasked) + return false; + + return true; +} +</pre> ==Reference Implementation== diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 15fa4f3..d21054b 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -34,8 +34,9 @@ value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block. -This proposal seeks to ensure reliable behaviour in locktime calculations as -required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68 (sequence numbers), and BIP112 (CHECKSEQUENCEVERIFY). +This proposal seeks to ensure reliable behaviour in locktime calculations +as required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of +BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY). ==Specification== @@ -58,11 +59,10 @@ block time for the purpose of checking lock-time constraints: return pbegin[(pend - pbegin)/2]; } -Lock-time constraints are checked by the consensus method IsFinalTx(), -or LockTime() under BIP68. These methods take the block time as one -parameter. This BIP proposes that after activation calls to -IsFinalTx() or LockTime() within consensus code use the return value -of `GetMedianTimePast(pindexPrev)` instead. +Lock-time constraints are checked by the consensus method IsFinalTx(). +This method takes the block time as one parameter. This BIP proposes +that after activation calls to IsFinalTx() within consensus code use +the return value of `GetMedianTimePast(pindexPrev)` instead. A reference implementation of this proposal is provided by the following pull request: @@ -72,33 +72,10 @@ https://github.com/bitcoin/bitcoin/pull/6566 ==Deployment== -We reuse the double-threshold switchover mechanism from BIPs 34 and -66, with the same thresholds, but for nVersion = 8. The new rules are -in effect for every block (at height H) with nVersion = 8 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion = 8. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion = 8, nVersion = 3 blocks become -invalid, and all further blocks enforce the new rules. +This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). +Exact details TBD. -When assessing the block version as mask of ~0x20000007 must be applied -to work around the complications caused by -[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use] -of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal]. - -By applying ~0x20000007 with nVersion = 8, the thresholds should be tested -comparing block nVersion >= 4 as this will save a bit for future use. - -It is recommended that this soft-fork deployment trigger include other related -proposals for improving Bitcoin's lock-time capabilities, including: - -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: -CHECKLOCKTIMEVERIFY, - -[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: -Consensus-enforced transaction replacement signalled via sequence numbers, - -and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: -CHECKSEQUENCEVERIFY. +It is recommended to deploy BIP68 and BIP112 at the same time as this BIP. ==Acknowledgements== diff --git a/bip-0133.mediawiki b/bip-0133.mediawiki new file mode 100644 index 0000000..7d98f87 --- /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 a node's mempool are not relayed by this node and the functionality 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 implementation 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 disabling the fee filter to make sure it is exposed to all possible txid's. + +==Backward compatibility== + +Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/7542 + +==Copyright== +This document is placed in the public domain. |
