diff options
45 files changed, 4052 insertions, 183 deletions
diff --git a/README.mediawiki b/README.mediawiki index 13e38e8..8e82118 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1,4 +1,4 @@ -People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. +People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Luke Dashjr <luke_bipeditor@dashjr.org>. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. @@ -16,9 +16,15 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0001.mediawiki|1]] | BIP Purpose and Guidelines | Amir Taaki -| Standard +| Process | Active |- +| [[bip-0009.mediawiki|9]] +| Version bits with timeout and delay +| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell +| Informational +| Draft +|- | [[bip-0010.mediawiki|10]] | Multi-Sig Transaction Distribution | Alan Reiner @@ -64,8 +70,8 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0017.mediawiki|17]] | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr +| Standard | Withdrawn -| Draft |- | [[bip-0018.mediawiki|18]] | hashScriptCheck @@ -147,7 +153,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- style="background-color: #cfffcf" | [[bip-0037.mediawiki|37]] | Bloom filtering -| Mike Hearn and Matt Corallo +| Mike Hearn, Matt Corallo | Standard | Accepted |- @@ -199,6 +205,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0047.mediawiki|47]] +| Reusable Payment Codes for Hierarchical Deterministic Wallets +| Justus Ranvier +| Informational +| Draft +|- | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem | Gavin Andresen @@ -222,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 @@ -255,8 +267,8 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0068.mediawiki|68]] -| Consensus-enforced transaction replacement signalled via sequence numbers -| Mark Friedenbach +| Relative lock-time through consensus-enforced sequence numbers +| Mark Friedenbach, BtcDrak, Nicolas Dorier | Standard | Draft |- @@ -290,11 +302,131 @@ 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|102]] +| Block size increase to 2MB +| Jeff Garzik +| Standard +| Draft +|- +| [[bip-0103.mediawiki|103]] +| Block size following technological growth +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0105.mediawiki|105]] +| Consensus based block size retargeting algorithm +| BtcDrak +| Standard +| Draft +|- +| [[bip-0106.mediawiki|106]] +| Dynamically Controlled Bitcoin Block Size Max Cap +| Upal Chakraborty +| Standard +| Draft +|- +| [[bip-0107.mediawiki|107]] +| Dynamic limit on the block size +| Washington Y. Sanchez +| Standard +| Draft +|- +| [[bip-0111.mediawiki|111]] +| NODE_BLOOM service bit +| Matt Corallo, Peter Todd +| Standard +| Draft +|- +| [[bip-0112.mediawiki|112]] +| CHECKSEQUENCEVERIFY +| BtcDrak, Mark Friedenbach +| Standard +| Draft +|- +| [[bip-0113.mediawiki|113]] +| Median time-past as endpoint for lock-time calculations +| Thomas Kerin, Mark Friedenbach +| Standard +| Draft +|- +| [[bip-0120.mediawiki|120]] +| Proof of Payment +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0121.mediawiki|121]] +| Proof of Payment URI scheme +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0122.mediawiki|122]] +| URI scheme for Blockchain references / exploration +| Marco Pontello +| Standard +| Draft +|- +| [[bip-0123.mediawiki|123]] +| BIP Classification +| Eric Lombrozo +| Informational +| Draft +|- +| [[bip-0125.mediawiki|125]] +| Opt-in Full Replace-by-Fee Signaling +| David Harding, Peter Todd +| Standard +| Draft +|- +| [[bip-0130.mediawiki|130]] +| sendheaders message +| Suhas Daftuar +| Standard +| Draft +|- +| [[bip-0140.mediawiki|140]] +| Normalized TXID +| Christian Decker +| Standard +| Draft +|- +| [[bip-0141.mediawiki|141]] +| Segregated Witness (Consensus layer) +| Eric Lombrozo, Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0142.mediawiki|142]] +| Address Formats for Witness Program +| Johnson Lau +| Standard +| Draft +|- +| [[bip-0143.mediawiki|143]] +| Transaction signature verification for version 0 and version 1 witness program +| Johnson Lau, Pieter Wuille +| Standard +| Draft +|- +| [[bip-0144.mediawiki|144]] +| Segregated Witness (Peer Services) +| Eric Lombrozo, Pieter Wuille +| 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..e1abadd 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -1,8 +1,8 @@ <pre> BIP: 1 Title: BIP Purpose and Guidelines - Status: Accepted - Type: Standards Track + Status: Active + Type: Process Created: 2011-08-19 </pre> @@ -13,6 +13,7 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + ==BIP Types== There are three kinds of BIP: @@ -23,28 +24,26 @@ There are three kinds of BIP: ==BIP Work Flow== -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]]. +The BIP process begins with a new idea for Bitcoin. Each potential 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@lists.linuxfoundation.org] 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. + +Vetting an idea publicly before going as far as writing a BIP is meant to save both the potential author and the wider community time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Small enhancements or patches often don't need standardisation between multiple projects; these don't need a BIP and should be injected into the relevant Bitcoin development work flow with a patch submission to the applicable Bitcoin issue tracker. -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. +Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list. This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be sent to the bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. -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. +BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. -Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. +It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones. -Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. +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]]. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. -Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. +Authors MUST NOT self assign BIP numbers, but should use an alias such as "bip-johndoe-infinitebitcoins" which includes the author's name/nick and the BIP subject. -If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. +If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the BIPs git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests. Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. -BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. - -For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. - Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. @@ -141,11 +140,11 @@ If you are interested in assuming ownership of a BIP, send a message asking to t ==BIP Editors== -The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]]. +The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]]. ==BIP Editor Responsibilities & Workflow== -A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com. +The BIP editor subscribes to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org. For each new BIP that comes in an editor does the following: @@ -155,20 +154,26 @@ 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. -* Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141). +The BIP editor will: -* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub. +* 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. -* List the BIP in [[README.mediawiki]] +* Merge the pull request when the author is ready (allowing some time for further peer review). -* Send email back to the BIP author with next steps (post to bitcoin mailing list). +* List the BIP in [[README.mediawiki]] -Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. +* Send email back to the BIP author with next steps (post to bitcoin-dev mailing list). -The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. +The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. ==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. + +01 Jan 2016 - Clarified early stages of BIP idea championing, collecting community feedback, etc. diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki new file mode 100644 index 0000000..b160810 --- /dev/null +++ b/bip-0009.mediawiki @@ -0,0 +1,168 @@ +<pre> + BIP: 9 + Title: Version bits with timeout and delay + Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au> + Status: Draft + Type: Informational Track + Created: 2015-10-04 +</pre> + +==Abstract== + +This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes. + +==Motivation== + +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. + +==Specification== + +===Mechanism=== + +'''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. + +'''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. + +'''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. + +'''Soft Fork Support''' +Software which supports the change should begin by setting B in all blocks +mined until it is resolved. + + if (BState != activated && BState != failed) { + SetBInBlock(); + } + +'''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. + + if (NextBlockHeight % 2016 == 0) { + if (BState == defined && Previous2016BlocksCountB() >= 1916) { + BState = locked-in; + BActiveHeight = NextBlockHeight + 2016; + } + } + +'''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; + } + } + +After another retarget period (to allow detection of buggy miners), +the bit may be reused. + +'''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. + +'''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=== + +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. + +'''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. + +'''Multi-stage soft forks''' +Soft forks right now are typically treated as booleans: they go from an inactive to an active state in blocks. Perhaps at some point there is demand for a change that has a larger number of stages, with additional validation rules that get enabled one by one. The above mechanism can be adapted to support this, by interpreting a combination of bits as an integer, rather than as isolated bits. The warning system is compatible with this, as (nVersion & ~nExpectedVersion) will always be non-zero for increasing integers. + +== Rationale == + +The failure timeout allows eventual reuse of bits even if a soft fork was +never activated, so it's clear that the new use of the bit refers to a +new BIP. It's deliberately very course grained, to take into account +reasonable development and deployment delays. There are unlikely to be +enough failed proposals to cause a bit shortage. + +The fallow period at the conclusion of a soft fork attempt allows some +detection of buggy clients, and allows time for warnings and software +upgrades for successful soft forks. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki index 07dca96..44011d5 100644 --- a/bip-0017.mediawiki +++ b/bip-0017.mediawiki @@ -2,8 +2,8 @@ BIP: 17 Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr <luke+bip17@dashjr.org> - Status: Draft - Type: Withdrawn + Status: Withdrawn + Type: Standards Track Created: 2012-01-18 </pre> diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 00d9a53..2706926 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -56,6 +56,7 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must *address: bitcoin address *message: message that describes the transaction to the user ([[#Examples|see examples below]]) *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) +*paycode: payment code (BIP-47) *(others): optional, for future extensions ==== Transfer amount/size ==== @@ -67,6 +68,11 @@ I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is inv Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount. + +==== Payment code ==== + +If a URI provides a payment code, and if the client supports BIP-47, then the resulting transaction SHOULD construct a transaction per BIP-47 instead of using the address provided in the URI. + == Rationale == ===Payment identifiers, not person identifiers=== @@ -122,3 +128,6 @@ Characters must be URI encoded properly. === Bitcoin clients === * Bitcoin-Qt supports the old version of Bitcoin URIs (ie without the req- prefix), with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858. +==References== + +* [[bip-0047.mediawiki|BIP47 - Reusable Payment Codes for Hierarchical Deterministic Wallets]] 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-0032.mediawiki b/bip-0032.mediawiki index 902a5eb..28541f5 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -209,7 +209,7 @@ It is also the reason for the existence of hardened keys, and why they are used ===Test vector 1=== -Master (hex): 000102030405060708090a0b0c0d0e0f +Seed (hex): 000102030405060708090a0b0c0d0e0f * Chain m ** ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8 ** ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi @@ -231,7 +231,7 @@ Master (hex): 000102030405060708090a0b0c0d0e0f ===Test vector 2=== -Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 +Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 * Chain m ** ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB ** ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki new file mode 100644 index 0000000..c3c5058 --- /dev/null +++ b/bip-0047.mediawiki @@ -0,0 +1,306 @@ +RECENT CHANGES: + +* (18 Dec 2015) Update explanations to resolve FAQs + +* (12 Oct 2015) Revise blinding method for notification transactions + +* (21 Sep 2015) Correct base58check version byte + +<pre> + BIP: 47 + Title: Reusable Payment Codes for Hierarchical Deterministic Wallets + Authors: Justus Ranvier <justus@openbitcoinprivacyproject.org> + Status: Draft + Type: Informational + Created: 2015-04-24 +</pre> + +==Abstract== + +This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. + +This BIP is a particular application of BIP43 and is intended to supplement HD wallets which implement BIP44. + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + +==Motivation== + +Payment codes add identity information to transactions which is useful in a merchant-customer interaction while protecting the privacy of users. Payment codes provide the privacy benefits of Darkwallet-style Stealth Addresses to SPV clients without requiring the assistance of a trusted full node and while greatly reducing reliance on blockchain storage. + +==Path levels== + +We define the following 3 levels in BIP32 path: + +<code> +m / purpose' / coin_type' / identity' +</code> + +The child keys derived from an identity are used in different ways: + +<code> +m / purpose' / coin_type' / identity' / 0 +</code> + +The 0th (non-hardened) child is the notification key. + +<code> +m / purpose' / coin_type' / identity' / 0 through 2147483647 +</code> + +These (non-hardened) keypairs are used for ECDH to generate deposit addresses. + +<code> +m / purpose' / coin_type' / identity' / 0' through 2147483647' +</code> + +These (hardened) keypairs are ephemeral payment codes. + +Apostrophe in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set to 47' (or 0x8000002F) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification. + +===Coin type=== + +The coin type field is identical to the same field in BIP44 + +Hardened derivation is used at this level. + +===Identity=== + +The identity derivation level produces an extended public key and its associated extended private key. + +When the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a "payment code." + +This derivation level is equivalent to the Account level in BIP-44. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs. + +For example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0'). + +The second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths. + +Incoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction. + +Hardened derivation is used at this level. + +Except where noted, all keys derived from a payment code use the public derivation method. + +==Standard Payment Codes (v1)== + +===Representation=== + +====Binary Serialization==== + +A payment code contains the following elements: + +* Byte 0: version. required value: 0x01 +* Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification +** Bit 0: Bitmessage notification +** Bits 1-7: reserved +* Byte 2: sign. required value: 0x02 or 0x03 +* Bytes 3 - 34: x value, must be a member of the secp256k1 group +* Bytes 35 - 66: chain code +* Bytes 67 - 79: reserved for future expansion, zero-filled unless otherwise noted + +====Base58 Serialization==== + +When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form. + +* The version byte is: 0x47 (produces a "P" as the first character of the serialized form) +* The payload is the binary serialization of the payment code + +===Protocol=== + +In the following examples, Alice and Bob are identities with a corresponding payment codes. Alice initiates a Bitcoin transaction, and Bob is the recipient of the transaction. + +It is assumed that Alice can easily obtain Bob's payment code via a suitable method outside the scope of the payment code protocol. + +====Definitions==== + +* Payment code: an extended public key and associated metadata which is associated with a particular identity/account +* Notification address: the P2PKH address associated with the 0<sup>th</sup> public key derived from a payment code +* Notification transaction: a transaction which sends an output to a notification address which includes an embedded payment code + +====Notification Transaction==== + +Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure: + +# Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction) +## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address +# Alice derives a unique shared secret using ECDH: +## Alice selects the private key corresponding to the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>a</pre> +## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre> +## Alice calculates a secret point: <pre>S = aB</pre> +## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre> +### "x" is the x value of the secret point +### "o" is the outpoint being spent by the first pubkey-exposing input of the transaction. +# Alice serializes her payment code in binary form. +# Alice renders her payment code (P) unreadable to anyone except Bob: +## Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre> +## Replace the chain code with c': <pre>c' = c XOR (last 32 bytes of s)</pre> +# Alice adds an OP_RETURN output to her transaction which consists of P. +<img src="bip-0047/reusable_payment_codes-01.png" /> + +# Bob watches for any transactions which create an output at his notification address. +# When a transaction is received, the client examines it to determine if it contains a standard OP_RETURN output with an 80 byte payload (notification transactions). +# If the first byte of the payload in a notification transaction is 0x01: +## Bob selects the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>A, where A = aG</pre> +## Bob selects the private key associated with his notification address: <pre>b</pre> +## Bob calculates a secret point: <pre>S = bA</pre> +## Bob calculates the binding factor: <pre>s = HMAC-SHA512(x, o)</pre> +### "x" is the x value of the secret point +### "o" is the outpoint being spent by the first pubkey-exposing input of the transaction. +## Bob interprets the 80 byte payload as a payment code, except: +### Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre> +### Replace the chain code with c': <pre>c' = c XOR (last 32 bytes of s)</pre> +## If the updated x value is a member of the secp256k1 group, the payment code is valid. +## If the updated x value is not a member of the secp256k1 group, the payment code is ignored. + +Now that Bob's client has received Alice's payment code, it is possible for Alice to send payments (up to 2<sup>32</sup> payments) to Bob. + +Alice will never again need to send a notification transaction to Bob. + +Bitcoins received via notification transactions require special handling in order to avoid privacy leaks: + +# The value of outputs received to notification addresses MUST NOT be displayed to the user as part of their spendable balance. +# Outputs received to notification addresses MUST NOT be used as inputs for any transaction that involve ECDH calculations using any of the user's payment codes. +# Outputs received to notification addresses MAY be passed through a mixing service before being added to the user's spendable balance. +# Outputs received to notification addresses MAY be donated to miners using dust-b-gone or an equivalent procedure. + +=====Standard Notification Transaction Scripts===== + +Alice SHOULD use an input script in one of the following standard forms to expose a public key, and compliant applications SHOULD recognize all of these forms. + +* P2PK (pay to pubkey) +* P2PKH (pay to pubkey hash) +* Multisig (bare multisig, without P2SH) +* a script which spends any of the above script forms via P2SH (pay to script hash) + +Compatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions. + +====Sending==== + +# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows: +## Alice selects the 0th private key derived from her payment code: <pre>a</pre> +## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre> +### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob +## Alice calculates a secret point: <pre>S = aB</pre> +## Alice calculates a scalar shared secret using the x value of S: <pre>s = SHA256(Sx)</pre> +### If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again. +## Alice uses the scalar shared secret to calculate the ephemeral public key used to generate the P2PKH address for this transaction: <pre>B' = B + sG</pre> +<img src="bip-0047/reusable_payment_codes-04.png" /> +<img src="bip-0047/reusable_payment_codes-05.png" /> +# Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice. +## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. +## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre> +## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre> +<img src="bip-0047/reusable_payment_codes-02.png" /> +<img src="bip-0047/reusable_payment_codes-03.png" /> + +====Refunds==== + +Because Bob learns Alice's payment code as part of the process of receiving a payment, Bob has all the information he needs in order to send a refund to Alice. + +A refund transaction is identical to a payment transactions, with only the roles of the participants switches. + +Bob MUST send a notification transaction to Alice prior to the first time he sends funds to Alice, even if he has received transactions from her in the past. + +<img src="bip-0047/reusable_payment_codes-06.png" /> + +====Anonymous Payments==== + +If Alice does not want her payment to Bob to be associated with her identity, she generates an ephemeral payment code to use for the transaction. + +* Ephemeral payment codes are the hardened children of a payment code, starting from an index of zero. +* An ephemeral payment code SHOULD only be used for a single outgoing payment. +* The notification address of an ephemeral payment code MUST be monitored for notification transactions in order to detect incoming refund payments +* The correspondence between BIP44 accounts and ephemeral payment codes is 1:many + +====Cold Storage==== + +* Unlike traditional watching-only wallets, those associated with payment codes held in cold storage can not detect incoming payments immediately. +* When the watching-only wallet detects an incoming notification transaction, it packages the transaction in an implementation-specific format suitable for transfer to the offline device. +* The offline device recovers the payment code, then pre-generates a large number of relevant keypairs (example: 10000) in order to minimize the need for air gap round trips. +* The offline device then packages the relevant public keys in an implementation-specific format suitable for transfer to the online device. +* The online device can then watch for incoming payments using a suitable lookahead window. +* If the lookahead window reaches the end of the pre-generated public keys, the user must generate more keys on the offline device and transfer them to the online device. + +====Wallet Recovery==== + +Normal operation of a payment code-enabled wallet can be performed by an SPV client and does not require access to a complete copy of the blockchain. + +Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain. + +The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer. + +When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other. + +Previously-spendable funds will generally not be lost or become inaccessible after a recovery from a seed, but all information regarding previous outgoing payments will be lost. + +In order to recover received funds from a seed, the wallet must obtain every notification it has ever received to its notification address, including all spent transactions. It then re-establishes its lookahead window for each subchain by scanning every derived address sequentially until it locates a contiguous block of unused addresses of a user-specified length. + +The metadata which a wallet must store to properly process outgoing transactions consists of: + +# A list of every payment code to which the identity has sent a notification transaction. +## This list is lost if a wallet must be recovered from a seed. +## The recovered wallet MUST send notification transactions as if it was a newly-created wallet +# The index value corresponding to the next unused pubkey for each payment code on the previous list +## This value can be recovered by checking each ephemeral deposit address in sequence for transactions. +## Wallets MAY use a lookahead window capable of detecting gaps in the address sequence during this recovery operation. +# The index value of the next unused ephemeral payment code. +## Recovering all incoming funds associated with ephemeral payment codes with 100% certainty requires exhausting the entire 2<sup>32</sup> address space of potential ephemeral payment codes. +### In most cases, less than 100% certainty is acceptable as long as a fallback "deep scan" is available as an option to the user. +## The wallet checks the notification address for each ephemeral payment code for notification transactions in order to recover associated funds. +## Since most ephemeral payment codes will not receive a refund transaction wallets SHOULD use a large lookahead window for this recovery operation. +## The recovered value MUST be chosen as a number higher than any ephemeral payment code which has received a notification transaction. + +===Wallet Sharing=== + +Wallets using payment codes generally should not be shared across multiple devices, given the need to synchronize metadata between each instance. + +If wallets are shared between devices without a synchronization mechanism, undesirable address reuse can occur. + +Wallets may perform an OPTIONAL check for existing transactions to an ephemeral deposit addresses prior to sending a transaction by checking a local copy of the blockchain or querying a public blockchain explorer via Tor or equivalent. + +===Alternate Notification Methods=== + +In order to ensure that no funds will be lost in the event the recipient must recover their wallet from a seed, the sender MUST send a notification transaction the first time the sender interacts with a particular recipient. + +A recipient MAY choose to designate alternate notification methods which the sender may use in addition to a notification transaction. + +If the recipient specifies an alternate notification method, a compliant implementation MAY refrain from continually monitoring the notification address and SHOULD check the notification address periodically to detect payments sent by users who can not employ the alternate method. + +A recipient specifies their preference for alternate notification by setting the appropriate bits in the feature byte of their payment code. + +===Bitmessage Notification=== + +A recipient prefers to receive notifications via Bitmessage indiates this preference by: + +* Setting bit 0 of the features byte to 1 +* Setting byte 67 of the serialized payment code to the desired Bitmessage address version +* Setting byte 68 of the serialized payment code to the desired Bitmessage stream number + +The sender uses this information to construct a valid notification Bitmessage address: + +# Derive a Bitmessage signing key as: <pre>B = payment code / 0 / 0</pre> +# Initialize a counter at 1: <pre>n</pre> +# Derive a candidate encryption key as: <pre>B' = payment code / 0 / n</pre> +# If the combination of B and B` do not form a valid Bitmessage address, increment n by one and try again +# Use the address version, signing key, encryption key, and stream number to construct a Bitmessage address per the Bitmessage protocol + +The sender transmits their payment code in base58 form to the calculated Bitmessage address. + +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. + +==Reference== + +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[https://bitcoin.org/en/glossary/outpoint|Outpoint]] +* [[https://github.com/petertodd/dust-b-gone|dust-b-gone]] +* [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]] +* [[https://bitmessage.org/bitmessage.pdf|Bitmessage]] +* [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007812.html|Mailing list discussion]] diff --git a/bip-0047/reusable_payment_codes-01.png b/bip-0047/reusable_payment_codes-01.png Binary files differnew file mode 100644 index 0000000..30a003f --- /dev/null +++ b/bip-0047/reusable_payment_codes-01.png diff --git a/bip-0047/reusable_payment_codes-02.png b/bip-0047/reusable_payment_codes-02.png Binary files differnew file mode 100644 index 0000000..da81d63 --- /dev/null +++ b/bip-0047/reusable_payment_codes-02.png diff --git a/bip-0047/reusable_payment_codes-03.png b/bip-0047/reusable_payment_codes-03.png Binary files differnew file mode 100644 index 0000000..3087293 --- /dev/null +++ b/bip-0047/reusable_payment_codes-03.png diff --git a/bip-0047/reusable_payment_codes-04.png b/bip-0047/reusable_payment_codes-04.png Binary files differnew file mode 100644 index 0000000..9738ca2 --- /dev/null +++ b/bip-0047/reusable_payment_codes-04.png diff --git a/bip-0047/reusable_payment_codes-05.png b/bip-0047/reusable_payment_codes-05.png Binary files differnew file mode 100644 index 0000000..5e93559 --- /dev/null +++ b/bip-0047/reusable_payment_codes-05.png diff --git a/bip-0047/reusable_payment_codes-06.png b/bip-0047/reusable_payment_codes-06.png Binary files differnew file mode 100644 index 0000000..c5619da --- /dev/null +++ b/bip-0047/reusable_payment_codes-06.png diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 7bd88a6..28b20dd 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -1,8 +1,10 @@ +'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''' + <pre> 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> @@ -38,7 +40,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for with OP_CHECKSIG and OP_CHECKMULTISIG the empty byte array (the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for OP_CHECKSIG and OP_CHECKMULTISIG, an empty byte array (i.e., the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. # '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 02de20b..df995de 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -2,7 +2,7 @@ BIP: 65 Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd <pete@petertodd.org> - Status: Draft + Status: Accepted Type: Standards Track Created: 2014-10-01 </pre> @@ -16,11 +16,17 @@ some point in the future. ==Summary== -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 -as though a NOP was executed. +CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if +any of the following conditions are true, the script interpreter will terminate +with an error: + +* the stack is empty; or +* the top item on the stack is less than 0; or +* the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or +* the top stack item is greater than the transaction's nLockTime field; or +* the nSequence field of the txin is 0xffffffff; + +Otherwise, script execution will continue as if a NOP had been executed. The nLockTime field in a transaction prevents the transaction from being mined until either a certain block height, or block time, has been reached. By @@ -32,18 +38,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,14 +91,14 @@ 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==== -Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's +Services like GreenAddress store bitcoins with 2-of-2 multisig scriptPubKey's such that one keypair is controlled by the user, and the other keypair is controlled by the service. To spend funds the user uses locally installed wallet software that generates one of the required signatures, and then uses a @@ -121,14 +123,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 +170,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. @@ -199,6 +201,7 @@ transaction output ''can'' be spent. Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. + case OP_NOP2: { // CHECKLOCKTIMEVERIFY @@ -271,9 +274,29 @@ semantics and detailed rationale for those semantics. https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 -==Upgrade and Testing Plan== +==Deployment== + +We reuse the double-threshold IsSuperMajority() switchover mechanism used in +BIP66 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 < 4 blocks become +invalid, and all further blocks enforce the new rules. + +It should be noted that BIP9 involves permanently setting a high-order bit to +1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus +no bits in nVersion are permanently lost. + + +===SPV Clients=== -TBD +While SPV clients are (currently) unable to validate blocks in general, +trusting miners to do validation for them, they are able to validate block +headers and thus can validate a subset of the deployment rules. SPV clients +should reject nVersion < 4 blocks if 950 out of 1000 preceding blocks have +nVersion >= 4 to prevent false confirmations from the remaining 5% of +non-upgraded miners when the 95% threshold has been reached. ==Credits== @@ -287,7 +310,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-0066.mediawiki b/bip-0066.mediawiki index 41cbd8f..1235afd 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -2,7 +2,7 @@ BIP: 66 Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> - Status: Draft + Status: Final Type: Standards Track Created: 2015-01-10 </pre> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 9c4f3de..8be5c9b 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -4,8 +4,8 @@ Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft - Type: Standard - Created: 8 February 2015 + Type: Standards Track + Created: 2015-02-08 </pre> ==Abstract== diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index 8da92b8..55905af 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -1,7 +1,10 @@ <pre> BIP: 68 - Title: Consensus-enforced transaction replacement signalled via sequence numbers + Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach <mark@friedenbach.org> + BtcDrak <btcdrak@gmail.com> + Nicolas Dorier <nicolas.dorier@gmail.com> + kinoshitajona <kinoshitajona@gmail.com> Status: Draft Type: Standards Track Created: 2015-05-28 @@ -9,17 +12,44 @@ ==Abstract== -This BIP describes a modification to the consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding output, for the purpose of supporting consensus-enforced transaction replacement features. +This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. ==Motivation== -Bitcoin has sequence number fields for each input of a transaction. The original idea appears to have been that the highest sequence number should dominate and miners should prefer it over lower sequence numbers. This was never really implemented, and the half-implemented code seemed to be making this assumption that miners would honestly prefer the higher sequence numbers, even if the lower ones were much much more profitable. That turns out to be a dangerous assumption, and so most technical people have assumed that kind of sequence number mediated replacement was useless because there was no way to enforce "honest" behaviour, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behaviour on the part of miners. +Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly implemented, it assumes miners would prefer higher sequence numbers even if the lower ones were more profitable to mine. However, a miner acting on profit motives alone would break that assumption completely. The change described by this BIP repurposes the sequence number for new use cases without breaking existing functionality. It also leaves room for future expansion and other use cases. + +The transaction nLockTime is used to prevent the mining of a transaction until a certain date. nSequence will be repurposed to prevent mining of a transaction until a certain age of the spent output in blocks or timespan. This, among other uses, allows bi-directional payment channels as used in [https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Hashed Timelock Contracts (HTLCs)] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Bidirectional_Payment_Channels BIP112]. ==Specification== -The maximum sequence number can be included in any block, like normal. For transactions with an nVersion of 2 or greater, a sequence number of one less than the maximum can only be included in the next block after the input it is spending, rather than it being possible to be included in the same block. A sequence number one less than that can only be included two blocks later, and so on. Alternatively, a sequence number LOCKTIME_THRESHOLD (500,000,000) less than the maximum (0xffffffff - 500,000,000 = 0xe2329aff) can only be included in a block with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. A sequence number one less than that can only be included two seconds later, and so on. This behaviour is only enforced if the most significant bit of the sequence number field is set. +This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on. + +All references to median-time-past (MTP) are as defined by BIP113. + +If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances. + +If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time. + +The sequence number encoding is interpreted as follows: + +Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks. + +The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112). + +This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion. + +<img src=bip-0068/encoding.png></img> + +For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits. + +When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter. +The mining date of the output is equals to the median-time-past of the previous block which mined it. + +The block produced time is equal to the median-time-past of its previous block. -This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise: +When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter. + +This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise: <pre> enum { @@ -27,183 +57,171 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), LOCKTIME_VERIFY_SEQUENCE = (1 << 0), }; - const uint32_t SEQUENCE_THRESHOLD = (1 << 31); - - int64_t LockTime(const CTransaction &tx, - int flags, const CCoinsView* pCoinsView, - int nBlockHeight, int64_t nBlockTime) + /* Setting nSequence to this value for every input in a transaction + * disables nLockTime. */ + static const uint32_t SEQUENCE_FINAL = 0xffffffff; + + /* If this flag set, CTxIn::nSequence is NOT interpreted as a + * relative lock-time. Setting the most significant bit of a + * sequence number disabled 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; + + /* In order to use the same number of bits to encode roughly the + * same wall-clock duration, and because blocks are naturally + * limited to occur every 600s on average, the minimum granularity + * for time-based relative lock-time is fixed at 512 seconds. + * Converting from CTxIn::nSequence to seconds is performed by + * multiplying by 512 = 2^9, or equivalently shifting up by + * 9 bits. */ + static const int SEQUENCE_LOCKTIME_GRANULARITY = 9; + + int64_t LockTime(const CTransaction &tx, int flags, const std::vector<int>* prevHeights, const CBlockIndex& block) { - CCoins coins; - uint32_t nLockTime; - - bool fEnforceBIP68 = tx.nVersion >= 2 + assert(prevHeights == NULL || prevHeights->size() == tx.vin.size()); + int64_t nBlockTime = (flags & LOCKTIME_MEDIAN_TIME_PAST) + ? block.GetAncestor(std::max(block.nHeight-1, 0))->GetMedianTimePast() + : block.GetBlockTime(); + + bool fEnforceBIP68 = static_cast<uint32_t>(tx.nVersion) >= 2 && flags & LOCKTIME_VERIFY_SEQUENCE; - + // Will be set to the equivalent height- and time-based nLockTime // values that would be necessary to satisfy all relative lock- // time constraints given our view of block chain history. int nMinHeight = 0; int64_t nMinTime = 0; - // Will remain equal to true if all inputs are finalized (MAX_INT). + // Will remain equal to true if all inputs are finalized + // (CTxIn::SEQUENCE_FINAL). bool fFinalized = true; - - BOOST_FOREACH(const CTxIn& txin, tx.vin) { - // The relative lock-time is the inverted sequence number so - // as to preserve the semantics MAX_INT means an input is - // finalized (0 relative lock-time). - nLockTime = ~txin.nSequence; - - // ~MAX_INT is zero/false, meaning the input is final. - if (!nLockTime) + for (size_t txinIndex = 0; txinIndex < tx.vin.size(); txinIndex++) { + const CTxIn& txin = tx.vin[txinIndex]; + // Set a flag if we witness an input that isn't finalized. + if (txin.nSequence == CTxIn::SEQUENCE_FINAL) continue; else fFinalized = false; - // Sequence numbers equal to or above the SEQUENCE_THRESHOLD - // are not treated as relative lock-times, nor are they given - // any consensus-enforced meaning at this point. - if (nLockTime >= SEQUENCE_THRESHOLD) - continue; - // Do not enforce sequence numbers as a relative lock time - // unless we have been instructed to. + // unless we have been instructed to, and a view has been + // provided. if (!fEnforceBIP68) continue; - // Skip this input if it is not in the UTXO set. This should - // only ever happen in non-consensus code. - if (!pCoinsView->GetCoins(txin.prevout.hash, coins)) + // Sequence numbers with the most significant bit set are not + // treated as relative lock-times, nor are they given any + // consensus-enforced meaning at this point. + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) continue; - if (nLockTime < LOCKTIME_THRESHOLD) - // We subtract 1 from relative lock-times because of lock - // time of 0 has the semantics of "same block," so a lock- - // time of 1 should mean "next block," but nLockTime has - // the semantics of "last invalid block height." - nMinHeight = std::max(nMinHeight, coins.nHeight + (int)nLockTime - 1); - else + if (prevHeights == NULL) + continue; + + int nCoinHeight = (*prevHeights)[txinIndex]; + + if (txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG) { + + int64_t nCoinTime = block.GetAncestor(std::max(nCoinHeight-1, 0))->GetMedianTimePast(); + // Time-based relative lock-times are measured from the // smallest allowed timestamp of the block containing the // txout being spent, which is the median time past of the // block prior. - nMinTime = std::max(nMinTime, - pindexBestHeader->GetAncestor(coins.nHeight-1)->GetMedianTimePast() - - LOCKTIME_THRESHOLD + (int64_t)nLockTime); + nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) << CTxIn::SEQUENCE_LOCKTIME_GRANULARITY) - 1); + } else { + // We subtract 1 from relative lock-times because a lock- + // time of 0 has the semantics of "same block," so a lock- + // time of 1 should mean "next block," but nLockTime has + // the semantics of "last invalid block height." + nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_MASK) - 1); + } } - // If sequence numbers are MAX_INT / zero relative lock-time, the - // transaction is considered final and nLockTime constraints are - // not enforced. + // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the + // transaction is considered final and nLockTime constraints + // are not enforced. if (fFinalized) return 0; - + if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD) nMinHeight = std::max(nMinHeight, (int)tx.nLockTime); else nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime); - if (nMinHeight >= nBlockHeight) + if (nMinHeight >= block.nHeight) return nMinHeight; + if (nMinTime >= nBlockTime) return nMinTime; return 0; - } - - int64_t CheckLockTime(const CTransaction &tx, int flags) - { - AssertLockHeld(cs_main); - - // By convention a negative value for flags indicates that the - // current network-enforced consensus rules should be used. - flags = std::max(flags, 0); - - // pcoinsTip contains the UTXO set for chainActive.Tip() - const CCoinsView *pCoinsView = pcoinsTip; - - // CheckLockTime() uses chainActive.Height()+1 to evaluate - // nLockTime because when LockTime() is called within - // CBlock::AcceptBlock(), the height of the block *being* - // evaluated is what is used. Thus if we want to know if a - // transaction can be part of the *next* block, we need to call - // LockTime() with one more than chainActive.Height(). - const int nBlockHeight = chainActive.Height() + 1; - - // Timestamps on the other hand don't get any special treatment, - // because we can't know what timestamp the next block will have, - // and there aren't timestamp applications where it matters. - const int64_t nBlockTime = GetAdjustedTime(); - - return LockTime(tx, flags, pCoinsView, nBlockHeight, nBlockTime); - } -</pre> + }</pre> Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be updated as well, since the semantics of the return value has been inverted. -==Rationale== - -Counting down from the maximum makes sense, since nothing can be higher than the maximum and no transaction can be in a block before its parent transactions. This means that a higher sequence number can always be included earlier than a lower one (even if the time the original coins being spent was unknown when the transaction was authored). Because of this, even rational miners should go along with the scheme: Take the higher sequence number and collect the fees, or skip over it in the hopes that no one else takes a higher number before the next available lower number becomes spendable. And, of course, users are not constrained to make their sequence numbers go down only one at a time. So it's "take the most updated version, now, or gamble that no one in the next dozen blocks takes the most updated and that you manage to include the next to most when it finally becomes mineable." This is similar to how lock-time works. In fact, this scheme is precisely a per-input relative lock-time. - ==Example: Bidirectional payment channel== -A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1btc output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network. +A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1 BTC output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network. -Alice desires to send Bob a payment of 0.1btc. She does so by constructing a transaction spending the 1btc output and sending 0.1btc to Bob and 0.9btc back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1btc, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2btc, then 0.3btc to Bob with a relative lock-time of 29 days from creation of the channel. +Alice desires to send Bob a payment of 0.1 BTC. She does so by constructing a transaction spending the 1 BTC output and sending 0.1 BTC to Bob and 0.9 BTC back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1 BTC, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2 BTC, then 0.3 BTC to Bob with a relative lock-time of 29 days from creation of the channel. -Bob now desires to send Alice a refund of 0.25btc. He does so by constructing a transaction spending the 1btc output and sending 0.95btc (= 0.7btc + 0.25btc) to Alice and 0.05btc to himself. Since Bob will still have in his logs the transaction giving him 0.7btc 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures. +Bob now desires to send Alice a refund of 0.25 BTC. He does so by constructing a transaction spending the 1btc output and sending 0.95 BTC (= 0.7 BTC + 0.25 BTC) to Alice and 0.05 BTC to himself. Since Bob will still have in his logs the transaction giving him 0.7 BTC 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures. -Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by setting the relative lock-time to zero (nSequence = MAX_INT) and both parties signing. +Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by finalizing the input (nSequence = MAX_INT) and both parties signing. ==Implementation== -A reference implementation is provided in the following git repository: +A reference implementation is provided by the following pull request + +https://github.com/bitcoin/bitcoin/pull/6312 -https://github.com/maaku/bitcoin/tree/sequencenumbers +==Acknowledgments== -==Acknowledgements== +Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text. -Credit goes to Gregory Maxwell for providing a succinct and clear description of the behaviour of this change, which became the basis of this BIP text. +This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona. ==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, such as [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY. +BIP68 MUST be deployed together with BIP113. It is also recommended to deploy BIP112 at the same time. ==Compatibility== -The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP without requiring any special-case handling. +The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP. -There may be other uses for the sequence number field that are not commonplace or yet to be discoverd. To allow for other uses of the sequence number field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is set. This allows up to 31 bits of the sequence number field to be used for other purposes in applicaitons which don't simultaneously need a per-input relative lock-time. +As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset. -The most efficient way to calculate sequence number from relative lock-time is with bit-inversion: +Additionally, this BIP specifies only 16 bits to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive). This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future. -<pre> - // 0 <= nHeight < 500,000,000 blocks - nSequence = ~(nHeight); - nHeight = ~(nSequence); - - // 1 <= nTime < 1,647,483,648 seconds (52.2 years) - nSequence = ~(nTime - 1 + LOCKTIME_THRESHOLD); - nTime = ~(nSequence) - LOCKTIME_THRESHOLD + 1; -</pre> - -In languages which do not support bit inversion, the calculation can be accomplished with integer arithmetic instead: +The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts: <pre> - nSequence = 0xffffffff - nHeight; - nHeight = 0xffffffff - nSequence; + // 0 <= nHeight < 65,535 blocks (1.25 years) + nSequence = nHeight; + nHeight = nSequence & 0x0000ffff; - nSequence = 0xffffffff - nTime + 1 - LOCKTIME_THRESHOLD; - nTime = 0xffffffff - nSequence + 1 - LOCKTIME_THRESHOLD; + // 0 <= nTime < 33,554,431 seconds (1.06 years) + nSequence = (1 << 22) | (nTime >> 9); + nTime = (nSequence & 0x0000ffff) << 9; </pre> ==References== Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html -BIP 34: Block v2, Height in Coinbase, https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki +BIP112: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki + +BIP113: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki -BIP 65: OP_CHECKLOCKTIMEVERIFY, https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki +Hashed Timelock Contrats (HTLCs): https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf -BIP 66: Strict DER signatures, https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki diff --git a/bip-0068/encoding.png b/bip-0068/encoding.png Binary files differnew file mode 100644 index 0000000..cd7649e --- /dev/null +++ b/bip-0068/encoding.png diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e868df3..e23ff04 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -33,7 +33,7 @@ Many wallets will place spending outputs first and change outputs second, leakin Such information should remain private not only for the benefit of consumers, but in higher order financial systems must be kept secret to prevent fraud. A researcher recently demonstrated this principle when he detected that Bitstamp leaked information when creating exchange transactions, enabling potential espionage among traders. [1] -One way to address these privacy weaknesses is by randomly ordering inputs and outputs. [2] +One way to address these privacy weaknesses is by randomizing the order of inputs and outputs. [2] After all, the order of inputs and outputs does not impact the function of the transaction they belong to, making random sorting viable. Unfortunately, it can be difficult to prove that this sorting process is genuinely randomly sorted based on code or run-time analysis, especially if the software is closed source. A malicious software developer can abuse the ordering of inputs and outputs as a side channel of leaking information. diff --git a/bip-0070/paymentrequest.proto b/bip-0070/paymentrequest.proto index 6680810..717946e 100644 --- a/bip-0070/paymentrequest.proto +++ b/bip-0070/paymentrequest.proto @@ -3,7 +3,7 @@ // // Use fields 1000+ for extensions; // to avoid conflicts, register extensions via pull-req at -// https://github.com/bitcoin/bips/bip-0070/extensions.mediawiki +// https://github.com/bitcoin/bips/blob/master/bip-0070/extensions.mediawiki // package payments; 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-0101.mediawiki b/bip-0101.mediawiki index 9a78255..a76db0f 100644 --- a/bip-0101.mediawiki +++ b/bip-0101.mediawiki @@ -44,7 +44,7 @@ Expressed in pseudo-code, using integer math, assuming that block_timestamp is a Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC. -Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. +Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block. diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki new file mode 100644 index 0000000..b75f798 --- /dev/null +++ b/bip-0102.mediawiki @@ -0,0 +1,42 @@ +<pre> + BIP: 102 + Title: Block size increase to 2MB + Author: Jeff Garzik <jgarzik@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-06-23 +</pre> + +==Abstract== + +Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB. + +==Motivation== + +# Enable network growth. +# Continue current economic policy of low fee pressure on average. +# Exercise network upgrade procedure. + +==Specification== + +# Maximum block size permitted to be valid is 1MB. +# 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== + +Older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network. + +==Discussion== + +In the short term, an increase is needed to continue to facilitate +network growth, and buy time for more comprehensive solutions to be +developed. This continues the current economic policies with regards to +fees, matching market expectations and preventing market disruption. + +In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management. + +==Implementation== + +https://github.com/jgarzik/bitcoin/tree/2015_2mb_blocksize + diff --git a/bip-0103.mediawiki b/bip-0103.mediawiki new file mode 100644 index 0000000..39e8a3f --- /dev/null +++ b/bip-0103.mediawiki @@ -0,0 +1,72 @@ +<pre> + BIP: 103 + Title: Block size following technological growth + Author: Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-07-21 +</pre> + +==Abstract== + +This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. + +==Motivation== + +Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availability on the market, there is no reason why Bitcoin's fundamental transaction rate cannot improve proportionally. + +Currently, there is a consensus rule in place that limits the size of blocks to 1000000 bytes. Changing this requires a hard-forking change: one that will require every full node in the network to implement the new rules. The new chain created by those changed nodes will be rejected by old nodes, so this would effectively be a request to the ecosystem to migrate to a new and incompatible network. Doing this while controversy exists is dangerous to the network and the ecosystem. + +Furthermore, the effective space available is always constrained by a hash rate majority and its ability to process transactions. No hard forking change that relaxes the block size limit can be guaranteed to provide enough space for every possible demand - or even any particular demand - unless strong centralization of the mining ecosystem is expected. Because of that, the development of a fee market and the evolution towards an ecosystem that is able to cope with block space competition should be considered healthy. This does not mean the block size or its limitation needs to be constant forever. However, the purpose of such a change should be evolution with technological growth, and not kicking the can down the road because of a fear of change in economics. + +Bitcoin's advantage over other systems does not lie in scalability. Well-designed centralized systems can trivially compete with Bitcoin's on-chain transactions in terms of cost, speed, reliability, convenience, and scale. Its power lies in transparency, lack of need for trust in network peers, miners, and those who influence or control the system. Wanting to increase the scale of the system is in conflict with all of those. Attempting to buy time with a fast increase is not wanting to face that reality, and treating the system as something whose scale trumps all other concerns. A long term scalability plan should aim on decreasing the need for trust required in off-chain systems, rather than increasing the need for trust in Bitcoin. + +In summary, hard forks are extremely powerful, and we need to use them very responsibly as a community. They have the ability to fundamentally change the technology or economics of the system, and can be used to disadvantage those who expected certain rules to be immutable. They should be restricted to uncontroversial changes, or risk eroding the expectation of low trust needed in the system in the longer term. As the block size debate has been controversial so far - for good or bad reasons - this BIP aims for gradual change and its effects start far enough in the future. + +==Specification== + +The block size limitation is replaced by the function below, applied to the median of the timestamps of the previous 11 blocks, or in code terms: the block size limit for pindexBlock is GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast()). + +The sigop limit scales proportionally. + +It implements a series of block size steps, one every ~97 days, between January 2017 and July 2063, each increasing the maximum block size by 4.4%. This allows an overall growth of 17.7% per year. + +<pre> +uint32_t GetMaxBlockSize(int64_t nMedianTimePast) { + // The first step is on January 1st 2017. + if (nMedianTimePast < 1483246800) { + return 1000000; + } + // After that, one step happens every 2^23 seconds. + int64_t step = (nMedianTimePast - 1483246800) >> 23; + // Don't do more than 11 doublings for now. + step = std::min<int64_t>(step, 175); + // Every step is a 2^(1/16) factor. + static const uint32_t bases[16] = { + // bases[i] == round(1000000 * pow(2.0, (i + 1) / 16.0)) + 1044274, 1090508, 1138789, 1189207, + 1241858, 1296840, 1354256, 1414214, + 1476826, 1542211, 1610490, 1681793, + 1756252, 1834008, 1915207, 2000000 + }; + return bases[step & 15] << (step / 16); +} +</pre> + +==Rationale== + +Waiting 1.5 years before the hard fork takes place should provide ample time to minimize the risk of a hard fork, if found uncontroversial. + +Because every increase (including the first) is only 4.4%, risk from large market or technological changes is minimized. + +The growth rate of 17.7% growth per year is consistent with the average growth rate of bandwidth the last years, which seems to be the bottleneck. If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit. + +Using a time-based check is very simple to implement, needs little context, is efficient, and is trivially reviewable. Using the "median time past" guarantees monotonic behaviour, as this median is required to be increasing, according to Bitcoin's existing consensus rules. Using the "median time past" of the block before means we know in advance what the limit of each block will be, without depending on the actual block's timestamp. + +==Compatibility== + +This is a hard forking change, thus breaks compatbility with old fully-validating node. It should not be deployed without widespread consensus. + +==Acknowledgements== + +Thanks to Gregory Maxwell and Wladimir J. van der Laan for their suggestions. diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki new file mode 100644 index 0000000..c4f0a09 --- /dev/null +++ b/bip-0105.mediawiki @@ -0,0 +1,107 @@ +<pre> + BIP: 105 + Title: Consensus based block size retargeting algorithm + Author: BtcDrak <btcdrak@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-08-21 +</pre> + +==Abstract== + +A method of altering the maximum allowed block size of the Bitcoin protocol +using a consensus based approach. + +==Motivation== + +There is a belief that Bitcoin cannot easily respond to raising the +blocksize limit if popularity was to suddenly increase due to a mass adoption +curve, because co-ordinating a hard fork takes considerable time, and being +unable to respond in a timely manner would irreparably harm the credibility of +bitcoin. + +Additionally, predetermined block size increases are problematic because they +attempt to predict the future, and if too large could have unintended +consequences like damaging the possibility for a fee market to develop +as block subsidy decreases substantially over the next 9 years; introducing +or exacerbating mining attack vectors; or somehow affect the network in unknown +or unpredicted ways. Since fixed changes are hard to deploy, the damage could be +extensive. + +Dynamic block size adjustments also suffer from the potential to be gamed by the +larger hash power. + +Free voting as suggested by BIP100 allows miners to sell their votes out of band +at no risk, and enable the sponsor the ability to manipulate the blocksize. +It also provides a cost free method or the larger pools to vote in ways to +manipulate the blocksize such to disadvantage or attack smaller pools. + + +==Rationale== + +By introducing a cost to increase the block size ensures the mining community +will collude to increase it only when there is a clear necessity, and reduce it +when it is unnecessary. Larger miners cannot force their wishes so easily +because not only will they have to pay extra a difficulty target, then can be +downvoted at no cost by the objecting hash power. + +Using difficulty as a penalty is better than a fixed cost in bitcoins because it +is less predictable. + +In order to prevent miners having complete control over blocksize, an upper +limit is required at protocol level. This feature ensures full nodes retain +control over consensus, remembering full nodes are the mechanism to keep miners +honest. + + +==Specification== + +The initial block size limit shall be 1MB. + +Each time a miner creates a block, they may vote to increase or decrease the +blocksize by a maximum of 10% of the current block size limit. These votes will +be used to recalculate the new block size limit every 2016 blocks. + +Votes are cast using the block's coinbase transaction scriptSig. + +As per BIP34, the coinbase transaction scriptSig starts with a push of the block +height. The next push is a little-endian number representing the preferred block +size in bytes. For example, 0x4c(OP_PUSHDATA1) 0x03(size of constant) 0x80 0x84 0x1e(2MB) +or 0x4c(OP_PUSHDATA1) 0x04(size of constant) 0x80 0x96 0x98 0x00(10MB). + +If a miner votes for an increase, the block hash must meet a difficulty target +which is proportionally larger than the standard difficulty target based on the +percentage increase they voted for. + +Votes proposing decreasing the block size limit do not need to meet a higher +difficulty target. + +Miners can vote for no change by voting for the current block size. + +For blocks to be valid the blockhash must meet the required difficulty target +for the vote otherwise the block is invalid and will be rejected. + +Every 2016 blocks, the block size limit will be recalculated by the median of +all votes in the last 2016 blocks. This will redefine the block size limit for +the next 2016 blocks. + +Blocks that are larger than the calculated base block size limit are invalid and +will be rejected. + +The base block size limit may not reduce below 1MB or increase above 8MB (the exact +number for the upper limit requires further discussion). + + +==Acknowledgements== + +This proposal is based on ideas and concepts derived from the writings of +Meni Rosenfeld and Gregory Maxwell. + + +==References== + +[[bip-0034.mediawiki|BIP34]] + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki new file mode 100644 index 0000000..e9018fa --- /dev/null +++ b/bip-0106.mediawiki @@ -0,0 +1,80 @@ +<pre> + BIP: 106 + Title: Dynamically Controlled Bitcoin Block Size Max Cap + Author: Upal Chakraborty <bitcoin@upalc.com> + Status: Draft + Type: Standards Track + Created: 2015-08-24 +</pre> + +==Abstract== + +This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... + +i. Depending only on previous block size calculation. + +ii. Depending on previous block size calculation and previous Tx fee collected by miners. + +==Motivation== + +With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... + +https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= + +==Specification== + +===Proposal 1 : Depending only on previous block size calculation=== + + If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize + Double MaxBlockSize + Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize + Half MaxBlockSize + Else + Keep the same MaxBlockSize + +===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== + + TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period + TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) + + TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period + TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) + + If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) ) + MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty + Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) ) + MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty + Else + Keep the same MaxBlockSize + +==Rationale== + +These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. + +===Proposal 1 : Depending only on previous block size calculation=== + +This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. + +===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== + +This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. + +==Compatibility== + +This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks. + +==Other solutions considered== + +[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik + +[https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld + +[https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase maximum block size] - by Gavin Andresen + +[https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following technological growth] - by Pieter Wuille + +[https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus Dryja + +==Deployment== + +If consensus is achieved, deployment can be made at a future block number at which difficulty will change. diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki new file mode 100644 index 0000000..88a2c99 --- /dev/null +++ b/bip-0107.mediawiki @@ -0,0 +1,83 @@ +<pre> + BIP: 107 + Title: Dynamic limit on the block size + Author: Dr Washington Y. Sanchez <washington.sanchez@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-09-11 +</pre> + +==Abstract== + +This BIP proposes a dynamic limit to the block size based on transaction volume. + +==Motivation== + +Over the next few years, large infrastructure investments will be made into: + +# Improving global network connectivity +# Improving block propogation across the Bitcoin network +# Layer 2 services and networks for off-chain transactions +# General efficiency improvements to transactions and the blockchain + +* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may agument the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. +* In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. +* These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. + +==Specification== + +* Increases in the block size will occur in 2 phases +* '''Phase 1''' +** The block size will be increased similar to [[https://twitter.com/adam3us/status/636410827969421312|Adam Back's proposal]], as a safe runway prior to switching to Phase 2, while network and protocol infrastructure is improved +** The schedule: +*** ''2016-2017:'' 2 MB +*** ''2018-2019:'' 4 MB +*** ''2020:'' 6 MB +* '''Phase 2''' +** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume +** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur +*** This calculates to a theoretical maximum of 13 increases per year +** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% +** The maximum block size can only ever be increased, not decreased +* The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases +** Transactions without fees can continue to be submitted and relayed on the network as per normal +** <code>limitfreerelay</code> also helps counter attempts to trigger a block size increase by 'penny-flooding' + +For example: +* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size wil be 6 MB +* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. +* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. + +==Rationale== + +* '''Phase 1''' +** This runway has a schedule for conservative increases to the block size in order to relieve transaction volume pressure while allowing network and protocol infrastructure improvements to be made, as well as layer 2 services to emerge +* '''Phase 2''' +** Why 60% full blocks? +*** IF blocks are 60% full, they count as a ''vote'' towards increasing the block size +*** If this parameter is too low, the trigger sensitivity may be too high and vulnerable to spam attacks or miner collusion +*** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place +*** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size +**** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered +*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distrance from the limit. +** Why 3025 blocks? +*** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 +*** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: +***# Demonstrate a market-driven secular elevation in the transaction volume +***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions +*** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand +** Why 10% increase in the block size? +*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunitites to increase the block size per year +*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community + +==Deployment== +''From BIP66:'' +We reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = ''n''. The new rules are in effect for every block (at height H) with nVersion = ''n'' and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = ''n''. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = ''n'', nVersion = ''n-1'' blocks become invalid, and all further blocks enforce the new rules. + +==Acknowledgements== + +Thanks to Austin Hill, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments. + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki new file mode 100644 index 0000000..d3bd630 --- /dev/null +++ b/bip-0111.mediawiki @@ -0,0 +1,85 @@ +<pre> + BIP: 111 + Title: NODE_BLOOM service bit + Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-08-20 +</pre> + +== Abstract == + +This BIP extends BIP 37, Connection Bloom filtering, by defining a +service bit to allow peers to advertise that they support bloom filters +explicitly. It also bumps the protocol version to allow peers to +identify old nodes which allow bloom filtering of the connection despite +lacking the new service bit. + + +== Motivation == + +BIP 37 did not specify a service bit for the bloom filter service, thus +implicitly assuming that all nodes that serve peers data support it. +However, the connection filtering algorithm proposed in BIP 37, and +implemented in several clients today, has been shown to provide little +to no privacy<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.</ref>. +Thus, allowing node operators to disable connection bloom filtering is a +much-needed feature. + + +== Specification == + +The following protocol bit is added: + +<pre> + NODE_BLOOM = (1 << 2) +</pre> + +Nodes which support bloom filters should set that protocol bit. +Otherwise it should remain unset. In addition the protocol version is +increased from 70002 to 70011 in the reference implementation. It is +often the case that nodes which have a protocol version smaller than +70011, but larger than 70000 support bloom filtered connections without +the NODE_BLOOM bit set, however clients which require bloom filtered +connections should avoid making this assumption. + +NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise +NODE_BLOOM but not NODE_NETWORK (though there is little reason to do +so now, some proposals may make this more useful in the future) + +If a node does not support bloom filters but receives a "filterload", +"filteradd", or "filterclear" message from a peer the node should +disconnect that peer immediately. For backwards compatibility, in +initial implementations, nodes may choose to only disconnect nodes which +have the new protocol version set and attempt to send a filter command. + +While outside the scope of this BIP it is suggested that DNS seeds and +other peer discovery mechanisms support the ability to specify the +services required; current implementations simply check only that +NODE_NETWORK is set. + + +== Design rational == + +A service bit was chosen as applying a bloom filter is a service. + +The increase in protocol version is for backwards compatibility. In +initial implementations, old nodes which are not yet aware of NODE_BLOOM +and use a protocol version < 70011 may still send filter messages to a +node without NODE_BLOOM. This feature may be removed after there are +sufficient NODE_BLOOM nodes available and SPV clients have upgraded, +allowing node operators to fully close the bloom-related DoS vectors. + + +== Reference Implementation == + +https://github.com/bitcoin/bitcoin/pull/6579 + + +== Copyright == + +This document is placed in the public domain. + + +== References == +<references> diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki new file mode 100644 index 0000000..643c617 --- /dev/null +++ b/bip-0112.mediawiki @@ -0,0 +1,399 @@ +<pre> + BIP: 112 + Title: CHECKSEQUENCEVERIFY + Authors: BtcDrak <btcdrak@gmail.com> + Mark Friedenbach <mark@friedenbach.org> + Eric Lombrozo <elombrozo@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-08-10 +</pre> + +==Abstract== + +This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin +scripting system that in combination with BIP 68 allows execution +pathways of a script to be restricted based on the age of the output +being spent. + + +==Summary== + +CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. +When executed, if any of the following conditions are true, the script interpreter will terminate with an error: + +* the stack is empty; or +* 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; or +** 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 will continue as if a NOP had been executed. + +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== + +BIP 68 repurposes the transaction nSequence field meaning by giving +sequence numbers new consensus-enforced semantics as a relative +lock-time. However, there is no way to build Bitcoin scripts to make +decisions based on this field. + +By making the nSequence field accessible to script, it becomes +possible to construct code pathways that only become accessible some +minimum time after proof-of-publication. This enables a wide variety +of applications in phased protocols such as escrow, payment channels, +or bidirectional pegs. + + +===Contracts With Expiration Deadlines=== + +====Escrow with Timeout==== + +An escrow that times out automatically 30 days after being funded can be +established in the following way. Alice, Bob and Escrow create a 2-of-3 +address with the following redeemscript. + + IF + 2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY + ELSE + "30d" CHECKSEQUENCEVERIFY DROP + <Alice's pubkey> CHECKSIGVERIFY + ENDIF + +At any time funds can be spent using signatures from any two of Alice, +Bob or the Escrow. + +After 30 days Alice can sign alone. + +The clock does not start ticking until the payment to the escrow address +confirms. + + +===Retroactive Invalidation=== + +In many instances, we would like to create contracts that can be revoked in case +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 do. + +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 +output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging +another party from broadcasting the transaction in the first place. If the invalidation +condition does not occur before the timeout, the delayed branch becomes spendable, +honoring the original contract. + +Some more specific applications of this idea: + +====Hash Time-Locked Contracts==== + +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==== + +Scriptable relative locktime provides a predictable amount of time to respond in +the event a counterparty broadcasts a revoked transaction: Absolute locktime +necessitates closing the channel and reopen it when getting close to the timeout, +whereas with relative locktime, the clock starts ticking the moment the +transactions confirms in a block. It also provides a means to know exactly how +long to wait (in number of blocks) before funds can be pulled out of the channel +in the event of a noncooperative counterparty. + + +====Lightning Network==== + +The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops. + +These channels are based on an anchor transaction that requires a 2-of-2 +multisig from Alice and Bob, and a series of revocable commitment +transactions that spend the anchor transaction. The commitment +transaction splits the funds from the anchor between Alice and Bob and +the latest commitment transaction may be published by either party at +any time, finalising the channel. + +Ideally then, a revoked commitment transaction would never be able to +be successfully spent; and the latest commitment transaction would be +able to be spent very quickly. + +To allow a commitment transaction to be effectively revoked, Alice +and Bob have slightly different versions of the latest commitment +transaction. In Alice's version, any outputs in the commitment +transaction that pay Alice also include a forced delay, and an +alternative branch that allows Bob to spend the output if he knows that +transaction's revocation code. In Bob's version, payments to Bob are +similarly encumbered. When Alice and Bob negotiate new balances and +new commitment transactions, they also reveal the old revocation code, +thus committing to not relaying the old transaction. + +A simple output, paying to Alice might then look like: + + HASH160 <revokehash> EQUAL + IF + <Bob key hash> + ELSE + "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 +relays a revoked transaction, that Bob has 24 hours to claim the funds. + +With CHECKLOCKTIMEVERIFY, this would look like: + + HASH160 <revokehash> EQUAL + IF + <Bob key hash> + ELSE + "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. + +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. + +Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated, +since in principle they may pay either Alice or Bob, depending on whether +Alice discovers a secret R, or a timeout is reached, but the same principle +applies -- the branch paying Alice in Alice's commitment transaction gets a +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 <R-HASH> EQUAL + IF + "24h" CHECKSEQUENCEVERIFY + 2DROP + <Alice key hash> + ELSE + <Commit-Revocation-Hash> EQUAL + NOTIF + "24h" CHECKLOCKTIMEVERIFY DROP + ENDIF + <Bob key hash> + ENDIF + CHECKSIG + +and correspondingly in Bob's commitment transaction: + + HASH160 DUP <R-HASH> EQUAL + SWAP <Commit-Revocation-Hash> EQUAL ADD + IF + <Alice key hash> + ELSE + "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 +the timeout is complete and Alice has had time to reveal the revocation +secret. + +See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper. + + +====2-Way Pegged Sidechains==== + +The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this BIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof: + + IF + lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY + ELSE + withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL + ENDIF + + +==Specification== + +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; + + 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; + } + + 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; + } + + +==Reference Implementation== + +A reference implementation is provided by the following pull request: + +https://github.com/bitcoin/bitcoin/pull/6564 + + +==Deployment== + +This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB. + +It is recommended to deploy BIP68 and BIP113 at the same time as this BIP. + + +==Credits== + +Mark Friedenbach invented the application of sequence numbers to +achieve relative lock-time, and wrote the reference implementation of +CHECKSEQUENCEVERIFY. + +The reference implementation and this BIP was based heavily on work +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 use cases. + + +==References== + +[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 + +[https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median past block time for time-lock constraints + +[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes] + +[http://lightning.network/lightning-network-paper.pdf Lightning Network] + +[https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] + +[http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day] + +[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations] + +[https://gist.github.com/sipa/bf69659f43e763540550 Version bits] + +[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels] + + +==Copyright== + +This document is placed in the public domain. + + diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki new file mode 100644 index 0000000..190fb4c --- /dev/null +++ b/bip-0113.mediawiki @@ -0,0 +1,137 @@ +<pre> + BIP: 113 + Title: Median time-past as endpoint for lock-time calculations + Author: Thomas Kerin <me@thomaskerin.io> + Mark Friedenbach <mark@friedenbach.org> + Status: Draft + Type: Standards Track + Created: 2015-08-10 +</pre> + + +==Abstract== + +This BIP is a proposal to redefine the semantics used in determining a +time-locked transaction's eligibility for inclusion in a block. The +median of the last 11 blocks is used instead of the block's timestamp, +ensuring that it increases monotonically with each block. + + +==Motivation== + +At present, transactions are excluded from inclusion in a block if the +present time or block height is less than or equal to that specified +in the locktime. Since the consensus rules do not mandate strict +ordering of block timestamps, this has the unfortunate outcome of +creating a perverse incentive for miners to lie about the time of +their blocks in order to collect more fees by including transactions +that by wall clock determination have not yet matured. + +This BIP proposes comparing the locktime against the median of the +past 11 block's timestamps, rather than the timestamp of the block +including the transaction. Existing consensus rules guarantee this +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). + + +==Specification== + +The values for transaction locktime remain unchanged. The difference is only in +the calculation determining whether a transaction can be included. Instead of +an unreliable timestamp, the following function is used to determine the current +block time for the purpose of checking lock-time constraints: + + enum { nMedianTimeSpan=11 }; + + int64_t GetMedianTimePast(const CBlockIndex* pindex) + { + int64_t pmedian[nMedianTimeSpan]; + int64_t* pbegin = &pmedian[nMedianTimeSpan]; + int64_t* pend = &pmedian[nMedianTimeSpan]; + for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev) + *(--pbegin) = pindex->GetBlockTime(); + std::sort(pbegin, pend); + 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. + +A reference implementation of this proposal is provided by the +following pull request: + +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. + +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. + + +==Acknowledgements== + +Mark Friedenbach for designing and authoring the reference +implementation of this BIP. + +Thanks go to Gregory Maxwell who came up with the original idea, +in #bitcoin-wizards on 2013-07-16. + +Thomas Kerin authored this BIP document. + + +==Compatibility== + +Transactions generated using time-based lock-time will take +approximately an hour longer to confirm than would be expected under +the old rules. This is not known to introduce any compatibility +concerns with existing protocols. + + +==References== +[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] + +[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers] + +[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY] + +[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations] + +[https://gist.github.com/sipa/bf69659f43e763540550 Version bits] + + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki new file mode 100644 index 0000000..1602c65 --- /dev/null +++ b/bip-0120.mediawiki @@ -0,0 +1,152 @@ +<pre> + BIP: 120 + Title: Proof of Payment + Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Status: Draft + Type: Standards Track + Created: 2015-07-28 +</pre> + +== Abstract == + +This BIP describes a system called Proof of Payment, PoP. It is used to prove that a wallet has the credentials that were used to sign a previously generated transaction. Or simply put, it lets you prove that you have made a payment. + +== Motivation == + +There are several scenarios in which it would be useful to prove that you have paid for something. For example: + +* A pre-paid hotel room where your PoP functions as a key to the door. +* An online video rental service where you pay for a video and watch it on any device. +* An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. +* Log in to a pay site using a PoP. +* A parking lot you pay for monthly and the car authenticates itself using PoP. +* A lottery where all participants pay to the same address, and the winner is selected among the transactions to that address. You exchange the prize for a PoP for the winning transaction. + +With Proof of Payment, these use cases can be achieved without any personal information (user name, password, e-mail address, etc) being involved. + +== Rationale == + +Desirable properties: + +# A PoP should be generated on demand. +# It should only be usable once to avoid issues due to theft. +# It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). +# It should prove that you have enough credentials to unlock all the inputs of the proven transaction. +# It should be easy to implement by wallets and servers to ease adoption. + +Current methods of proving a payment: + +* In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5. +* Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so. + +If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not necessarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address. + +== Specification == + +=== Data structure === + +A proof of payment for a transaction T, here called PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and in the same order as in T, but with each sequence number set to 0. There is exactly one output, here called the pop output, with value 0. The pop output must have the following format: + + OP_RETURN <version> <txid> <nonce> + +{| +! Field !! Size [B] !! Description +|- +| <version> || 2 || Version, little endian, currently 0x01 0x00 +|- +| <txid> || 32 || The transaction to prove +|- +| <nonce> || 6 || Random data +|} + +The lock_time of the PoP must be set to 499999999 to prevent the PoP from being included in a block, should it appear on the bitcoin p2p network. This is also the reason for setting the sequence numbers to 0, since sequence number of ffffffff would make lock_time ineffective. This specification demands that all input sequence numbers are 0, not just one of them, which would be sufficient to make lock_time effective. This is for simplicity reasons. + +An illustration of the PoP data structure and its original payment is shown below. + +<pre> + T + +------------------------------------------------+ + |inputs | outputs | + | Value,Sequence | Value,Script | + +------------------------------------------------+ + |input0 1,ffffffff | 0,pay to A | + |input1 3,ffffffff | 2,OP_RETURN <some data> | + |input2 4,ffffffff | 1,pay to B | + | | 4,pay to C | + +------------------------------------------------+ + + PoP(T) + +-------------------------------------------------------------+ + | inputs | outputs | + | Value,Sequence | Value,Script | + +-------------------------------------------------------------+ + |input0 1,00000000 | 0,OP_RETURN <version> <txid> <nonce> | + |input1 3,00000000 | | + |input2 4,00000000 | | + +-------------------------------------------------------------+ + | lock_time=499999999 | + +-------------------------------------------------------------+ +</pre> + +The PoP is signed using the same signing process that is used for bitcoin transactions. + +The purpose of the nonce is to make it harder to use a stolen PoP; Once the PoP has reached the server, that PoP is useless since the server will generate a new nonce for every PoP request. + +=== Process === + +# A proof of payment request is sent from the server to the wallet. The PoP request contains: +## a random nonce +## a destination where to send the PoP, for example a https URL +## data hinting the wallet which transaction to create a proof for. For example: +##* txid, if known by the server +##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment) +##* amount, label, message or other information from a BIP0021 URI +# The wallet identifies a transaction T, if possible. Otherwise it asks the user to select among the ones that match the hints in 1.iii. +# The wallet creates an unsigned PoP (UPoP) for T, and asks the user to sign it. +# The user confirms +# The UPoP(T) is signed by the wallet, creating PoP(T). +# The PoP is sent to the destination in 1.ii. +# The server receiving the PoP validates it and responds with “valid” or “invalid”. +# The wallet displays the response in some way to the user. + +'''Remarks:''' + +* The method of transferring the PoP request at step 1 is not specified here. Instead that is specified in separate specifications, see BIP0121. +* The nonce must be randomly generated by the server for every new PoP request. + +=== Validating a PoP === + +The server needs to validate the PoP and reply with "valid" or "invalid". That process is outlined below. If any step fails, the validation is aborted and "invalid" is returned: + +# Check the format of the PoP. It must pass normal transaction checks, except that the inputs may already be spent. +# Check that lock_time is 499999999. +# Check that there is exactly one output. This output must have value 0 and conform to the OP_RETURN output format outlined above. +# Check that the nonce is the same as the one requested. +# Check that the inputs of the PoP are exactly the same as in transaction T, except that the sequence numbers must all be 0. The ordering of the inputs must also be the same as in T. +# Run the scripts of all the inputs. All scripts must return true. +# Check that the txid in the PoP output is the transaction you actually want proof for. If you don’t know exactly what transaction you want proof for, check that the transaction actually pays for the product/service you deliver. +# Return "valid". + +== Security considerations == + +* Someone can intercept the PoP-request and change any parameter in it. These can be mitigated by using secure connections. Examples of tampered parameters: +** Pop destination - Stealing your PoP. +** label - Trick you to sign an unintended pop or set a label that your wallet doesn't have any record for, resulting in a broken service. Always check the PoP before signing. +** nonce - Your pop will not validate on server. +* Someone can steal a PoP, for example by tampering with the PoP request, and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^48). The server should have a mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so. +* Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied. +* Transaction malleability may cause the server to have a different transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions. + +== Reference implementation == + +[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub] + +[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub] + +== References == + +[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme + +[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP0070]: Payment Protocol + +[https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki BIP0121]: Proof of Payment URI scheme diff --git a/bip-0121.mediawiki b/bip-0121.mediawiki new file mode 100644 index 0000000..bafe856 --- /dev/null +++ b/bip-0121.mediawiki @@ -0,0 +1,145 @@ +<pre> + BIP: 121 + Title: Proof of Payment URI scheme + Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Status: Draft + Type: Standards Track + Created: 2015-07-27 +</pre> + +== Abstract == + +This is a proposal for a URI scheme to be used in the Proof of Payment +process. + +== Motivation == + +To make a Proof of Payment, the party that wants the proof needs to +transfer a Proof of Payment request to the wallet software of the +other party. To facilitate that transfer, a new URI scheme +representing the PoP request is proposed. This URI can then be encoded +in QR images or be sent over NFC in order to transfer it to the wallet. + +== Specification == + +The specification is the same as BIP0021, with the following +differences: + +* The URI scheme is <tt>btcpop</tt> instead of <tt>bitcoin</tt> +* The path component, i.e. the address part, is always empty. +* A mandatory <tt>p</tt> parameter whose value contains the destination for the PoP. This could for example be a <tt>https:</tt> URL or a <tt>mailto:</tt> URI. +* A mandatory <tt>n</tt> parameter representing the nonce, base58 encoded. +* An optional <tt>txid</tt> parameter containing the Base58 encoded hash of the transaction to prove. + +Just as in BIP0021, elements of the query component may contain +characters outside the valid range. These must first be encoded +according to UTF-8, and then each octet of the corresponding UTF-8 +sequence must be percent-encoded as described in RFC 3986. + +All parameters except <tt>p</tt> and <tt>n</tt> are hints to the +wallet on which transaction to create a PoP for. + +The extensibility of BIP0021 applies to this scheme as well. For +example, a <tt>date</tt> parameter or a <tt>toaddr</tt> parameter +might be useful. <tt>req-*</tt> parameters are also allowed and obey +the same rules as in BIP0021, clients not supporting a <tt>req-*</tt> +parameter must consider the URI invalid. + +=== Keep URIs short === + +Implementations should keep the URIs as short as possible. This is +because it makes QR decoding more stable. A camera with a scratched +lens or low resolution may run into problems scanning huge QR +codes. This is why the <tt>txid</tt> parameter is encoded in Base58 +instead of the classic hex encoded string. We get away with 44 +characters instead of 64. Also, the <tt>nonce</tt> parameter is Base58 +encoded for the same reason. + +== Interpretation == + +=== Transaction hints === + +The wallet processing the URI must use the hints in the PoP request to +filter its transaction set. The <tt>label</tt>, <tt>amount</tt> and +<tt>message</tt> parameters must, if present in the URI, exactly match +the data associated with the original payment according to the +following table: + +{| +| <tt>btcpop:</tt> URI parameter || <tt>bitcoin:</tt> URI parameter || BIP70 PaymentDetails data +|- +| <tt>label</tt> || <tt>label</tt> || <tt>memo</tt> +|- +| <tt>amount</tt> || <tt>amount</tt> || <tt>sum of outputs.amount</tt> +|- +| <tt>message</tt> || <tt>message</tt> || <tt>-</tt> +|} + +The <tt>txid</tt> parameter value must match the transaction hash of +the payment. + +After filtering, the resulting transaction set is displayed to the +user who selects one of them to prove. An implementation could also +automatically select a transaction in the filtered set, but +there must still be a way for the user to select freely among the +matching transactions. If the filtered set is empty, no transaction +fits the hints and a message about that is presented to the user. If +the filtered set contains exactly one transaction, which is +preferable, that transaction can be automatically selected. + +As a fallback, there must also be a way for the user to select any +transaction from the wallet regardless of the transaction hints. This +can be useful if the metadata of the wallet is lost, possibly due to a +restore from backup. + +=== PoP destination <tt>p</tt> === + +The <tt>p</tt> parameter value is the destination where to send the +PoP to. This destination is typically a <tt>https:</tt> URL or a +<tt>http:</tt> URL, but it could be any type of URI, for example +<tt>mailto:</tt>. To keep <tt>btcpop:</tt> URIs short, users should +not make their <tt>p</tt> parameter unnecessarily long. + +==== <tt>http:</tt> and <tt>https:</tt> URLs ==== + +Wallet implementations must support the <tt>http:</tt> and +<tt>https:</tt> schemes in which case <tt>POST</tt> method must be +used. The PoP is sent as a binary serialized transaction. The content +type of the POST request must be set to +<tt>application/bitcoin-pop</tt> + +== Examples == + +Send PoP for a transaction with label "video 42923" to +<nowiki>https://www.example.com/pop/352</nowiki>, using nonce +<tt>0x73 0xd5 0x1a 0xbb 0xd8 0x9c</tt>: +<pre> + btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video%2042923 +</pre> +Send PoP through mail using +<nowiki>mailto:pop@example.com?subject=pop444</nowiki>, amount +is 13370000 satoshis, nonce is <tt>0x6f 0xe 0xfb 0x68 0x92 0xf9</tt>. +Note that the <tt>?</tt> before <tt>subject</tt> is OK according to RFC3986, +since the query part starts from the first <tt>?</tt>: +<pre> + btcpop:?p=mailto:pop@example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337 +</pre> +Send PoP for transaction with id +<tt>cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79</tt> +to pizza place at <nowiki>http://pizza.example.com/pop/laszlo111</nowiki> using nonce <tt>0xfc 0xcc 0x2c 0x35 0xf0 0xb8</tt> +<pre> + btcpop:?p=http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL +</pre> +== Reference implementation == + +[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub] + +[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub] + +== References == + +[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme + +[https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki BIP0120]: Proof of Payment + +[https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier (URI): Generic Syntax diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki new file mode 100644 index 0000000..902aa02 --- /dev/null +++ b/bip-0122.mediawiki @@ -0,0 +1,112 @@ +<pre> + BIP: 122 + Title: URI scheme for Blockchain references / exploration + Author: Marco Pontello <marcopon@gmail.com> + Status: Draft + Type: Standards Track + Created: 29 August 2015 + Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html +</pre> + +==Abstract== + +This BIP propose an URI scheme for looking up blocks, transactions, addresses on a Blockchain explorer, or in general to make proper Blockchain references + +==Motivation== + +The purpose of this URI scheme is to enable users to handle all the requests for details about blocks, transactions, etc. with their preferred tool (being that a web service or a local application). +Currently a Bitcoin client usually points to an arbitrary blockchain explorer when the user looks for the details of a transaction, or let him choose from a limited list of possible alternatives. +Other times resorting to cut&paste is needed. +The same happens with posts and messages that reference some particular txs or blocks, if they provide links at all. + +==Specification== + +The URI follow this form: + + <nowiki>blockchain:[//chain]</type/hash></nowiki> + +Where: + +{| class="wikitable" +! style="text-align: center;" | Element +! colspan="2" style="text-align: center;" | Description +! +|- +| chain +| colspan="2" | '''chain ID''' (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed. +| optional +|- +| rowspan="3" | type +| tx +| for transactions. +| rowspan="3" | +|- +| block +| for blocks (supports both hash or height). +|- +| address +| for addresses. +|- +| hash +| colspan="2" | the relevant hash to refer to (leading zeros included), or block height. +| +|} + +---- +===Definition of chain ID=== + +The '''chain ID''' of a chain is the block hash of the corresponding genesis block. For forked chains, it's the block hash of the first block after fork. + +So, for example: +<pre> +Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f +Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 +Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 +</pre> + +An example of forked chain (Feathercoin, that forked Litecoin): + +<img src=bip-0122/chainid.png></img> + +<pre> +Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2 +Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb +</pre> + + +==Examples== + +A transaction on Bitcoin main net: + blockchain:/tx/b462ae6eb8bdae2e060239a2a3ea5d9c3e0f9ef34d9717beb2dcf0ed42cee7da + +A block on Bitcoin main net: + blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72 +or + blockchain:/block/372338 + +An address on Bitcoin main net: + blockchain:/address/16EW6Rv9P9AxFDBrZV816dD4sj1EAYUX3f + +A transaction on Bitcoin test net: + blockchain://000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a + +==Rationale== + +From the point of view of a wallet (or other Blockchain related tool) developer that need to show any kind of Blockchain references, using this scheme mean that he can simply make it a blockchain: link and be done with it, without having to worry about any specific Blockchain explorer or provide a means for the user to select one. + +Blockchain explorers in turn will simply offer to handle the blockchain: URI, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. + +Users get the convenience of using always their preferred explorer, which can be especially handy on mobile devices, where juggling with cut&paste is far from ideal. + +== Sample implementation == + +[https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub] + +==Acknowledgements== +Thanks to Btc Drak for suggesting to provide support for different networks. +Thanks to Jorge Timon for the idea of using genesis blocks hashes to identify them. +Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for suggestions about the structure and hierarchy of the URI scheme. + +==Copyright== + +This document is placed in the public domain.
\ No newline at end of file diff --git a/bip-0122/chainid.png b/bip-0122/chainid.png Binary files differnew file mode 100644 index 0000000..ab6957a --- /dev/null +++ b/bip-0122/chainid.png diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki new file mode 100644 index 0000000..776529a --- /dev/null +++ b/bip-0123.mediawiki @@ -0,0 +1,401 @@ +<pre> + BIP: 123 + Layer: Process + Title: BIP Classification + Author: Eric Lombrozo + Status: Draft + Type: Process + Created: 2015-08-26 +</pre> + +==Abstract== + +This document describes a classification scheme for BIPs. + +BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. + +The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. + +==Motivation== + +Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. + +In order to have a BIP process which more closely reflects the interoperability requirements, it is necessary to categorize BIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed. + +==Specification== + +Standards BIPs are placed in one of four layers: + +# Consensus +# Peer Services +# API/RPC +# Applications + +===1. Consensus Layer=== + +The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence. + +The consensus layer is not concerned with how messages are propagated on a network. + +Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks. + +====Soft Forks==== + +In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules. + +====Hard Forks==== + +In a hard fork, structures that were invalid under the old rules become valid under the new rules. + +===2. Peer Services Layer=== + +The peer services layer specifies how nodes find each other and propagate messages. + +Only a subset of all specified peer services are required for basic node interoperability. Nodes can support further optional extensions. + +It is always possible to add new services without breaking compatibility with existing services, then gradually deprecate older services. In this manner, the entire network can be upgraded without serious risks of service disruption. + +===3. API/RPC Layer=== + +The API/RPC layer specifies higher level calls accessible to applications. Support for these BIPs is not required for basic network interoperability but might be expected by some client applications. + +There's room at this layer to allow for competing standards without breaking basic network interoperability. + +===4. Applications Layer=== + +The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. + +==Classification of existing BIPs== + +{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Number +!Layer +!Title +!Owner +!Type +!Status +|- style="background-color: #cfffcf" +| [[bip-0001.mediawiki|1]] +| Process +| BIP Purpose and Guidelines +| Amir Taaki +| Standard +| Active +|- +| [[bip-0010.mediawiki|10]] +| Applications +| Multi-Sig Transaction Distribution +| Alan Reiner +| Informational +| Withdrawn +|- style="background-color: #cfffcf" +| [[bip-0011.mediawiki|11]] +| Peer Services +| M-of-N Standard Transactions +| Gavin Andresen +| Standard +| Accepted +|- style="background-color: #ffcfcf" +| [[bip-0012.mediawiki|12]] +| Consensus (soft fork) +| OP_EVAL +| Gavin Andresen +| Standard +| Withdrawn +|- style="background-color: #cfffcf" +| [[bip-0013.mediawiki|13]] +| Applications +| Address Format for pay-to-script-hash +| Gavin Andresen +| Standard +| Final +|- style="background-color: #cfffcf" +| [[bip-0014.mediawiki|14]] +| Peer Services +| Protocol Version and User Agent +| Amir Taaki, Patrick Strateman +| Standard +| Accepted +|- style="background-color: #ffcfcf" +| [[bip-0015.mediawiki|15]] +| Applications +| Aliases +| Amir Taaki +| Standard +| Deferred +|- style="background-color: #cfffcf" +| [[bip-0016.mediawiki|16]] +| Consensus (soft fork) +| Pay To Script Hash +| Gavin Andresen +| Standard +| Final +|- style="background-color: #ffcfcf" +| [[bip-0017.mediawiki|17]] +| Consensus (soft fork) +| OP_CHECKHASHVERIFY (CHV) +| Luke Dashjr +| Withdrawn +| Draft +|- +| [[bip-0018.mediawiki|18]] +| Consensus (soft fork) +| hashScriptCheck +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0019.mediawiki|19]] +| Peer Services +| M-of-N Standard Transactions (Low SigOp) +| Luke Dashjr +| Standard +| Draft +|- style="background-color: #ffcfcf" +| [[bip-0020.mediawiki|20]] +| Applications +| URI Scheme +| Luke Dashjr +| Standard +| Replaced +|- style="background-color: #cfffcf" +| [[bip-0021.mediawiki|21]] +| Applications +| URI Scheme +| Nils Schneider, Matt Corallo +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0022.mediawiki|22]] +| API/RPC +| getblocktemplate - Fundamentals +| Luke Dashjr +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0023.mediawiki|23]] +| API/RPC +| getblocktemplate - Pooled Mining +| Luke Dashjr +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0030.mediawiki|30]] +| Consensus (soft fork) +| Duplicate transactions +| Pieter Wuille +| Standard +| Final +|- style="background-color: #cfffcf" +| [[bip-0031.mediawiki|31]] +| Peer Services +| Pong message +| Mike Hearn +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0032.mediawiki|32]] +| Applications +| Hierarchical Deterministic Wallets +| Pieter Wuille +| Informational +| Accepted +|- +| [[bip-0033.mediawiki|33]] +| API/RPC +| Stratized Nodes +| Amir Taaki +| Standard +| Draft +|- style="background-color: #cfffcf" +| [[bip-0034.mediawiki|34]] +| Consensus (soft fork) +| Block v2, Height in coinbase +| Gavin Andresen +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0035.mediawiki|35]] +| Peer Services +| mempool message +| Jeff Garzik +| Standard +| Accepted +|- +| [[bip-0036.mediawiki|36]] +| Peer Services +| Custom Services +| Stefan Thomas +| Standard +| Draft +|- style="background-color: #cfffcf" +| [[bip-0037.mediawiki|37]] +| Peer Services +| Bloom filtering +| Mike Hearn and Matt Corallo +| Standard +| Accepted +|- +| [[bip-0038.mediawiki|38]] +| Applications +| Passphrase-protected private key +| Mike Caldwell +| Standard +| Draft +|- +| [[bip-0039.mediawiki|39]] +| Applications +| Mnemonic code for generating deterministic keys +| Slush +| Standard +| Draft +|- +| 40 +| Applications +| Stratum wire protocol +| Slush +| Standard +| BIP number allocated +|- +| 41 +| Applications +| Stratum mining protocol +| Slush +| Standard +| BIP number allocated +|- +| [[bip-0042.mediawiki|42]] +| Consensus (soft fork) +| A finite monetary supply for Bitcoin +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0043.mediawiki|43]] +| Applications +| Purpose Field for Deterministic Wallets +| Slush +| Standard +| Draft +|- +| [[bip-0044.mediawiki|44]] +| Applications +| Multi-Account Hierarchy for Deterministic Wallets +| Slush +| Standard +| Draft +|- +| [[bip-0045.mediawiki|45]] +| Applications +| Structure for Deterministic P2SH Multisignature Wallets +| Manuel Araoz +| Standard +| Draft +|- +| [[bip-0050.mediawiki|50]] +| Informational +| March 2013 Chain Fork Post-Mortem +| Gavin Andresen +| Informational +| Draft +<!-- 50 series reserved for a group of post-mortems --> +|- +| [[bip-0060.mediawiki|60]] +| Peer Services +| Fixed Length "version" Message (Relay-Transactions Field) +| Amir Taaki +| Standard +| Draft +|- +| [[bip-0061.mediawiki|61]] +| Peer Services +| "reject" P2P message +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0062.mediawiki|62]] +| Consensus (soft fork) +| Dealing with malleability +| Pieter Wuille +| Standard +| Draft +|- +| 63 +| Applications +| Stealth Addresses +| Peter Todd +| Standard +| BIP number allocated +|- +| [[bip-0064.mediawiki|64]] +| Peer Services +| getutxos message +| Mike Hearn +| Standard +| Draft +|- +| [[bip-0065.mediawiki|65]] +| Consensus (soft fork) +| OP_CHECKLOCKTIMEVERIFY +| Peter Todd +| Standard +| Draft +|- +| [[bip-0066.mediawiki|66]] +| Consensus (soft fork) +| Strict DER signatures +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0067.mediawiki|67]] +| Applications +| Deterministic P2SH multi-signature addresses +| Thomas Kerin +| Standard +| Draft +|- +| [[bip-0068.mediawiki|68]] +| Consensus (soft fork) +| Consensus-enforced transaction replacement signalled via sequence numbers +| Mark Friedenbach +| Standard +| Draft +|- +| [[bip-0070.mediawiki|70]] +| Applications +| Payment protocol +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0071.mediawiki|71]] +| Applications +| Payment protocol MIME types +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0072.mediawiki|72]] +| Applications +| Payment protocol URIs +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0073.mediawiki|73]] +| Applications +| Use "Accept" header with Payment Request URLs +| Stephen Pair +| Standard +| Draft +|- +| [[bip-0101.mediawiki|101]] +| Consensus (hard fork) +| Increase maximum block size +| Gavin Andresen +| Standard +| Draft +|} + diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki new file mode 100644 index 0000000..63788e9 --- /dev/null +++ b/bip-0125.mediawiki @@ -0,0 +1,187 @@ +<pre> + BIP: 125 + Title: Opt-in Full Replace-by-Fee Signaling + Author: David A. Harding <dave@dtrt.org>, Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-12-04 +</pre> + +==Abstract== + +Many nodes today will not replace any transaction in their mempool with +another transaction that spends the same inputs, making it difficult for +spenders to adjust their previously-sent transactions to deal with +unexpected confirmation delays or to perform other useful replacements. + +The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy +described here allows spenders to add a signal to a transaction indicating +that they want to be able to replace that transaction in the future. +In response to this signal, + +* Nodes may allow transactions containing this signal to be replaced in their mempools. + +* The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them. + +Nodes and recipients may continue to treat transactions without the +signal the same way they treated them before, preserving the existing +status quo. + +==Summary== + +This policy specifies two ways a transaction can signal that it is +replaceable. + +* '''Explicit signaling:''' A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1). + +* '''Inherited signaling:''' Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed. + +===Implementation Details=== + +The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules: + +One or more transactions currently in the mempool (original +transactions) will be replaced by a new transaction (replacement +transaction) that spends one or more of the same inputs if, + +# The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section. + +# The replacement transaction pays an absolute higher fee than the sum paid by the original transactions. + +# The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.) + +# The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals. + +# The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions. + +The initial implementation may be seen in +[https://github.com/bitcoin/bitcoin/pull/6871 Bitcoin Core PR#6871] +and specifically the master branch commits from +5891f870d68d90408aa5ce5b597fb574f2d2cbca to +16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive). + +===Receiving wallet policy=== + +Wallets that display unconfirmed transactions to users or that provide +data about unconfirmed transactions to automated systems should consider +doing one of the following: + +# Conveying additional suspicion about opt-in full-RBF transactions to the user or data consumer. + +# Ignoring the opt-in transaction until it has been confirmed. + +Because descendant transactions may also be replaceable under this +policy through inherited signaling, any method used to process opt-in +full-RBF transactions should be inherited by any descendant transactions +for as long as any ancestor opt-in full-RBF transactions remain +unconfirmed. + +===Spending wallet policy=== + +Wallets that don't want to signal replaceability should use either a max +sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when +then also want to use locktime; all known wallets currently do this. +They should also take care not to spend any unconfirmed transaction that +signals replaceability explicitly or through inherited signaling; most wallets also +currently do this by not spending any unconfirmed transactions except +for those they created themselves. + +Wallets that do want to make replacements should use explicit signaling +and meet the criteria described above in the Implementation Details +section. A +[https://en.bitcoin.it/wiki/Transaction_replacement Bitcoin Wiki page] +has been created to help wallet authors track deployed mempool policies +relating to transaction replacement. + +The initial implementation makes use of P2P protocol reject messages for +rejected replacements, allowing P2P clients to determine whether their +replacements were initially accepted by their peers. Standard P2P +lightweight client practice of sending to some peers while listening for +relays from other peers should allow clients to determine whether the +replacement has propagated. + +==Motivation== + +Satoshi Nakamoto's original Bitcoin implementation provided the +nSequence number field in each input to +[https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434 allow replacement] +of transactions containing that input within the +mempool. When receiving replacements, nodes were supposed to replace +transactions whose inputs had lower sequence numbers with transactions +that had higher sequence numbers. + +In that implementation, replacement transactions did not have to pay +additional fees, so there was no direct incentive for miners to +include the replacement and no built-in rate limiting that prevented +overuse of relay node bandwidth. Nakamoto +[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 removed replacement] +from Bitcoin version 0.3.12, leaving only the +comment, "Disable replacement feature for now". + +Replacing transactions with higher-fee transactions provided a way for +spenders to align their desires with miners, but by the time a +Replace-by-Fee (RBF) patch was available to re-enable replacement, some +receivers had begun to expect that the first version of a transaction +they saw was highly likely to be the version of the transaction to be +confirmed, and so some users advocated that replacement should be +disallowed. + +To address those concerns, a variation on RBF was created that +required that the replacement transaction pay all of same outputs as +the original transaction in equal or greater amount. This was called +RBF First Seen Safe (RBF-FSS), and the original RBF became known as +full-RBF. Although agreeable to recipients who relied on the +first-seen version of a transaction, each use of RBF-FSS required +adding an extra input to a transaction, resulting in wallets being +unable to use it if they had no spare inputs, a loss of privacy when +inputs from different origins get used in the same transaction, and a +wasteful increase in transaction byte size. + +Opt-in full-RBF uses Nakamoto's original semantics (with a slight +tweak to allow locktime users to opt-out) to signal that replacement +is possible, providing first-seen users with the ability to ignore +those transactions while also allowing for the efficiency benefits +of full-RBF. + +There are no known problematic interactions between opt-in full-RBF and +other uses of nSequence. Specifically, opt-in full-RBF is compatible +with consensus-enforced locktime as provided in the Bitcoin 0.1 +implementation, draft BIP68 (Relative lock-time using consensus-enforced +sequence numbers), and draft BIP112 (CHECKSEQUENCEVERIFY). + +==Deployment== + +Now, and since Bitcoin's first release, 100% of the network hash rate +mines transactions using opt-in full-RBF semantics (sequence less than +(0xffffffff - 1)). + +Opt-in full-RBF as a default mempool replacement policy among nodes +and miners is expected to become widespread as they upgrade to Bitcoin +Core 0.12.0 (release expected Jan/Feb 2016) and similar node software +such as Bitcoin LJR. + +Actual replacement may be unreliable until two conditions have been satisfied: + +# Enough nodes have upgraded to support it, providing a relay path for replacements to go from spending wallets to miners controlling significant amounts of hash rate. + +# Enough hash rate has upgraded to support replacement, allowing for reasonable probability that a replacement can be mined. + +==Client support== + +No known wallet currently creates transactions by default with +nSequence set below (0xffffffff - 1), so no known existing wallet +explicitly signals replaceability by default. No known popular wallet +spends other users' unconfirmed transactions by default, so no known +existing wallets signals inherited replaceability. + +==See also== + +# [https://en.bitcoin.it/wiki/Transaction_replacement Transaction Replaceability on Bitcoin Wiki] targeted at helping wallet authors use RBF + +# Tools for creating opt-in full-RBF transactions: https://github.com/petertodd/replace-by-fee-tools#replace-by-fee-tools + +# [https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/ Reddit: Questions about opt-in RBF] targeted at helping community members understand opt-in full-RBF + +==Copyright== + +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. diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki new file mode 100644 index 0000000..b187a49 --- /dev/null +++ b/bip-0140.mediawiki @@ -0,0 +1,113 @@ +<pre> + BIP: 140 + Title: Normalized TXID + Author: Christian Decker <decker.christian@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-10-14 +</pre> +== Abstract == + +This BIP describes the use of normalized transaction IDs (NTXIDs) in order to eliminate transaction malleability, both in the third-party modification scenario as well as the participant modification scenario. The transaction ID is normalized by removing the signature scripts from transactions before computing its hash. The normalized transaction hashes are then used during the signature creation and signature verification of dependent transactions. + +== Motivation == + +Transaction malleability refers to the fact that transactions can be modified, either by one of the signers by re-signing the transaction or a third-party by modifying the signature representation. This is a problem since any modification to the serialized representation also changes the hash of the transaction, which is used by spending transaction to reference the funds that are being transferred. If a transaction is modified and later confirmed by ending up in the blockchain all transactions that depended on the original transaction are no longer valid, and thus orphaned. + +BIPs 62<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|BIP 62 - Dealing with malleability]]</ref> and 66<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki|BIP 66 - Strict DER signatures]]</ref> alleviate the problem of third-party modification by defining a canonical representation of the signatures. However, checking the canonical representation is complex and may not eliminate all sources of third-party malleability. Furthermore, these BIPs do not address modifications by one of the signers, i.e., re-signing the transaction, because signers can produce any number of signatures due to the random parameter in ECDSA. + +This proposal eliminates malleability by removing the malleable signatures from the hash used to reference the outputs spent by a transaction. The new hash used to reference an output is called the ''normalized transaction ID''. The integrity of all data that is used to reference the output is guaranteed by the signature itself, and any modification that would change the normalized transaction ID would also invalidate the signature itself. + +Besides eliminating transaction malleability as a source of problems it also allows the use of transaction templates. Transaction templates simplify higher level protocols and allows new uses. They allow an unsigned template transaction to be used as a basis for a sequence of transaction and only once the sequence matches the signers' expectations they provide the necessary signatures for the template to become valid, thus opting in to the sequence. + +== Specification == + +The use of normalized transaction IDs is introduced as a softfork. The specification is divided into three parts: + +* Computation of the normalized transaction ID +* Introduction of a new extensible signature verification opcode to enable softfork deployment +* Changes to the UTXO tracking to enable normalized transaction ID lookup + +=== Normalized Transaction ID computation === + +In order to calculate the normalized transaction ID, the signature script is stripped from each input of the transaction of non-coinbase transactions and each input is normalized. Stripping the signature script is achieved by setting the script's length to 0 and removing the <code>uchar[]</code> array from the <code>TxIn</code>.<ref>[[https://en.bitcoin.it/wiki/Protocol_Specification#tx|Protocol Specification: TX]]</ref> +Inputs are then normalized by replacing the hash of each previous transaction with its normalized version if available, i.e., the normalized hash of the previous transaction that created the output being spent in the current transaction. Version 1 transactions do not have a normalized transaction ID hence the non-normalized transaction ID is used for input normalization. + +The normalized transaction ID is then computed as the double <code>SHA 256</code> hash of the normalized transaction matching the existing transaction ID computation. The normalized transaction ID remains unchanged even if the signatures of the transaction are replaced/malleated and describe a class of semantically identical transactions. In the following we use ''transaction instance ID'' to refer to the transaction ID computed on the transaction including signatures. Normalized transaction IDs for coinbase transactions are computed with the signature script in the coinbase input, in order to avoid hash collisions. + +=== OP_CHECKSIGEX === +This BIP introduces a new opcode <code>OP_CHECKSIGEX</code> which replaces <code>OP_NOP4</code>. <code>OP_CHECKSIGEX</code> subsumes <code>OP_CHECKSIGVERIFY</code> and <code>OP_CHECKMULTISIGVERIFY</code>, and extends them by accepting a new <code>VERSION</code> parameter. The version parameter is a single integer pushed onto the stack before invoking <code>OP_CHECKSIGEX</code> and is used to group and evolve future versions of signature checking opcodes. + +When executed <code>OP_CHECKSIGEX</code> pops the version from the stack and then performs the signature check according to the specified version. If the verifying client does not support the specified version, i.e., the version was defined after the release of the client, the client must treat the <code>OP_CHECKSIGEX</code> as an <code>OP_NOP</code>. + +==== Version 1 ==== + +The first version of <code>OP_CHECKSIGEX</code> (<code>VERSION=1</code>) implements normalized transaction IDs and uses Schnorr signatures instead of the current ECDSA signatures. + +Version 1 introduces the following new standard script format: + + m {pubkey}...{pubkey} n v OP_CHECKSIGEX + +with matching scriptSig format: + + {signature}...{signature} + +This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP 11] with an additional version parameter <code>v</code> and the new opcode. Singlesig transactions are encoded as ''1-of-1'' transactions. + +The existing <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> have a bug<ref>[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]]</ref> that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. + +The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. + +=== Tracking Normalized Transaction IDs === + +The transaction version is bumped to 2. The new version signals to clients receiving the transaction that they should track the normalized transaction ID along with the transaction instance ID in the unspent transaction output (UTXO) set. Upon receiving a version 2 transaction the client computes the normalized transaction ID, annotates the outputs with it, and adds them into the UTXO set indexed by the transaction instance ID as before. Transactions continue using the transaction instance ID to reference the outputs, but while checking the signature they may get normalized. All network messages continue to use the transaction instance ID to reference the transaction, specifically <code>inv</code>, <code>getdata</code>, <code>tx</code> and <code>block</code> messages still use transaction instance IDs, not the normalized transaction IDs. + +Outputs created by version 1 transactions are not annotated with the normalized transaction ID, and when normalizing the hashes in transaction inputs referencing version 1 outputs are not modified. + +== Rationale == + +=== Normalization === +Normalized transaction IDs are provably non-malleable since no data is included in the signaturehash whose integrity is not also proven in the signature, thus any modification causing the hash to change will also invalidate the signature. +Normalized transactions are secure as they still use cryptographic hashes over all the semantic information of the transaction, i.e., the inputs, outputs and metadata, thus it is still computationally infeasible to cause a hash collision between transactions. + +There are a number of advantages to using normalized transaction IDs: + +* Like BIP 62 and BIP 66 it solves the problem of third-parties picking transactions out of the network, modifying them and reinjecting them. +* ''m-of-n'' multisig outputs are often used in higher level protocols<ref>[[http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf|A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels ]]</ref><ref>[[http://lightning.network/lightning-network-paper.pdf|The Bitcoin Lightning Network: +Scalable Off-Chain Instant Payments]]</ref> in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. +* Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. + +The only occurence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. + +In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. + +Using version 2 for transactions is an explicit opt-in to the normalized ID tracking and a simple upgrade for existing clients. It avoids having to reprocess the entire blockchain and computing the normalized transaction IDs for existing outputs in the UTXO. This would be further complicated by having to recursively compute normalized transaction IDs down to the coinbase transactions which created the coins. + +Tracking the normalized transaction IDs in the UTXO requires the storage of an additional hash per transaction whose outputs are not completely spent, which at 7,000,000 transactions with unspent outputs amounts to 224MB additional storage on disk. + +The coinbase transactions have been checked for hash-collisions and no collisions were found except for the coinbase transactions in blocks at heights 91842 and 91880, which are known to be identical<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP 30 - Duplicate transactions]]</ref>, and motivated the introduction of BIP 34.<ref>[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in Coinbase]]</ref> Since coinbase transactions are invalid if transmitted outside of a block it is not possible to modify them on the fly and since they only mature after being included for a long time in the blockchain they are considered safe. + +=== OP_CHECKSIGEX === + +The new opcode <code>OP_CHECKSIGEX</code> was introduced in order to allow the use of normalized transaction IDs as a softfork and in order to keep the number of <code>OP_NOP</code>s needed to a bare minimum, while enabling future soft-fork updates to the signing algorithms. + +The additional argument containing the version can be pushed on the stack using a single byte up to version 16 (<code>OP_1</code> - <code>OP_16</code>), resulting in one byte overhead for this script type. Using the standard multisig format also for 1-of-1 transactions add an additional 2 bytes, however it also removes the bug requiring a dummy push, resulting in a single byte overhead. +Furthermore, using Schnorr signatures instead of ECDSA brings a number of improvements that reduce the size of transactions (''m-of-m'' is the same size as ''1-of-1'') and increase verification speed (batch signature validation by summing up keys and signatures). The code is already in bitcoin/secp256k1 and can be merged in. We limited the description of this BIP to re-using BIP 11 style ''m-of-n'' scripts to keep it short, however Schnorr also allows a number of more complex applications which we defer to future BIPs. + +Version 0 was intentionally skipped in order to guarantee that the top-most element before <code>OP_CHECKSIGEX</code> is non-zero. This is necessary to guarantee that non-upgraded clients, which interpret <code>OP_CHECKSIGEX</code> as <code>OP_NOP4</code>, do not end up with a zero value on top of the stack after execution, which would be interpreted as script failure. + +=== Impact === + +This is a softfork which replaces <code>OP_NOP4</code> with the new implementation of <code>OP_CHECKSIGEX</code>, as such the impact on the network is minimal. Wallets that do not implement this opcode will not be able to verify the validity of the scripts, however if transactions using <code>OP_CHECKSIGEX</code> are included in blocks they will accept them and track the inputs correctly. This is guaranteed since the transaction inputs still use the non-normalized transaction ID to reference the outputs to be claimed, hence non-upgraded wallets can still lookup the outputs and mark them as spent. Furthermore, clients that do not implement this BIP are unable to identify outputs using this script as their own, however upgrading and rescanning the blockchain will make them available. + +== See also == + +* [[bip-0062.mediawiki|BIP 62: Dealing with malleability]] +* [[bip-0066.mediawiki|BIP 66: Strict DER Signatures]] + +== References == +<references> + +==Copyright== +This document is placed in the public domain.
\ No newline at end of file diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki new file mode 100644 index 0000000..ac44d87 --- /dev/null +++ b/bip-0141.mediawiki @@ -0,0 +1,267 @@ +<pre> + BIP: 141 + Title: Segregated Witness (Consensus layer) + Author: Eric Lombrozo <elombrozo@gmail.com> + Johnson Lau <jl2012@xbt.hk> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-12-21 +</pre> + +==Abstract== + +This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure. + +The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch. + +==Motivation== + +The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it. + +By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed: + +# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was authorized is no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62): +#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation) +#* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62) +#* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability +#* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network +# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth. +# '''Some constraints could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example: +#* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent +#* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed +#* New script system could be introduced without any limitation from the existing script semantic +# '''Additional data required for fraud proofs can be added to witness'''. Extra data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify. +#* Backlinks for the outputs spent by the transaction's inputs can be provided. These backlinks consist of a block hash and an offset that thin clients can easily query and check to verify that the outputs exist. +#* Sum trees for transaction inputs and outputs can be committed making it possible to construct short proofs that no new coins are created in any noncoinbase transaction and that the miner does not add excessive fees to the coinbase transaction. + +==Specification== + +=== Commitment structure === + +!!!DRAFT ONLY!!! + +A new block rule is added which requires a commitment to the witness hashes in the coinbase (or an OP_RETURN output of a specific transaction, or somewhere else) + +(Hardfork after x year to move the commitment to block header?) + +Witness hash is the double SHA256 of a transaction including witnesses: http://blockhawk.net/diagrams/witnesstx.png. For the coinbase transaction, its witness hash is assumed to be 0x0000....0000. + +A witness root hash is calculated with all those witness hashes as leaves, in a way similar to the hashMerkleRoot in the block header. + +No witness data is allowed in blocks that don't commit to witness data, as this would otherwise leave room from spam. + +==== Proposal 1: balance tree (the current implementation) ==== +The commitment is a push of exactly 41 bytes: +*The first 4 bytes are commitment header: 0xaa21a9ed +*The next 4 bytes describe a nonce +*The next 1 byte is the "levels bytes", describes the number of levels in a Merkle tree (0 to 32) +*The next 32 bytes is a commitment root hash (not the witness root hash) + +Locator of the witness root hash is defined as: + +<pre>SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)</pre> + +The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. + +The coinbase's input's witness must consist of a single byte array of 32 * levels bytes, and are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. + +====Proposal 2: imbalance tree==== +The commitment is a push of exactly 40 bytes: +*The first 4 bytes are commitment header: 0xaa21a9ed +*The next 4 bytes describe a nonce +*The next 32 bytes is a commitment root hash (not the witness root hash) + +Locator of the witness root hash is defined as: + +<pre>SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)</pre> + +The first levels bits of locator, interpreted in little endian, are assumed to be the position in the leaves of the Merkle tree where the witness root hash goes. + +The coinbase's input's witness must consist of a single byte array, which the size must be a multiple of 32 bytes but not bigger than 32*32 bytes. These are assumed to be the Merkle path to connect the witness root hash to the commitment root hash. Depth of the commitment is determined by the length of the path. If the depth of the tree is 0, the path should be represented by 0x00, and the witness root hash will be same as the commitment root hash. + +=== Block size limit === +Blocks are currently limited to 1 MB total size. We change this restriction as follows: + +We define a base block size s<sub>b</sub> consisting of the existing header and transactions, a witness size s<sub>w</sub> consisting of only the size of the witness data, and a virtual block size s<sub>v</sub> = s<sub>b</sub> + s<sub>w</sub>/4. + +The new rule is s<sub>v</sub> <= 1 MB. + +=== Witness program === + +* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". +** In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty. +** In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript. + +** If the version byte is 0, the WP is the actual script. +*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig. +*** The program must not fail, and result in exactly a single TRUE on the stack. +** If the version byte is 1, the WP must be 32 bytes, as a SHA256 hash of the actual script. +*** The witness must consist of an input stack to feed to the program, followed by the serialized program. +*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program. +*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack. +*** The script must not fail, and result in exactly a single TRUE on the stack. +** If the version byte is 2 to 16, no further interpretation of the witness program or witness happens. + +=== Other consensus critical constraints === + +== Block size analysis == +WORK IN PROGRESS + +Definitions: +<pre> + Core block size (CBS): The block size as seen by a non-upgrading full node + Witness size (WS): The total size of witness data in a block + Total block size (TBS): CBS + WS + Witness discount (WD): A discount factor for witness data in VBS calculation (1 = no discount) + Virtual block size (VBS): CBS + (WS * WD) + Witness adoption (WA): Proportion (in size) of new format transactions among all transactions + Prunable ratio (PR): Proportion of signature data size in a transaction +</pre> + +With some transformation it could be shown that: +<pre> + TBS = CBS / (1 - WA * PR) + = VBS / (1 - WA * PR * (1 - WD)) +</pre> + +In order to keep the proposal as a soft fork, the CBS must not have a upper limit higher than 1MB. + +The PR heavily depends on the transaction script type and input-output ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 multisig P2SH are about 47% and 72% respectively. According to the data presented by Pieter Wuille on 7 December 2015, the current average PR on the blockchain is about 60%. + + + +== Examples == + +=== Version 0 witness program === + +The following example is a version 0 witness program, equivalent to the existing Pay-to-Pubkey-Hash (P2PKH) output. + + witness: <signature> <pubkey> + scriptSig: (empty) + scriptPubKey: OP_0 <0x76A914{20-byte-hash-value}88AC> + +The OP_0 indicates the following push is a version 0 witness program. The witness program is deserialized and becomes: + + DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG + +The script is executed with the data from witness + + <signature> <pubkey> DUP HASH160 <20byte-hash-value> EQUALVERIFY CHECKSIG + +Comparing with a P2PKH output, the witness program equivalent occupies 2 more bytes in the scriptPubKey, while moving the signature and public key from scriptSig to witness. + +=== Version 1 witness program === + +The following example is an 1-of-2 multi-signature version 1 witness program. + + witness: 0 <signature1> <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> + scriptSig: (empty) + scriptPubKey: OP_1 <0x{32-byte-hash-value}> + +The OP_1 in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized: + + 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG + +The script is executed with the remaining data from witness: + + 0 <signature1> 1 <33-byte-pubkey1> <33-byte-pubkey2> 2 CHECKMULTISIG + +Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed. + +The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness. + +=== Witness program nested in Pay-to-Script-Hash === + +The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output. + + witness: 0 <signature1> <0x5121{33-byte-pubkey1}21{33-byte-pubkey2}52AE> + scriptSig: <0x5120{32-byte-hash-value}> + scriptPubKey: HASH160 <20-byte-hash-value> EQUAL + +The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as: + + OP_1 <0x{32-byte-hash-value}> + +The version 1 witness program is then executed as described in the last example + +Comparing with the last example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig, which is not prunable in transmission. Although a nested witness program is less efficient in many ways, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0. + +=== Trust-free unconfirmed transaction dependency chain === +Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner. + +Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. + +Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. + +Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. + +== Future extensions == +=== Compact fraud proof for SPV nodes === +Bitcoin right now only has two real security models. A user either runs a full-node which validates every block with all rules in the system, or a SPV (Simple Payment Verification) client which only validates the headers as a proof of publication of some transactions. The Bitcoin whitepaper suggested that SPV nodes may accept alerts from full nodes when they detect an invalid block, prompting the SPV node to download the questioned blocks and transactions for validation. This approach, however, could become a DoS attack vector as there is virtually no cost to generate a false alarm. An alarm must come with a compact, yet deterministic fraud proof. + +In the current Bitcoin protocol, it is possible to generate compact fraud proof for almost all rules except a few: + +# It is not possible to prove a miner has introduced too many Bitcoins in the coinbase transaction outputs without showing the whole block itself and all input transactions. +# It is not possible to prove the violation of any block specific constraints, such as size and sigop limits, without showing the whole block (and all input transactions in the case of sigop limit) +# It is not possible to prove the spending of a non-existing input without showing all transaction IDs in the blockchain way back to the genesis block. + +It is possible to prove the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to prove the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules. + +=== New script system === +Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures. + +Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity. + +The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork. + +=== Per-input lock-time and relative-lock-time === +Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution. + +With a soft fork, it is possible to introduce a separate witness structure to allow per-input lock-time and relative-lock-time, and a new script system that could sign and manipulate the new data (like BIP65 and BIP112). + +== Backward compatibility == +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. + +'''What a non-upgraded wallet can do''' + +* Receiving bitcoin from non-upgraded and upgraded wallets +* Sending bitcoin to non-upgraded wallets +* Sending bitcoin to upgraded wallets using a P2SH address (a less efficient way to use segregated witness) + +'''What a non-upgraded wallet cannot do''' + +* Validating segregated witness transaction. It assumes such a transaction is always valid +* Sending bitcoin to upgraded wallets using a native witness program (a more efficient way to use segregated witness) + +== Deployment == + +We reuse the double-threshold IsSuperMajority() switchover mechanism used in +BIP65 with the same thresholds, but for nVersion = 5. The new rules are +in effect for every block (at height H) with nVersion = 5 and at least +750 out of 1000 blocks preceding it (with heights H-1000..H-1) also +have nVersion >= 5. Furthermore, when 950 out of the 1000 blocks +preceding a block do have nVersion >= 5, nVersion < 5 blocks become +invalid, and all further blocks enforce the new rules. + +(It should be noted that BIP9 involves permanently setting a high-order bit to +1 which results in nVersion >= all prior IsSuperMajority() soft-forks and thus +no bits in nVersion are permanently lost.) + + +=== SPV Clients === + +While SPV clients are unable to fully validate blocks, +they are able to validate block headers and, thus, can check block version and proof-of-work. +SPV clients should reject nVersion < 5 blocks if 950 out of 1000 preceding blocks have +nVersion >= 5 to prevent false confirmations from the remaining 5% of +non-upgraded miners when the 95% threshold has been reached. + +== Credits == +Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. + +== Reference Implementation == +https://github.com/sipa/bitcoin/commits/segwit + +== Copyright == +This document is placed in the public domain. diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki new file mode 100644 index 0000000..7efeca7 --- /dev/null +++ b/bip-0142.mediawiki @@ -0,0 +1,157 @@ +<pre> + BIP: 142 + Title: Address Formats for Witness Program + Author: Johnson Lau <jl2012@xbt.hk> + Status: Draft + Type: Standards Track + Created: 2015-12-24 +</pre> + +== Abstract == + +This BIP describes 2 new types of Bitcoin address to support native Segregated Witness (segwit) transactions. The first type resembles the original P2PKH base-58 address. The second type is a z-base-32 representation of a witness program with Damm algorithm checksum, which supports arbitrarily complex transactions, and is forward compatible to new version witness programs in the future. + +== Motivation == + +To define standard payment addresses for native segwit transactions to promote early adoption of the more efficient transaction method. + +== Specification == + +=== P2PKH segwit address === + +The first new Bitcoin address format defined is specific to pay-to-public-key-hash segwit transaction. The scriptPubKey is a single push of version-0 witness program in this form, + <0x0076A914{20-byte-hash-value}88AC> +The new address is encoded exactly in the same way as the original pay-to-public-key-hash address: + base58-encode: [1-byte version][20-byte-hash-value][4-byte checksum] +Version byte is 0x19 for a main-network address, 0x41 for a testnet address. The following 20-byte is the public key hash. And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and public key hash. + +All addresses generated with this scheme will a constant length of 34 characters, with a "B" prefix for main-network and "T" prefix for testnet. + +=== General segwit address === + +The second new bitcoin address format defined is applicable to witness program of version 0 to 15 with a length of 2 to 32 bytes. + +The z-base-32 character set is used: +{|class="wikitable" style="width:40ex; text-align: center; margin: 0 auto 0 auto;" +!width="12%"|Value +!width="12%"|Symbol +!width="12%"|Value +!width="12%"|Symbol +!width="12%"|Value +!width="12%"|Symbol +!width="12%"|Value +!width="12%"|Symbol +|- +| 0 || y || 8 || e || 16 || o || 24 || a +|- +| 1 || b || 9 || j || 17 || t || 25 || 2 +|- +| 2 || n || 10 || k || 18 || 1 || 26 || 4 +|- +| 3 || d || 11 || m || 19 || u || 27 || 5 +|- +| 4 || r || 12 || c || 20 || w || 28 || h +|- +| 5 || f || 13 || p || 21 || i || 29 || 7 +|- +| 6 || g || 14 || q || 22 || s || 30 || 6 +|- +| 7 || 8 || 15 || x || 23 || z || 31 || 9 +|} + +It is case-insensitive and includes all alphanumeric characters excluding 0, 2, l, v. The order of alphabet is chosen so that less ambiguous alphabet characters will appear more frequently than others. + +An address is a 270-bit string in z-base-32 with the following components: + + 5 address version bits + 5 length bits + 4 witness program version bits + 256 witness program bits + +The address version bits is 00001<sub>b</sub> for the main-network and 11001<sub>b</sub> for the testnet. + +Value of the length bits is the length of the witness program in byte minus 1. + +Witness program version bits indicates version of the witness program (v0 to v15). + +The witness program is padded with leading 0<sub>b</sub> to 256 bits. + +The 270-bit string is transformed to z-base-32 with 54 digits. + +The 54-digit raw address is then divided into 9 equal segments. For each segment, a checksum is calculated with Damm algorithm and appended to the end of the segment. This makes the length increases to 63 digits. + +A second round of checksum is calculated by taking the digits in the same position of the 9 segments, and appended to the end of the address. This is the final address with 69 digits. + + +== Rationale == + +The segregated witness soft fork (BIP x) defines 2 ways of encoding "witness program", a data push of 2 to 32 bytes: + +* A native witness program output is a scriptPubKey with a push of version byte followed by a push of witness program, and nothing else; +* A witness program in P2SH is a P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output. + +As the P2SH address has been defined in 2012, using witness program in P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space and is less collision-resistance than a native witness program, and is only a short-term solution to make the transition smoother. Eventually, all users are expected to use the more efficient native witness program as the primary payment method. + +The drawbacks of Bitcoin addresses have been extensively discussed in BIP13. Since then, better payment methods have been proposed or deployed, for example: +*BIP47 Reusable Payment Codes for Hierarchical Deterministic Wallets +*BIP63 Stealth Addresses +*BIP70 Payment protocol + +However, none of these are as widely adopted as the suboptimal base-58 scriptPubKey template addresses, which is still a standard for the whole eco-system, from wallets, block explorers, merchants, exchanges, to end users. As P2PKH transactions are still dominating the blockchain, the author believes that the proposed P2PKH segwit addresses is the easiest way for wallets and services to adopt native witness program, which is particularly important in the context of scaling the capacity of the blockchain. + +The P2PKH segwit addresses only allow simple payment to a single public key. For arbitrarily complex segwit transactions, the general segwit address is used. The use of z-base-32 eliminates case-sensitiveness and simplifies transformation to and from hexadecimals. The Damm algorithm checksum allows detection of all single-digit errors and all adjacent transposition errors. With the excellent upgradability of witness program, this proposal is also forward compatible to new version witness programs that is not longer than 32 bytes. + +== Compatibility == + +This proposal is not backward compatible, but it fails gracefully -- if an older implementation is given one of these new Bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. + +This proposal is forward compatible to any new witness program format with version 2 to 15 and length of 2 to 32 bytes. + +== Example == + +=== P2PKH segwit address === + +The following public key, + 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 +when encoded as a P2PKH template, would become: + DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG +And the corresponding version 1 Bitcoin address is + 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM +When the same script is encoded as a version 0 witness program, the scriptPubKey becomes: + OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC> +Using 0x19 as the address version, the equivalent witness program address is: + B4YZZ3nMBETWVF9ZSfotSwTxVnqhdkTi7r + +=== General segwit address === + +With the same 25 bytes version 0 witness program in the last example: + OP_0 <0x76A914010966776006953D5567439E5E39F86A0D273BEE88AC> +The address version bits is 00001<sub>b</sub> + 00001<sub>b</sub> +The lengths bits is 11000<sub>b</sub> (24 = 25 - 1) + 00001-11000<sub>b</sub> +The witness program version bits is 0000 + 00001-11000-0000<sub>b</sub> +Appended by the zero-padded witness program + 00001-11000-0000-0-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-00000-11101...01100 +The 270-bit string is transformed to z-base-32 with 54 digits and split into 9 equal segments: + bayyyy -yyyyyy -yyq4wt -eyejc3 -5sybwi -8iksqo -h6mah9 -o4oprh -767nfc +Calculate the Damm checksum for each segment: + For example: Damm(bayyyy) = 7 + bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4 +Calculate the Damm checksum for digits in the same position of different segments: + For example: Damm(byye58ho7) = j + bayyyy7-yyyyyyy-yyq4wte-eyejc3q-5sybwic-8iksqoo-h6mah9w-o4oprhm-767nfc4-jwk86o + +== Implementation == + +From arbitrary witness program to general segwit address: https://gist.github.com/jl2012/760b0f952715b8b6c608 + +== References == + +* [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] +* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] +* [[bip-xxxx.mediawiki|BIP x: Segregated Witness]] https://github.com/bitcoin/bips/pull/265 + +== Copyright == +This work is placed in the public domain. diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki new file mode 100644 index 0000000..276e2cb --- /dev/null +++ b/bip-0143.mediawiki @@ -0,0 +1,133 @@ +<pre> + BIP: 143 + Title: Transaction signature verification for version 0 and version 1 witness program + Author: Johnson Lau <jl2012@xbt.hk> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2016-01-03 +</pre> + +== Abstract == +This proposal defines a new transaction digest algorithm for signature verification in version 0 and version 1 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. + +== Motivation == +There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. <ref name=wiki>[https://en.bitcoin.it/wiki/OP_CHECKSIG]</ref> + +Unfortunately, there are at least 2 weaknesses in the original transaction digest algorithm: + +* For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n<sup>2</sup>) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). <ref>[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292]</ref><ref>[https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify]</ref><ref>[http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]</ref> +* The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. <ref>[https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]</ref> + +Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all. <ref>[https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki BIPx: Segregated Witness (Consensus layer)]</ref> + +== Specification == +A new transaction digest algorithm is defined, but only applicable to sigops in version 0 and version 1 witness program: + Double SHA256 of the serialization of: + 1. nVersion of the transaction + 2. hashPrevouts + 3. hashSequence + 4. transaction id and output index of the output spent by this input + 5. subscript of the input + 6. value of the output spent by this input + 7. nSequence of the input + 8. hashOutputs + 9. nLocktime of the transaction + 10. sighash type of the signature + +The items 1, 4, 5, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> + +The item 6 is a 8-byte value of the amount of bitcoin spent in this input. + +hashPrevouts: +*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all transaction ids and output indexes involved in this transaction; +*Otherwise, hashPrevouts is a uint256 of 0x0000......0000. + +hashSequence: +*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs; +*Otherwise, hashSequence is a uint256 of 0x0000......0000. + +hashOutputs: +*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output scriptPubKey with value; +*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output scriptPubKey with value of the same index as the input; +*Otherwise, hashOutputs is a uint256 of 0x0000......0000. + +The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n<sup>2</sup>) to O(n). + +Refer to the reference implementation, reproduced below, for the precise algorithm: + +<source lang="cpp"> + uint256 hashPrevouts; + uint256 hashSequence; + uint256 hashOutputs; + + if (!(nHashType & SIGHASH_ANYONECANPAY)) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].prevout; + } + hashPrevouts = ss.GetHash(); + } + + if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vin.size(); n++) { + ss << txTo.vin[n].nSequence; + } + hashSequence = ss.GetHash(); + } + + if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { + CHashWriter ss(SER_GETHASH, 0); + for (unsigned int n = 0; n < txTo.vout.size(); n++) { + ss << txTo.vout[n]; + } + hashOutputs = ss.GetHash(); + } else if ((nHashType & 0x1f) == SIGHASH_SINGLE && nIn < txTo.vout.size()) { + CHashWriter ss(SER_GETHASH, 0); + ss << txTo.vout[nIn]; + hashOutputs = ss.GetHash(); + } + + CHashWriter ss(SER_GETHASH, 0); + // Version + ss << txTo.nVersion; + // Input prevouts/nSequence (none/all, depending on flags) + ss << hashPrevouts; + ss << hashSequence; + // The input being signed (replacing the scriptSig with scriptCode + amount) + // The prevout may already be contained in hashPrevout, and the nSequence + // may already be contain in hashSequence. + ss << txTo.vin[nIn].prevout; + ss << static_cast<const CScriptBase&>(scriptCode); + ss << amount; + ss << txTo.vin[nIn].nSequence; + // Outputs (none/one/all, depending on flags) + ss << hashOutputs; + // Locktime + ss << txTo.nLockTime; + // Sighash type + ss << nHashType; + + return ss.GetHash(); +</source> + +== Deployment == + +This proposal is deployed with Segregated Witness softfork (BIP x) + +== Backward compatibility == + +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs, inculding the redefined sigops, as anyone-can-spend scripts. + +== Reference Implementation == + +https://github.com/sipa/bitcoin/commits/segwit + +== References == + +<references> + +== Copyright == + +This document is placed in the public domain. diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki new file mode 100644 index 0000000..ed8cf2b --- /dev/null +++ b/bip-0144.mediawiki @@ -0,0 +1,122 @@ +<pre> + BIP: 144 + Title: Segregated Witness (Peer Services) + Author: Eric Lombrozo <elombrozo@gmail.com> + Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-12 +</pre> + +==Abstract== +This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. + +==Motivation== +In addition to defining witness structures and requiring commitments in future blocks (BIPxxxx - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. + +==Specification== + +=== Serialization === +A new serialization format for tx messages is added to the peer-to-peer protocol. + +The serialization has the following structure: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Field Size +!Name +!Type +!Description +|- +| 4 +| version +| int32_t +| Transaction data format version +|- +| 1 +| marker +| char +| Must be zero +|- +| 1 +| flag +| char +| Must be nonzero +|- +| 1+ +| txin_count +| var_int +| Number of transaction inputs +|- +| 41+ +| txins +| txin[] +| A list of one or more transaction inputs +|- +| 1+ +| txout_count +| var_int +| Number of transaction outputs +|- +| 9+ +| txouts +| txouts[] +| A list of one or more transaction outputs +|- +| 1+ +| witness +| witness +| The witness structure as a serialized byte array +|- +| 4 +| lock_time +| uint32_t +| The block number or timestamp until which the transaction is locked +|} + +Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeeded, such a transaction would contain no inputs and a single output. + +If the witness is empty, the old serialization format should be used. + +Witness objects can be extended to contain other kinds of witness data not yet specified. This BIP is agnostic to the witness data structure, defined in BIPxxxx (Consensus Segwit BIP), and treats it as an arbitrary byte array. + +* '''Rationale for not having an independent message type with its own serialization''': this would require separate "tx" and "block" messages, and all RPC calls operating on raw transactions would need to be duplicated, or need inefficinent or nondeterministic guesswork to know which type is to be used. + +* '''Rationale for not using just a single 0x00 byte as marker''': that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data. + +* '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector. + +=== Handshake === +A new message 'havewitness' is sent after receiving 'verack' to +indicate that a node can provide witness if requested (similar to +'sendheaders') (Note: it might be better to signal this with a services bit in the version message) + +=== Hashes === +Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness +serialization. + +Support for a new hash including the witness data is added that is +computed from the new witness serialization. (Note that transactions +with an empty witness always use the old serialization, +and therefore, they have witness hash equal to normal hash.) + +<img src=bip-0144/witnesstx.png></img> + +=== Relay === +New inv types MSG_WITNESS_TX and MSG_WITNESS_BLOCK are added, only +for use in getdata. Inventory messages themselves still use just MSG_TX and MSG_BLOCK, +similar to MSG_FILTERED_BLOCK. + +* '''Rationale for not advertizing witnessness in invs''': we don't always use invs anymore (with 'sendheaders' BIP 130), plus it's not useful: implicitly, every transaction and block have a witness, old ones just have empty ones. + +MSG_WITNESS_TX getdata requests should use the non-witness serialized hash. The peer shall respond with a tx message, and if the witness structure is nonempty, the witness serialization shall be used. + +MSG_WITNESS_BLOCK requests will return a block message with transactions that have a witness using witness serialization. + +== Credits == +Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork. + +== Reference Implementation == +https://github.com/sipa/bitcoin/commits/segwit + +== Copyright == +This document is placed in the public domain. diff --git a/bip-0144/witnesstx.png b/bip-0144/witnesstx.png Binary files differnew file mode 100644 index 0000000..5fd8afc --- /dev/null +++ b/bip-0144/witnesstx.png |
