diff options
| -rw-r--r-- | README.mediawiki | 16 | ||||
| -rw-r--r-- | bip-0001.mediawiki | 14 | ||||
| -rw-r--r-- | bip-0022.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0062.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0065.mediawiki | 36 | ||||
| -rw-r--r-- | bip-0099.mediawiki | 365 | ||||
| -rw-r--r-- | bip-0102.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0112.mediawiki | 189 | ||||
| -rw-r--r-- | bip-0130.mediawiki | 47 |
9 files changed, 551 insertions, 124 deletions
diff --git a/README.mediawiki b/README.mediawiki index c4d7d86..b5e4019 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -234,7 +234,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Dealing with malleability | Pieter Wuille | Standard -| Draft +| Withdrawn |- | 63 | Stealth Addresses @@ -302,13 +302,19 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0099.mediawiki|99]] +| Motivation and deployment of consensus rule changes +| Jorge Timón +| Informational | Process +| Draft +|- | [[bip-0101.mediawiki|101]] | Increase maximum block size | Gavin Andresen | Standard | Draft |- -| [[bip-0102.mediawiki|101]] +| [[bip-0102.mediawiki|102]] | Block size increase to 2MB | Jeff Garzik | Standard @@ -367,6 +373,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Eric Lombrozo | Informational | Draft +|- +| [[bip-0130.mediawiki|130]] +| sendheaders message +| Suhas Daftuar +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index c18ebd3..6901080 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -25,6 +25,8 @@ There are three kinds of BIP: The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. +Authors MUST NOT self assign numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject. + The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this. @@ -155,11 +157,13 @@ For each new BIP that comes in an editor does the following: If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. -Once the BIP is ready for the repository, the BIP editor will: +Once the BIP is ready for the repository it should be submitted as a "pull request" to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub where it may get further feedback. + +The BIP editor will: -* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141). +* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments. -* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub. +* Merge the pull request when the author is ready (allowing some time for further peer review). * List the BIP in [[README.mediawiki]] @@ -172,3 +176,7 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit ==History== This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list. + +==Changelog== + +10 Oct 2015 - Added clarifications about sumission process and BIP number assignment. diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index ffb303b..b39f957 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -53,7 +53,7 @@ getblocktemplate MUST return a JSON Object containing the following keys: |- | 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 inadvertantly expend SIGOPs (which are counted toward limits, despite not being executed). +| coinbaseaux || {{No}} || Object || data that SHOULD be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys. This does not include the block height, which is required to be included in the scriptSig by [[bip-0034.mediawiki|BIP 0034]]. It is advisable to encode values inside "PUSH" opcodes, so as to not inadvertently expend SIGOPs (which are counted toward limits, despite not being executed). |- | coinbasetxn || {{Patch|this or ↓}} || Object || [[#Transactions Object Format|information for coinbase transaction]] |- diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 5d46b7c..28b20dd 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -4,7 +4,7 @@ BIP: 62 Title: Dealing with malleability Author: Pieter Wuille <pieter.wuille@gmail.com> - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2014-03-12 </pre> diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index ed87478..b48fa75 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -18,8 +18,8 @@ some point in the future. CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed it compares the top item on the stack to the nLockTime field of the transaction -containing the scriptSig. If that top stack item is greater than the transaction -nLockTime the script fails immediately, otherwise script evaluation continues +containing the scriptSig. If that top stack item is greater than the transaction's +nLockTime field the script fails immediately, otherwise script evaluation continues as though a NOP was executed. The nLockTime field in a transaction prevents the transaction from being mined @@ -32,18 +32,14 @@ remains unspendable. ==Motivation== -The nLockTime field in transactions makes it possible to prove that a -transaction output can be spent in the future: a valid signature for a -transaction with the desired nLockTime can be constructed, proving that it is -possible to spend the output with that signature when the nLockTime is reached. -An example where this technique is used is in micro-payment channels, where the -nLockTime field proves that should the receiver vanish the sender is guaranteed -to get all their escrowed funds back when the nLockTime is reached. +The nLockTime field in transactions can be used to prove that it is +''possible'' to spend a transaction output in the future, by constructing a +valid transaction spending that output with the nLockTime field set. -However, the nLockTime field is insufficient if you wish to prove that a -transaction output ''cannot'' be spent until some time in the future, as there -is no way to prove that the secret keys corresponding to the pubkeys controlling -the funds have not been used to create a valid signature. +However, the nLockTime field can't prove that it is ''impossible'' to spend a +transaction output until some time in the future, as there is no way to know if +a valid signature for a different transaction spending that output has been +created. ===Escrow=== @@ -89,9 +85,9 @@ requires the co-operation of both parties to spend the output. To ensure the failure of one party does not result in the funds becoming lost, refund transactions are setup in advance using nLockTime. These refund transactions need to be created interactively, and additionaly, are currently vulnerable to -transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, +transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the interactive setup with a non-interactive setup, and additionally, -making transaction mutability (aka malleability) a non-issue. +making transaction malleability a non-issue. ====Two-factor wallets==== @@ -121,14 +117,14 @@ Now the user is always able to spend their funds without the co-operation of the service by waiting for the expiry time to be reached. -====Micropayment Channels==== +====Payment Channels==== -Jeremy Spilman style micropayment channels first setup a deposit controlled by +Jeremy Spilman style payment channels first setup a deposit controlled by 2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends the output of tx1 to payor and payee. Prior to publishing tx1 a refund transaction is created, tx3, to ensure that should the payee vanish the payor can get their deposit back. The process by which the refund transaction is -created is currently vulnerable to transaction mutability attacks, and +created is currently vulnerable to transaction malleability attacks, and additionally, requires the payor to store the refund. Using the same scriptPubKey from as in the Two-factor wallets example solves both these issues. @@ -168,7 +164,7 @@ non-trivial, and even the best existing technqiue - announce-commit sacrifices - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone (thus to mining fees assuming miners behave optimally and rationally) but only at a time -sufficiently far into the future that large miners profitably can't sell the +sufficiently far into the future that large miners can't profitably sell the sacrifices at a discount. @@ -307,7 +303,7 @@ time. PayPub - https://github.com/unsystem/paypub -Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html +Jeremy Spilman Payment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html ==Implementations== diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki new file mode 100644 index 0000000..c40bacb --- /dev/null +++ b/bip-0099.mediawiki @@ -0,0 +1,365 @@ +<pre> + BIP: 99 + Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) + Author: Jorge Timón <jtimon@jtimon.cc> + Status: Draft + Type: Informational | Process + Created: 2015-06-20 + Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html +</pre> + +==Abstract== + +This BIP attempts to create a taxonomy of the different types of +consensus forks and proposes a deployment mechanism for each of them. + +==Motivation== + +The security assumptions of p2p consensus-based systems like Bitcoin are +not always well-understood, and the best upgrade mechanisms to the +consensus validation rules may vary depending on the type of change being deployed. +Discussing such changes without a uniform view on the deployment +paths often leads to misunderstandings and unnecessarily delays the +deployment of changes. + +==Definitions== + +;Software fork +: A copy of an existing project. In free software, this can be done without the permission of the original project's maintainers. + +;Consensus fork +: A divergence in the implementation of the verification consensus rules can impede the expected eventual convergence of the network in a single chain that has the most proof of work and also satisfies the rules. This can be intentional or be caused by a bug in consensus validation reimplementations. + +;Softfork +: A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility. + +;Hardfork +: A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade. + +;Libconsensus +: a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest). + +;Libbitcoinconsensus +: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line + +==Taxonomy of consensus forks== + +===Accidental consensus fork=== + +Software forks are very different in nature from consensus rules forks. No software +maintainer has special powers over consensus rules changes. There's +many good reasons (experimentation, lack of features, independent +development, diversity, etc) to fork the Bitcoin Core software and it's good +that there's many alternative implementations of the protocol (forks +of Bitcoin Core or written from scratch). + +But sometimes a bug in the reimplementaion of the consensus +validation rules can prevent users of alternative implementation from +following the longest (most work) valid chain. This can result in +those users losing coins or being defrauded, making reimplementations +of the consensus validation rules very risky. Note that a natural +language specification of those rules doesn't help since the +consensus is not determined by such specification but by the software +that the majority of the network runs. That's why "the implementation +is the specification". + +But Bitcoin Core contains many more things than just consensus +validation and it would be unreasonable for all alternative +implementations to depend on it. Bitcoin Core should not be the +specification. That's why the consensus validation is being separated +into a libbitcoinconsensus library with a C API easily accessible from +any language. This makes alternative implementations much more secure +without burdening them with specific design choices made by Bitcoin +Core. It is to be noted that sharing the same code for consensus +validation doesn't prevent alternative implementations from +independently changing their consensus rules: they can always fork +the libbitcoinconsensus project (once it is in a separate repository). + +Hopefully libbitcoinconsensus will remove this type of consensus fork +which - being accidental - obviously doesn't need a deployment plan. + +====11/12 March 2013 Chain Fork==== + +There is a precedent of an accidental consensus fork at height 225430. +Without entering into much detail (see [2]), the situation was different from +what's being described from the alternative implementation risks (today alternative implementation +still usually rely in different degrees on Bitcoin Core trusted proxies, which +is very reasonable considering the lack of a complete libconsensus). +The two conflicting consensus validation implementations were two +different versions of Bitcoin Core (Bitcoin-qt at the time): 0.8 +against all versions prior to it. Most miners had been fast on +upgrading to 0.8 and they were also fast on downgrading to 0.7 as an +emergency when they were asked to by the developers community. + +A short summary would be that BDB was being +abandoned in favor of levelDB, and - at the same time - the miner's +policy block size limit was being lift (it was not a consensus rule, +not even enforced via softfork). Even after testing, a case where +levelDB couldn't correctly validate certain bigger blocks only appeared after +deployment in production. Fortunately this was handled very well and +rapidly by the whole worldwide community and nobody is unhappy about +the solution. + +But there's some philosophical disagreements on the terms of what the +solution was: we can add a pedantic note on that. +If "the implementation is the specification", then those +levelDB-specific limitations were part of the consensus rules. +Then additional rules were necessary and any alternative +implementation (including 0.8) would have to implement it. Then a +planned consensus fork to migrate all Bitcoin-qt 0.7- users could +remove those additional consensus restrictions. +Had libconsensus being implemented without depending on levelDB, +those additional restrictions wouldn't have been part of "the specification" + and this would just have been a bug in the +consensus rules, just a consensus-critical bug in a set of +implementations, concretely all satoshi-bitcoin-0.7-or-less (which +happened to be a huge super majority of the users), but other +implementations (like libbitcoin) would be free from such bug and +implementing the correct libconsensus specification. But since the +buggy implementation was a super-majority, the solution would have +been to instantly (from a specific block) change the rules to not let +the super-majority deviate from the specification and then have +another consensus fork to remove them. Two theoretical consensus forks +instead of one but the first one deployed practically for free. The +practical result would have been identical and only the definitions +change. This means discussing something that went uncontroversially +well further is "philosophical bike-shed" (TM). + +===Unilateral softforks=== + +If it is in their best interest of miners to softfork it should be +assumed that they may likely enforce it. In some cases, even against the will of a +super-majority of users. This is practically an attack on the network +and the only solution is to carefully design the incentives so that +the case is simply impossible. If that fails, miners should still +consider the risk of motivating a schism hardfork before attempting +such a consensus fork. A deployment plan for this case is also +unnecessary. + +===Schism hardforks=== + +Fundamental disagreements and controversies are part of social +systems, like the one defined as the human participants in the Bitcoin +network. Without judging the motivation of the rule discrepancies or +what rules were in place first, we're definining schism[1] hardforks as +those in which - for whatever reason - users are consiously going to validate 2 +different sets of consensus rules. Since they will validate different +rulesets, they will end up following 2 different chains for at least +some time, maybe forever. + +One possible result observed in the past[non_proportional_inflatacoin_fork] +is that one of the chains rapidly disappears, but nothing indicates +that this must always be the case. + +While 2 chains cohexist, they can be considered two different +currencies. +We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market +capitalization are completely unpredictable, + +maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), + +maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), + +maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin), + +maybe mc(bitcoinA) + mc(bitcoinB) = 0, + +... + +Schism hardforks have been compared to one type of altcoins called +"spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to +bitcoin owners at a given block height. + +This is very disruptive and hopefully will never be needed. But if +it's needed the best deployment path is just to activate the rule +changes after certain block height in the future. On the other hand, +it is healthy decentralization-wise that many independent software +projects are ready to deploy a schism hardfork. + +In all of the following examples there's clearly a confrontation that +is being resolved using an intentional consensus hardfork. + +====ASIC-reset hardfork==== + +Imagine ASIC production has been consolidated to a single company and +distribution is simply not happening: the company is keeping them to +mine itself. For that or another reason, a single entity controls +40%+ of the hashrate and there's no hope for an spontaneous +improvement in decentralization. Such an untenable centralization could +be fixed (with great risks) by switching the hash function used in the +proof of work, effectively "pressing the restart button" on the ASIC +market. The next function should be simple to implement in ASIC as +well so that the market can more easily develop as a healthy and +competitive one (as opposed to what the "ASIC-hard" proponents would +want), but that's another story...] + +Since in this case the confrontation is clearly against the current +miners any notion of "miners' voting" is utterly irrelevant. + +====Anti-Block-creator hardfork==== + +There's less extreme cases where changing the pow function would not +be necessary. For example, let's imagine a bright future where +commoditized ASICs are running in millions home-heaters all over the +world, but the block size has been completely removed and the network has devolved to a +very centralized system where only 2 big pools have the resources to +fully validate full blocks and create block templates with competitive levels of +transaction fees. In that case, changing the pow function would be a +terrible waste and a risk that could be avoided. A hardfork restoring +a block size limit could help fixing this situation. Please don't +take it as an argument for or against raising the block size limit: +it's just an example. But in this case, again, those 2 big pools +would probably be against the fork and, again, their voting is +irrelevant. + +Like in the previous example, miners are expected to oppose and they +have to be ignored. + +====Anti-cabal hardfork==== + +Let's imagine BIP66 had a crypto backdoor +that nobody noticed and allows an evil developer cabal to steal +everyone's coins. The users and non-evil developers could join, fork +libconsensus and use the forked version in their respective bitcoin +implementations. +Should miner's "vote" be required to express their consent? What if some miners +are part of the cabal? In the unlikely event that most miners are +part of such an evil cabal, changing the pow function may be +required. In other cases, mining "vote" doesn't have much value +either since this kind of hardfork would not qualify as +uncontroversial anyway. + +===Uncontroversial consensus upgrades=== + +"Uncontroversial" is something tough to define in this context. What +if a single user decides he won't upgrade no matter what and +he doesn't even attempt to explain his decision? Obviously, such +a user should be just ignored. But what if the circumstances are +slightly different? What if they're 2, 10 users? where's the line. +It is possible that we can never have a better definition than "I know +it when I see it" [citation needed]. + +====Uncontroversial softforks==== + +If a majority of miners adopts a softfork, users will follow that +chain, even without understanding the new rules. For them is like +if blocks are created in a certain way or certain valid transactions +are being rejected by miners for some reason. For old nodes it just +looks like the new rules are policy rules rather than consensus rules. +This greatly reduces the deployment risks, making softforks the +preferred consensus rules upgrade mechanism. + +The first precedent of a softfork was the introduction of P2SH +documented in BIP16. There were competing proposals, but BIP12 had +clear disadvantage and BIP17 was considered a less tested but +functionally equivalent version by most of the reviewers. Although it +was later discovered that BIP16 had unnecessary limitations and BIP17 +is now considered superior, this probably still qualified for our +vague concept of "uncontroversial". + +At the time, there was no "mining voting" implementation and it was +simply deployed using the timestamp of the blocks at some time in the +future as the activation trigger. This can't guarantee the assumption +that most miners have upgraded before enforcing the new rules and +that's why the voting mechanism and first used for BIP30 and BIP66. +The current voting threshold for softfork enforcement is 95%. There's +also a 75% threshold for miners to activate it as a policy rule, but +it should be safe for miners to activate such a policy from the start +or later than 75%, as long as they enforce it as consensus rule after 95%. + +The current miners' voting mechanism can be modified to allow for +changes to be deployed in parallel, the rejection of a concrete +softfork without getting locked for the deployment of the next one, +and also a more efficient use of the version field in block +headers [3]. BIP65 is expected to be deployed with the improved +mechanism. + +====Uncontroversial hardforks==== + +Some consensus changes require all participants to upgrade their software +before the new rules can be safely activated or they will face serious +risk of following the wrong chain and being defrauded. Even if the +exact same mechanism used for softforks would be more risky in these +cases, that doesn't mean that this type of changes cannot be deployed +in an uncontroversial and safe manner. + +The simplest approach is to select a block height far enough in the +future that everybody has plenty of time to change their software. +But if you're aiming for universal adoption, that includes miners' +adoption, so it seems reasonable to use a mining voting on top of +that. In this case there's only one relevant threshold and it could +be different from the softfork one. Probably 100% is too strict, +since it would allow a relatively small miner to attack the network +and block a consensus upgrade. Something between 99% and 95% is +probably a sensible choice for this parameter. + +====Uncontroversial emergency hardforks==== + +Emergency forks may not have time to consult miners and have to be +deployed simply by choosing a block height not so far in the future. + +But emergency forks could be prepared ahead of time. For example, an +intermediary version of software could allow blocks +that are double the size of old blocks (after a certain height in the +future) while still making miners reject bigger blocks as a softfork +rule. Then miners can start the regular process for uncontroversial +softfork (or a unilateral softfork if they're a majority) at any +point in the future if it is required, and both intermediary and new +versions would be prepared for it (which would make deployment much +easier). Other related consensus changes could be deployed in the +meantime (say, quadrupling the block size) making the emergency +softfork unnecessary. + +==Code== + +This BIP is complemented with a concrete code proposal[4] for an +uncontroversial hardfork which acts as a precedent and removes the +perception that hardforks are impossible in Bitcoin. The deployment of +the proposal should not block any other potential hardforks (thus it +will required the version bits proposal[3] to be implemented). The +change itself doesn't add much complexity to Bitcoin Core and is simple +enough that is trivial to apply to diverse implementations (that +currently can only use libbitcoinconsensus to validate script-related +rules). The change has been already widely tested in many altcoins. + +The chosen consensus change is the fix of the timewarp attack +discovered and also fixed with a simple patch[5] by @ArtForz. This +change has been deployed by most altcoins that made any minimally +meaningful change to bitcoin and thus can be considered somewhat +tested (in fact, most SHA256d altcoins that didn't implement it have +died or being forced to implement it as an emergency hardfork). When +deploying this change has been discussed, usually arguments in the +lines of "if we get to the point when this matters to bitcoin, we +would be already in serious trouble" were used against it. This +shouldn't be seen as a disadvantage in this context, since it means we +can safely activate the fix very far away in the future (say, 4 years +worth of blocks). + +==Footnotes== + +[1] https://en.wikipedia.org/wiki/Schism + +[2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki + +[non_proportional_inflatacoin_fork] TODO missing link + +[spinoffs] https://bitcointalk.org/index.php?topic=563972.0 + +[3] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki + +[4] https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 + +[5] Original references: +https://bitcointalk.org/index.php?topic=114751.0 +https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 +Rebased patch: +https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14 + +==Attribution== + +Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, +Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki index 6694cb8..b75f798 100644 --- a/bip-0102.mediawiki +++ b/bip-0102.mediawiki @@ -9,7 +9,7 @@ ==Abstract== -Increase total amount of transaction data permitted in a block from 1MB to 2MB on November 11, 2015. +Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB. ==Motivation== @@ -20,7 +20,7 @@ Increase total amount of transaction data permitted in a block from 1MB to 2MB o ==Specification== # Maximum block size permitted to be valid is 1MB. -# Increase this maximum to 2MB on November 11, 2015 at 00:00:00 UTC. +# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support. # Increase maximum block sigops by similar factor, preserving SIZE/50 formula. ==Backward compatibility== diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index e1a186f..c7ee45e 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -20,24 +20,19 @@ being spent. ==Summary== CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. -When executed, the script interpreter continues as if a NOP was executed -so long as one of the following conditions is met: +When executed, if any of the following conditions are true, the script interpreter will terminate with an error: - * the transaction's nVersion field is 0 or 1; - * the top item on the stack is a value greater than or equal to (1 << 31); or - * the top item on the stack and the transaction input's sequence number are both relative lock-times of the same units, and the relative lock-time represented by the sequence number is greater than or equal to the relative lock-time represented by the top item on the stack. +* the top item on the stack is less than 0; or +* the top item on the stack has the disable flag (1 << 31) unset; and +** the transaction version is less than 2; or +** the transaction input sequence number disable flag (1 << 31) is set; and +** the relative lock-time type is not the same; or +** the top stack item is greater than the transaction sequence (when masked according to the BIP68); -Otherwise, script execution terminates with an error. +Otherwise, script execution will continue as if a NOP had been executed. -BIP 68's redefinition of nSequence prevents a non-final transaction -from being selected for inclusion in a block until the corresponding -input has reached the specified age, as measured in block height or -block time. By comparing the argument to CHECKSEQUENCEVERIFY against -the nSequence field, we indirectly verify a desired minimum age of the -the output being spent; until that relative age has been reached any -script execution pathway including the CHECKSEQUENCEVERIFY will fail -to validate, causing the transaction not to be selected for inclusion -in a block. +BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age, as measured in block-height or block-time. By comparing the argument to CHECKSEQUENCEVERIFY against the nSequence field, we indirectly verify a desired minimum age of the +the output being spent; until that relative age has been reached any script execution pathway including the CHECKSEQUENCEVERIFY will fail to validate, causing the transaction not to be selected for inclusion in a block. ==Motivation== @@ -85,9 +80,9 @@ of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security -reasons, is designed to be very hard and very expensive to deliberately pull off. +reasons, is designed to be very hard and very expensive to do. -Despite this limitation, we do have a way to provide something functionally similar +Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the @@ -100,7 +95,7 @@ Some more specific applications of this idea: ====Hash Time-Locked Contracts==== -Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead. +Hash Time-Locked Contracts (HTLCs) provide a general mechanism for off-chain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead. ====Bidirectional Payment Channels==== @@ -142,11 +137,12 @@ A simple output, paying to Alice might then look like: HASH160 <revokehash> EQUAL IF - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Bob key hash> ELSE - "24h" CHECKSEQUENCEVERIFY - DUP HASH160 <Alice key hash> CHECKSIGVERIFY + "24h" CHECKSEQUENCEVERIFY DROP + <Alice key hash> ENDIF + CHECKSIG This allows Alice to publish the latest commitment transaction at any time and spend the funds after 24 hours, but also ensures that if Alice @@ -156,17 +152,18 @@ With CHECKLOCKTIMEVERIFY, this would look like: HASH160 <revokehash> EQUAL IF - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Bob key hash> ELSE - "2015/12/15" CHECKLOCKTIMEVERIFY - DUP HASH160 <Alice key hash> CHECKSIGVERIFY + "2015/12/15" CHECKLOCKTIMEVERIFY DROP + <Alice key hash> ENDIF + CHECKSIG This form of transaction would mean that if the anchor is unspent on 2015/12/16, Alice can use this commitment even if it has been revoked, simply by spending it immediately, giving no time for Bob to claim it. -Ths means that the channel has a deadline that cannot be pushed +This means that the channel has a deadline that cannot be pushed back without hitting the blockchain; and also that funds may not be available until the deadline is hit. CHECKSEQUENCEVERIFY allows you to avoid making such a tradeoff. @@ -179,35 +176,33 @@ delay, and the entire output can be claimed by the other party if the revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to Alice might look like the following in Alice's commitment transaction: - HASH160 DUP <revokehash> EQUAL + HASH160 DUP <R-HASH> EQUAL IF - DROP DUP HASH160 <Bob key hash> CHECKSIGVERIFY + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Alice key hash> ELSE - <R hash> EQUAL - IF - "24h" CHECKSEQUENCEVERIFY DROP - DUP HASH160 <Alice key hash> CHECKSIGVERIFY - ELSE - "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP - DUP HASH160 <Bob key hash> CHECKSIGVERIFY + <Commit-Revocation-Hash> EQUAL + NOTIF + "24h" CHECKLOCKTIMEVERIFY DROP ENDIF + <Bob key hash> ENDIF + CHECKSIG and correspondingly in Bob's commitment transaction: - HASH160 DUP <revokehash> EQUAL + HASH160 DUP <R-HASH> EQUAL + SWAP <Commit-Revocation-Hash> EQUAL ADD IF - DROP DUP HASH160 <Alice key hash> CHECKSIGVERIFY + <Alice key hash> ELSE - <R hash> EQUAL - IF - DUP HASH160 <Alice key hash> CHECKSIGVERIFY - ELSE - "24h" CHECKSEQUENCEVERIFY DROP - "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP - DUP HASH160 <Bob key hash> CHECKSIGVERIFY - ENDIF + "2015/10/20 10:33" CHECKLOCKTIMEVERIFY + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Bob key hash> ENDIF + CHECKSIG Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the final branch of above to ensure Bob cannot spend the output until after both @@ -234,15 +229,19 @@ Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. - /* Threshold for nSequence: below this value it is interpreted - * as a relative lock-time, otherwise ignored. */ - static const uint32_t SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31); + /* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. */ + static const uint32_t SEQUENCE_LOCKTIME_DISABLE_FLAG = (1 << 31); - /* Threshold for nSequence when interpreted as a relative - * lock-time: below this value it has units of blocks, otherwise - * seconds. */ - static const uint32_t SEQUENCE_UNITS_THRESHOLD = (1 << 30); + /* 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)) { @@ -252,10 +251,10 @@ semantics and detailed rationale for those semantics. } break; } - + 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 @@ -266,23 +265,23 @@ semantics and detailed rationale for those semantics. // 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 is too large to be treated as a relative lock- - // time, CHECKSEQUENCEVERIFY behaves as a NOP. - if (nSequence >= SEQUENCE_LOCKTIME_THRESHOLD) + // operand has the disabled lock-time flag set, + // CHECKSEQUENCEVERIFY behaves as a NOP. + if ((nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) break; - - // Actually compare the specified sequence number with the input. + + // Compare the specified sequence number with the input. if (!checker.CheckSequence(nSequence)) return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); - + break; } @@ -291,38 +290,52 @@ semantics and detailed rationale for those semantics. // 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 above SEQUENCE_LOCKTIME_THRESHOLD - // are not consensus constrained. Testing that the transaction's - // sequence number is not above this threshold prevents - // using this property to get around a CHECKSEQUENCEVERIFY - // check. - if (txToSequence >= SEQUENCE_LOCKTIME_THRESHOLD) + + // 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; - // There are two kinds of nSequence: lock-by-blockheight + 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 < SEQUENCE_UNITS_THRESHOLD. + // 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 < SEQUENCE_UNITS_THRESHOLD && nSequence < SEQUENCE_UNITS_THRESHOLD) || - (txToSequence >= SEQUENCE_UNITS_THRESHOLD && nSequence >= SEQUENCE_UNITS_THRESHOLD) + (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 (txTo->vin[nIn].nSequence > txToSequence) + if (nSequence > txToSequence) return false; - + return true; } @@ -336,25 +349,10 @@ https://github.com/bitcoin/bitcoin/pull/6564 ==Deployment== -We reuse the double-threshold switchover mechanism from BIPs 34 and -66, with the same thresholds, but for nVersion = 4. The new rules are -in effect for every block (at height H) with nVersion = 4 and at least -750 out of 1000 blocks preceding it (with heights H-1000..H-1) also -have nVersion = 4. Furthermore, when 950 out of the 1000 blocks -preceding a block do have nVersion = 4, 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 TDB. -It is recommended that this soft-fork deployment trigger include other -related proposals for improving Bitcoin's lock-time capabilities, including: +It is recommended to deploy BIP68 and BIP113 at the same time as this BIP. -[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: -OP_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-0113.mediawiki BIP 113]: -Median-Past-Time-Lock. ==Credits== @@ -367,12 +365,12 @@ done by Peter Todd for the closely related BIP 65. BtcDrak authored this BIP document. -Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases. +Thanks to Eric Lombrozo and Anthony Towns for contributing example use cases. ==References== -[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Consensus-enforced transaction replacement signalled via sequence numbers +[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Relative lock-time through consensus-enforced sequence numbers [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY @@ -397,3 +395,4 @@ Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases. This document is placed in the public domain. + diff --git a/bip-0130.mediawiki b/bip-0130.mediawiki new file mode 100644 index 0000000..56184e3 --- /dev/null +++ b/bip-0130.mediawiki @@ -0,0 +1,47 @@ +<pre> + BIP: 130 + Title: sendheaders message + Author: Suhas Daftuar <sdaftuar@chaincode.com> + Status: Draft + Type: Standards Track + Created: 2015-05-08 +</pre> + +==Abstract== + +Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". + +==Motivation== + +Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless +they are able to connect to a (valid) headers chain. Consequently, block relay generally works +as follows: +# A node (N) announces the new tip with an "inv" message, containing the block hash +# A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself +# N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block + +However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator). + +In the case of a reorg, where 1 or more blocks are disconnected, nodes currently just send an "inv" for the new tip. Peers currently are able to request the new tip immediately, but wait until the headers for the intermediate blocks are delivered before requesting those blocks. By announcing headers from the last fork point leading up to the new tip in the block announcement, peers are able to request all the intermediate blocks immediately. + +==Specification== + +# The sendheaders message is defined as an empty message where pchCommand == "sendheaders" +# Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect). +# Feature discovery is enabled by checking protocol version >= 70012 + +==Additional constraints== + +As support for sendheaders is optional, software that implements this may also optionally impose additional constraints, such as only honoring sendheaders messages shortly after a connection is established. + +==Backward compatibility== + +Older clients remain fully compatible and interoperable after this change. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/6494 + +==Copyright== + +This document is placed in the public domain. |