mirror of https://github.com/lukechilds/bips.git
Matt David
9 years ago
64 changed files with 5701 additions and 694 deletions
@ -0,0 +1,7 @@ |
|||
os: linux |
|||
language: generic |
|||
sudo: false |
|||
script: |
|||
- scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 |
|||
- diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true |
|||
- if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi |
@ -0,0 +1,223 @@ |
|||
<pre> |
|||
BIP: 2 |
|||
Title: BIP Status and Comments |
|||
Author: Luke Dashjr <luke+bip@dashjr.org> |
|||
Status: Draft |
|||
Type: Process |
|||
Created: 2016-02-03 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP describes objective criteria that can be used to determine when a BIP Status should be changed, to ensure it is a reliable metric documenting actual usage of the proposal. It also adds a way for final comment on completed BIPs, by adding to them a reference to a wiki page and summary of the tone thereof. Finally, it extends the list of allowable BIP licenses to include many more popular options. |
|||
|
|||
==Copyright== |
|||
|
|||
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. |
|||
|
|||
==BIP status field== |
|||
|
|||
===Specification=== |
|||
|
|||
Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. |
|||
|
|||
A BIP may only change status from Draft (or Rejected) to Accepted, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. |
|||
|
|||
BIPs should be changed from Draft or Accepted status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Accepted status if it meets the criteria required as described in the previous paragraph. |
|||
|
|||
An Accepted BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. |
|||
|
|||
When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. |
|||
|
|||
A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. |
|||
|
|||
====Progression to Final status==== |
|||
|
|||
See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. |
|||
|
|||
A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold. |
|||
|
|||
A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document). |
|||
|
|||
Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month. |
|||
|
|||
API/RPC and application layer BIPs must be implemented by at least two independent and compatible software applications. |
|||
|
|||
Software authors are encouraged to publish summaries of what BIPs their software supports to aid in verification of status changes. Good examples of this at the time of writing this BIP, can be observed in [https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md Bitcoin Core's doc/bips.md file] as well as [https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/README.specs Bitcoin Wallet for Android's wallet/README.specs file]. |
|||
|
|||
These criteria are considered objective ways to observe the de facto adoption of the BIP, and are not to be used as reasons to oppose or reject a BIP. Should a BIP become actually and unambiguously adopted despite not meeting the criteria outlined here, it should still be updated to Final status. |
|||
|
|||
===Rationale=== |
|||
|
|||
Why is this necessary at all? |
|||
|
|||
* BIP 1 defines an ambiguous criteria for the Status field of BIPs, which is often a source of confusion. As a result, many BIPs with significant real-world use have been left as Draft or Accepted status longer than appropriate. By giving objective criteria to judge the progression of BIPs, this proposal aims to help keep the Status accurate and up-to-date. |
|||
|
|||
How is the entire Bitcoin economy defined by people selling goods/services and holders? |
|||
|
|||
* For Bitcoin to function as a currency, it must be accepted as payment. Bitcoins have no value if you cannot acquire anything in exchange for them. If everyone accepting such payments requires a particular set of consensus rules, "bitcoins" are de facto defined by that set of rules - this is already the case today. If those consensus rules are expected to broaden (as with a hard-fork), those merchants need to accept payments made under the new set of rules, or they will reject "bitcoins" as invalid. Holders are relevant to the degree in that they choose the merchants they wish to spend their bitcoins with, and could also as a whole decide to sell under one set of consensus rules or the other, thus flooding the market with bitcoins and crashing the price. |
|||
|
|||
Why aren't <x> included in the economy? |
|||
|
|||
* Some entities may, to some degree, also be involved in offering goods and/or services in exchange for bitcoins, thus in that capacity (but not their capacity as <x>) be involved in the economy. |
|||
* Miners are not included in the economy, because they merely *rely on* others to sell/spend their otherwise-worthless mined produce. Therefore, they must accept everyone else's direction in deciding the consensus rules. |
|||
* Exchanges are not included in the economy, because they merely provide services of connecting the merchants and users who wish to trade. Even if all exchanges were to defect from Bitcoin, those merchants and users can always trade directly and/or establish their own exchanges. |
|||
* Developers are not included in the economy, since they merely write code, and it is up to others to decide to use that code or not. |
|||
|
|||
But they're doing something important and have invested a lot in Bitcoin! Shouldn't they be included in such an important decision? |
|||
|
|||
* This BIP does not aim to address what "should" be the basis of decisions. Such a statement, no matter how perfect in its justification, would be futile without some way to force others to use it. The BIP process does not aim to be a kind of forceful "governance" of Bitcoin, merely to provide a collaborative repository for proposing and providing information on standards, which people may voluntarily adopt or not. It can only hope to achieve accuracy in regard to the "Status" field by striving to reflect the reality of *how things actually are*, rather than *how they should be*. |
|||
|
|||
What if a single merchant wishes to block a hard-fork? |
|||
|
|||
* This BIP addresses only the progression of the BIP Status field, not the deployment of the hard-fork (or any other change) itself. |
|||
* Regardless, one shop cannot operate in a vacuum: if they are indeed alone, they will soon find themselves no longer selling in exchange for bitcoin payments, as nobody else would exist willing to use the previous blockchain to pay them. If they are no longer selling, they cease to meet the criteria herein which enables their veto. |
|||
|
|||
How about a small number of merchants (maybe only two) who sell products to each other? |
|||
|
|||
* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. |
|||
|
|||
How can economic agreement veto a soft-fork? |
|||
|
|||
* The group of miners is determined by the consensus rules for the dynamic-membership multi-party signature (for Bitcoin, the proof-of-work algorithm), which can be modified with a hard-fork. Thus, if the same conditions required to modify this group are met in opposition to a soft-fork, the miner majority supporting the soft-fork is effectively void because the economy can decide to replace them with another group of would-be miners who do not support the soft-fork. |
|||
|
|||
What happens if the economy decides to hard-fork away from a controversial soft-fork, more than three months later? |
|||
|
|||
* The controversial soft-fork, in this circumstance, changes from Final to Replaced status to reflect the nature of the hard-fork replacing the previous (final) soft-fork. |
|||
|
|||
What is the ideal percentage of listening nodes needed to adopt peer services proposals? |
|||
|
|||
* This is unknown, and set rather arbitrarily at this time. For a random selection of peers to have at least one other peer implementing the extension, 13% or more would be necessary, but nodes could continue to scan the network for such peers with perhaps some reasonable success. Furthermore, service bits exist to help identification upfront. |
|||
|
|||
Why is it necessary for at least two software projects to release an implementation of API/RPC and application layer BIPs, before they become Final? |
|||
|
|||
* If there is only one implementation of a specification, there is no other program for which a standard interface is used with or needed. |
|||
* Even if there are only two projects rather than more, some standard coordination between them exists. |
|||
|
|||
What if a BIP is proposed that only makes sense for a single specific project? |
|||
|
|||
* The BIP process exists for standardisation between independent projects. If something only affects one project, it should be done through that project's own internal processes, and never be proposed as a BIP in the first place. |
|||
|
|||
==BIP comments== |
|||
|
|||
===Specification=== |
|||
|
|||
Each BIP should, in its preamble, link to a Bitcoin Wiki page with a summary tone of the comments on that page. |
|||
Reviewers of the BIP who consider themselves qualified, should post their own comments on this wiki page in [https://www.mediawiki.org/wiki/Help:Talk_pages#Editing_conventions_on_talk_pages standard "Talk page" format]. |
|||
The comments page should generally only be used to post final comments for a completed BIP. |
|||
If a BIP is not yet completed, reviewers should instead post on the applicable development mailing list thread to allow the BIP author(s) to address any concerns or problems pointed out by the review. |
|||
|
|||
Some BIPs receive exposure outside the development community prior to completion, and other BIPs might not be completed at all. To avoid a situation where critical BIP reviews may go unnoticed during this period, reviewers may, at their option, still post their review on the comments page, provided they first post it to the mailing list and plan to later remove or revise it as applicable based on the completed version. Such revisions should be made by editing the previous review and updating the timestamp. Reviews made prior to the complete version may be removed if they are no longer applicable and have not been updated in a timely manner (eg, within one month). |
|||
|
|||
Pages must be named after the full BIP number (eg, "BIP 0001") and placed in the "BIP Comments" namespace. For example, the link for BIP 1 will be https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 . |
|||
|
|||
In order to avoid possible abuse of Bitcoin Wiki moderation, BIPs may choose to list a second forum for BIP comments, in addition to the Bitcoin Wiki. In this case, the second forum's URI should be listed below the Bitcoin Wiki's URI. |
|||
|
|||
Summary tones may be chosen from the following, but this BIP does not intend to cover all possible nuances: |
|||
|
|||
* No comments yet. |
|||
* Unanimously Recommended for implementation |
|||
* Unanimously Discourage for implementation |
|||
* Mostly Recommended for implementation, with some Discouragement |
|||
* Mostly Discouraged for implementation, with some Recommendation |
|||
|
|||
For example, the preamble to BIP 1 might be updated to include the line: |
|||
|
|||
Comments-Summary: No comments yet. |
|||
Comments-URI: https://en.bitcoin.it/wiki/BIP_Comments:BIP_0001 |
|||
https://some-other-wiki.org/BIP_1_Comments |
|||
|
|||
These fields must follow the "Discussions-To" header defined in BIP 1 (if that header is not present, it should follow the position where it would be present; generally this is immediately above the Status header). |
|||
|
|||
To avoid doubt: comments and status are unrelated metrics to judge a BIP, and neither should be directly influencing the other. |
|||
|
|||
===Rationale=== |
|||
|
|||
What is the purpose of BIP comments? |
|||
|
|||
* Various BIPs have been adopted (the criteria required for "Final" Status) despite being considered generally inadvisable. Some presently regard BIPs as a "good idea" simply by virtue of them being assigned a BIP number. Due to the low barrier of entry for submission of new BIPs, it seems advisable for a way for reviewers to express their opinions on them in a way that is consumable to the public without needing to review the entire development discussion. |
|||
|
|||
Will BIP comments be censored or limited to particular participants/"experts"? |
|||
|
|||
* The Bitcoin Wiki moderators have control over that venue and may make reasonable moderation attempts. Admitted non-experts should refrain from commenting outside of their area of knowledge. However, comments should not be censored, and participation should be open to the public. |
|||
* If the Bitcoin Wiki were to abuse its position, the venue for comments can always be changed. |
|||
|
|||
==BIP licensing== |
|||
|
|||
===Specification=== |
|||
|
|||
New BIPs may be accepted with the following licenses. Each new BIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respecitve abbreviation given below. |
|||
|
|||
For example, a preamble might include the following License header: |
|||
|
|||
License: BSD-2-Clause |
|||
GNU-All-Permissive |
|||
|
|||
In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. |
|||
|
|||
It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. |
|||
|
|||
For example, a preamble specifying the optional License-Code header might look like: |
|||
|
|||
License: BSD-2-Clause |
|||
GNU-All-Permissive |
|||
License-Code: GPL-2.0+ |
|||
|
|||
In this case, the code in the BIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. |
|||
If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. |
|||
For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). |
|||
|
|||
License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable. |
|||
License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*. |
|||
License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable. |
|||
License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*. |
|||
|
|||
In the event that the text or code is not available under common license terms, the list should instead be replaced with the single term "Complex", and full details provided in the Copyright section of the BIP. |
|||
|
|||
====Recommended licenses==== |
|||
|
|||
* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] |
|||
* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license] |
|||
* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] |
|||
* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] |
|||
|
|||
In addition, it is recommended that literal code included in the BIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for Bitcoin Core would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the BIP text. |
|||
|
|||
====Not recommended, but acceptable licenses==== |
|||
|
|||
* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] |
|||
* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0] |
|||
* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International] |
|||
* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] |
|||
* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license] |
|||
* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer] |
|||
* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3] |
|||
* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer] |
|||
* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] |
|||
* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0] |
|||
|
|||
Additionally, PD is used to express that the work is placed in the public domain. |
|||
This may not be used for new BIPs, and is only defined for use by BIPs predating acceptance of this BIP. |
|||
|
|||
===Rationale=== |
|||
|
|||
BIP 1 allowed the Open Publication License or releasing into the public domain; was this insufficient? |
|||
|
|||
* The OPL is generally regarded as obsolete, and not a license suitable for new publications. |
|||
* Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms. |
|||
* Public domain is not universally recognised as a legitimate action, thus it is inadvisable. |
|||
|
|||
Why are there software licenses included? |
|||
|
|||
* Some BIPs, especially consensus layer, may include literal code in the BIP itself which may not be available under the exact license terms of the BIP. |
|||
* Despite this, not all software licenses would be acceptable for content included in BIPs. |
|||
|
|||
Why is Public Domain no longer acceptable for new BIPs? |
|||
|
|||
* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the BIP simply copyrighted with no redistribution or modification allowed at all. |
|||
|
|||
==See Also== |
|||
|
|||
* [[bip-0001.mediawiki|BIP 1: BIP Purpose and Guidelines]] |
|||
* [[bip-0123.mediawiki|BIP 123: BIP Classification]] |
|||
* [https://tools.ietf.org/html/rfc7282 RFC 7282: On Consensus and Humming in the IETF] |
After Width: | Height: | Size: 30 KiB |
File diff suppressed because it is too large
After Width: | Height: | Size: 6.2 KiB |
@ -0,0 +1,62 @@ |
|||
<pre> |
|||
BIP: 74 |
|||
Title: Allow zero value OP_RETURN in Payment Protocol |
|||
Author: Toby Padilla <tobypadilla@gmail.com> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2016-01-29 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. |
|||
|
|||
==Motivation== |
|||
|
|||
The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed. |
|||
|
|||
While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever. |
|||
|
|||
This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored. |
|||
|
|||
In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible. |
|||
|
|||
While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers. |
|||
|
|||
By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application. |
|||
|
|||
An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP. |
|||
|
|||
Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions. |
|||
|
|||
==Specification== |
|||
|
|||
The specification for this BIP is straightforward. BIP70 should be fully implemented with the following changes: |
|||
|
|||
* Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet. |
|||
|
|||
BIP70 has special handling for the case with multiple zero value outputs: |
|||
|
|||
<blockquote> |
|||
If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). |
|||
</blockquote> |
|||
|
|||
This behavior should be retained with the exception of OP_RETURN handling. In the case of a multiple output transaction where the sum of the output values is zero, the user should be prompted for a value and that value should be distributed over any or all outputs ''except'' the OP_RETURN output. In the case where the sum of outputs.amount is non-zero then any OP_RETURN outputs should not be ignored but no value should be assigned to them. |
|||
|
|||
Payment requests also must contain at least one payable output (i.e. no payment requests with ''just'' an OP_RETURN). |
|||
|
|||
==Rationale== |
|||
|
|||
As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage. |
|||
|
|||
As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data. |
|||
|
|||
This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage. |
|||
|
|||
==Compatibility== |
|||
|
|||
Since this BIP still supports OP_RETURN statements with a greater than zero value, it should be fully backwards compatible with any existing implementations. |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
@ -0,0 +1,75 @@ |
|||
<pre> |
|||
BIP: 80 |
|||
Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets |
|||
Author: Justus Ranvier <justus@opentransactions.org> |
|||
Jimmy Song <jimmy@monetas.net> |
|||
Status: Draft |
|||
Type: Informational |
|||
Created: 2014-08-11 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP defines a logical hierarchy for non-colored voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). |
|||
|
|||
This BIP is a particular application of BIP43 and is based on BIP44. |
|||
|
|||
==Motivation== |
|||
|
|||
The hierarchy proposed in this paper allows the handling of multiple coins and multiple series from a single seed. |
|||
|
|||
==Path levels== |
|||
|
|||
We define the following 4 levels in BIP32 path: |
|||
|
|||
<pre> |
|||
m / purpose' / coin_type' / series' / address_index |
|||
</pre> |
|||
|
|||
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 following the BIP43 recommendation to: the ASCII value of "80" with the most signifigant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification. |
|||
|
|||
Hardened derivation is used at this level. |
|||
|
|||
===Coin type=== |
|||
|
|||
One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages. |
|||
|
|||
This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues. |
|||
|
|||
Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44. |
|||
|
|||
Hardened derivation is used at this level. |
|||
|
|||
===Series=== |
|||
|
|||
Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals. |
|||
|
|||
Hardened derivation is used at this level. |
|||
|
|||
===Index=== |
|||
|
|||
Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. |
|||
|
|||
Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. |
|||
|
|||
Public derivation is used at this level. |
|||
|
|||
==Compatible wallets== |
|||
|
|||
* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
|||
|
|||
==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]] |
@ -0,0 +1,72 @@ |
|||
<pre> |
|||
BIP: 81 |
|||
Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets |
|||
Author: Justus Ranvier <justus@opentransactions.org> |
|||
Jimmy Song <jimmy@monetas.net> |
|||
Status: Draft |
|||
Type: Informational |
|||
Created: 2014-08-11 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). |
|||
|
|||
This BIP is a particular application of BIP43 and is based on BIP44. |
|||
|
|||
==Motivation== |
|||
|
|||
The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed. |
|||
|
|||
==Path levels== |
|||
|
|||
We define the following 8 levels in BIP32 path: |
|||
|
|||
<pre> |
|||
m / purpose' / series' / (5 color definition levels) / address_index |
|||
</pre> |
|||
|
|||
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 following the BIP43 recommendation to: the ASCII value of "81" with the most signifigant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification. |
|||
|
|||
Hardened derivation is used at this level. |
|||
|
|||
===Color Definition=== |
|||
|
|||
Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits). |
|||
|
|||
Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used. |
|||
|
|||
Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function. |
|||
|
|||
The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels |
|||
|
|||
Public derivation is used at these levels, even when the index exceeds 2^31. |
|||
|
|||
===Index=== |
|||
|
|||
Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. |
|||
|
|||
Public keys obtained at this level of the heirarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract. |
|||
|
|||
Public derivation is used at this level. |
|||
|
|||
==Compatible wallets== |
|||
|
|||
* [[https://github.com/btcsuite/btcwallet|btcwallet]] is the reference Bitcoin wallet for voting pools. |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
|||
|
|||
==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]] |
|||
* [[bip-0080.mediawiki|BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets]] |
@ -0,0 +1,92 @@ |
|||
<pre> |
|||
BIP: 83 |
|||
Title: Dynamic Hierarchical Deterministic Key Trees |
|||
Author: Eric Lombrozo <eric@ciphrex.com> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2015-11-16 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP defines a scheme for key derivation that allows for dynamic creation of key hierarchies based on the algorithm described in BIP32. |
|||
|
|||
==Motivation== |
|||
|
|||
Several proposals have been made to try to standardize a structure for hierarchical deterministic wallets for the sake of interoperability (reference BIP32, BIP44, BIP45). However, all proposals to date have tried to impose a specific structure upfront without providing any flexibility for dynamic creation of new hierarchical levels with different semantics or mapping between different applications that use distinct structures. |
|||
|
|||
Instead of attempting to impose a specific structure upfront, this BIP proposes that we design the derivation in such a way that we can continue extending hierarchies arbitrarily and indefinitely. |
|||
|
|||
==Specification== |
|||
|
|||
BIP32 provides a hierarchical derivation scheme where every node in the tree can be either used to derive child nodes or used as a signing key for ECDSA. This means that as soon as we choose to use a node as a signing key, we can no longer derive children from that node. To draw an analogy to file systems, each node is either a file or a directory but never both. However, given the need to predictably know the location of new children, it is generally not a good idea to mix both signing keys and parent nodes at the same level in the hierarchy. This means that as soon as we've decided that a particular level in the hierarchy is to be used for signing keys, we've lost the ability to nest deeper levels into the tree. |
|||
|
|||
At every level of the hierarchy, we reserve the child with index 0 to allow further nesting, and for signing key parent nodes use child indices 1 to MAX_INDEX (2<sup>31</sup> - 1) for signing keys. We can use either hardened or nonhardened derivation. |
|||
|
|||
Let p denote a specific signing key parent node and k be an index greater than 0. The children signing keys are then: |
|||
|
|||
p / k |
|||
|
|||
with k > 0. |
|||
|
|||
To create sublevels, we derive the nested nodes: |
|||
|
|||
p / 0 / n |
|||
|
|||
with n ≥ 0. |
|||
|
|||
Each of these nodes can now contain signing key children of their own, and again we reserve index 0 to allow deeper nesting. |
|||
|
|||
==Notation== |
|||
|
|||
We propose the following shorthand for writing nested node derivations: |
|||
|
|||
p // n instead of p / 0 / n |
|||
|
|||
p //' n instead of p / 0' / n |
|||
|
|||
==Mappings== |
|||
|
|||
Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. |
|||
|
|||
Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. |
|||
|
|||
==Use Cases== |
|||
|
|||
===Account Hierarchies=== |
|||
|
|||
For all that follows, we assume that key indices k > 0 and parent node indices n ≥ 0. |
|||
|
|||
From a master seed m, we can construct a default account using the following derivations for nonhardened signing keys: |
|||
|
|||
m / 1 / k (for change/internal outputs) |
|||
|
|||
m / 2 / k (for invoice/external outputs) |
|||
|
|||
To create subaccount a<sub>n</sub>, we use: |
|||
|
|||
a<sub>n</sub> = m // n |
|||
|
|||
To generate keys for subaccount a<sub>n</sub>, we use: |
|||
|
|||
a<sub>n</sub> / 1 / k (for change/internal outputs) |
|||
|
|||
a<sub>n</sub> / 2 / k (for invoice/external outputs) |
|||
|
|||
We can continue creating subaccounts indefinitely using this scheme. |
|||
|
|||
===Bidirectional Payment Channels=== |
|||
|
|||
In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain. |
|||
|
|||
By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. |
|||
|
|||
==References== |
|||
|
|||
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] |
|||
* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
|||
|
@ -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. |
@ -0,0 +1,83 @@ |
|||
<pre> |
|||
BIP: 107 |
|||
Title: Dynamic limit on the block size |
|||
Author: 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 propagation 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 augment 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 will 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 distance 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 opportunities 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== |
|||
Similar deployment model to BIP101: |
|||
<blockquote>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.</blockquote> |
|||
|
|||
==Acknowledgements== |
|||
|
|||
Thanks to Austin Williams, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments. |
|||
|
|||
==Copyright== |
|||
|
|||
This work is placed in the public domain. |
@ -0,0 +1,82 @@ |
|||
<pre> |
|||
BIP: 109 |
|||
Title: Two million byte size limit with sigop and sighash limits |
|||
Author: Gavin Andresen <gavinandresen@gmail.com> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2016-01-28 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing. |
|||
|
|||
==Motivation== |
|||
|
|||
# Continue current economic policy. |
|||
# Exercise hard fork network upgrade. |
|||
# Mitigate potential CPU exhaustion attacks |
|||
|
|||
==Specification== |
|||
|
|||
=== MAX_BLOCK_SIZE increased to 2,000,000 bytes === |
|||
|
|||
The maximum number of bytes in a canonically serialized block shall be increased from |
|||
1,000,000 bytes to 2,000,000 bytes. |
|||
|
|||
=== Switch to accurately-counted sigop limit of 20,000 per block === |
|||
|
|||
The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained, |
|||
but only ECDSA verifications actually performed to validate the block shall be counted. |
|||
|
|||
In particular: |
|||
|
|||
* The coinbase scriptSig is not counted |
|||
* Signature operations in un-executed branches of a Script are not counted |
|||
* OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top of the execution stack, it is counted as one signature operation. If it is satisfied by the public key nearest the bottom of the execution stack, it is counted as twenty signature operations. |
|||
* Signature operations involving invalidly encoded signatures or public keys are not counted towards the limit |
|||
|
|||
=== Add a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per block === |
|||
|
|||
The amount of data hashed to compute signature hashes is limited to 1,300,000,000 bytes per block. The same rules for counting are used as for counting signature operations. |
|||
|
|||
=== Activation: 75% hashpower support trigger, followed by 28-day 'grace period' === |
|||
|
|||
Solo miners or mining pool operators express their support for this BIP by setting the fourth-highest-bit in the block's 32-bit version number (0x10000000 in hex). The first block with that bit set, a timestamp less than or equal to the expiration time, and with at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) with that bit set, shall define the beginning of a grace period. Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall be subject to the new limits. |
|||
|
|||
As always, miners are expected to use their best judgement for what is best for the entire Bitcoin ecosystem when making decisions about what consensus-level changes to support. |
|||
|
|||
=== Expiration: 1-Jan-2018 === |
|||
|
|||
If this BIP is not triggered before 1-Jan-2018 00:00:00 GMT it should be considered withdrawn. |
|||
|
|||
Miners that support this BIP should set bit 0x10000000 in the block version until 1-Jan-2018. After that date, that bit can be safely re-used for future consensus rule upgrades. |
|||
|
|||
==Backward compatibility== |
|||
|
|||
Fully validating older clients are not compatible with this change. |
|||
The first block exceeding the old limits on block size or inaccurately counted signature operations will partition older clients off the new network. |
|||
|
|||
SPV (simple payment validation) wallets are compatible with this change. |
|||
|
|||
==Rationale== |
|||
|
|||
In the short term, an increase is needed to handle increasing transaction volume. |
|||
|
|||
The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software. |
|||
|
|||
The choices of constants for the deployment scheme were motivated by prior experience with upgrades to the Bitcoin consensus rules: |
|||
|
|||
* 0x10000000 was chosen to be compatible with the BIP 9 proposal for parallel deployment of soft forks |
|||
* 75% was chosen instead of 95% to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion. |
|||
* A four-week grace period after the voting period was chosen as a balance between giving people sufficient time to upgrade and keeping people's attention on the urgent need to upgrade. |
|||
|
|||
==Implementation== |
|||
|
|||
https://github.com/gavinandresen/bitcoin-git/tree/two_mb_bump |
|||
|
|||
See also http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork |
|||
|
|||
==Copyright== |
|||
|
|||
This work is placed in the public domain. |
@ -0,0 +1,124 @@ |
|||
<pre> |
|||
BIP: 122 |
|||
Title: URI scheme for Blockchain references / exploration |
|||
Author: Marco Pontello <marcopon@gmail.com> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2015-08-29 |
|||
Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP proposes a URI scheme for looking up blocks, transactions and 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 allows the user to choose from a set of alternatives. |
|||
Resorting to copy + paste into a browser is often required. |
|||
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>]/<tx|block|address>/<hash></nowiki> |
|||
|
|||
Where: |
|||
|
|||
{| class="wikitable" |
|||
! style="text-align: center;" | Element |
|||
! colspan="2" style="text-align: center;" | Description |
|||
! Required? |
|||
|- |
|||
| 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" | required |
|||
|- |
|||
| 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. |
|||
| required |
|||
|} |
|||
|
|||
====ABNF grammar==== |
|||
|
|||
<pre> |
|||
blockchainuri = "blockchain:" ["//" chain] "/" object |
|||
object = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) / |
|||
("address" "/" address) |
|||
chain = hash |
|||
hash = 64HEXDIG |
|||
blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" int. |
|||
address = base58 ; https://en.wikipedia.org/wiki/Base58 |
|||
</pre> |
|||
|
|||
---- |
|||
===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) developers which need to reference Blockchain data, using this scheme mean that he can simply make it a `blockchain:` link 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 schema, the first time the user visit their website, or launch/install the application, or even set themselves if there isn't already one. |
|||
|
|||
Users can link directly to their preferred block explorer (avoiding copy + paste which can be awkward on mobile devices). |
|||
|
|||
== Sample implementation == |
|||
|
|||
[https://github.com/MarcoPon/blockchain-exploration Demo Blockchain: URI handler on GitHub] |
|||
|
|||
==Acknowledgements== |
|||
|
|||
Thanks to Btc Drak for suggesting support for different networks and Jorge Timon for the suggestion that we could identify each network by its genesis block hash. |
|||
Thanks to Richard Moore, Matt Whitlock, Andreas Schildbach for help with the structure and hierarchy of the URI scheme. |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
After Width: | Height: | Size: 2.9 KiB |
@ -0,0 +1,123 @@ |
|||
<pre> |
|||
BIP: 124 |
|||
Title: Hierarchical Deterministic Script Templates |
|||
Author: Eric Lombrozo <eric@ciphrex.com> |
|||
William Swanson <swansontec@gmail.com> |
|||
Status: Draft |
|||
Type: Informational |
|||
Created: 2015-11-20 |
|||
Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32. |
|||
|
|||
==Motivation== |
|||
|
|||
Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts. |
|||
|
|||
In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs. |
|||
|
|||
This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32. |
|||
|
|||
==Specification== |
|||
|
|||
===Keys=== |
|||
|
|||
An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation: |
|||
|
|||
'''A'''<sub>k</sub> = (derivation path for A)/k |
|||
|
|||
===Key Groups=== |
|||
|
|||
Let '''m'''<sub>i</sub> denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k: |
|||
|
|||
{'''K'''<sub>k</sub>} = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k, ..., '''m'''<sub>n</sub>/k } |
|||
|
|||
Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy. |
|||
|
|||
===Sorting=== |
|||
|
|||
We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...) |
|||
|
|||
Define {'''K'''<sub>k</sub>}<sub>j</sub> to be the jth element of the sorted keys for derivation index k. |
|||
|
|||
===Script Templates=== |
|||
|
|||
We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation: |
|||
|
|||
''Script''('''A''') = opcodes ['''A'''] opcodes |
|||
|
|||
We extend this notation to an arbitrary number of placeholders: |
|||
|
|||
''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes |
|||
|
|||
We introduce the following convenient notation for sorted key groups: |
|||
|
|||
[{'''K'''<sub>k</sub>}] = [{'''K'''<sub>k</sub>}<sub>1</sub>] [{'''K'''<sub>k</sub>}<sub>2</sub>] ... [{'''K'''<sub>k</sub>}<sub>n</sub>] |
|||
|
|||
===Operations on Keys=== |
|||
|
|||
In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''<sub>k</sub>. We can use the following notation: |
|||
|
|||
[''Hash160''('''A'''<sub>k</sub>)] |
|||
|
|||
===Encoding=== |
|||
|
|||
TODO |
|||
|
|||
==Examples== |
|||
|
|||
===2-of-3 Multisig=== |
|||
|
|||
The script template is defined by: |
|||
|
|||
''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG |
|||
|
|||
Letting '''K'''<sub>k</sub> = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''<sub>k</sub>}). |
|||
|
|||
===1-of-1 or 2-of-3=== |
|||
|
|||
The script template is defined by: |
|||
|
|||
''Script''('''A''', '''B''') = <br> |
|||
OP_DUP ['''A'''] OP_CHECKSIG<br> |
|||
OP_NOTIF<br> |
|||
2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY <br> |
|||
OP_NOTIF<br> |
|||
OP_ENDIF<br> |
|||
OP_TRUE<br> |
|||
|
|||
Let '''M'''<sub>k</sub> = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''<sub>k</sub>} be a key group of three users that can only authorize transactions if at least two of them agree. |
|||
|
|||
The ''k''th script is given by ''Script''('''M'''<sub>k</sub>, {'''K'''<sub>k</sub>}). |
|||
|
|||
===Timelocked Contract=== |
|||
|
|||
The output is payable to Alice immediately if she knows the private key for '''A'''<sub>k</sub>. Bob must know the private key for '''B'''<sub>k</sub> and also wait for a timeout '''t''' before being able to spend the output. |
|||
|
|||
The script template is defined by: |
|||
|
|||
''Script''('''A''', '''B''', '''T''') = <br> |
|||
OP_IF <br> |
|||
OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG <br> |
|||
OP_ELSE <br> |
|||
['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP <br> |
|||
OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG <br> |
|||
OP_ENDIF |
|||
|
|||
The ''k''th script with timeout '''t''' is given by ''Script''('''A'''<sub>k</sub>, '''B'''<sub>k</sub>, '''t'''). |
|||
|
|||
==References== |
|||
|
|||
* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] |
|||
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] |
|||
* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]] |
|||
* [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]] |
|||
* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
|||
|
@ -0,0 +1,188 @@ |
|||
<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. |
@ -0,0 +1,102 @@ |
|||
<pre> |
|||
BIP: 131 |
|||
Title: "Coalescing Transaction" Specification (wildcard inputs) |
|||
Author: Chris Priest <cp368202@ohiou.edu> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2015-11-30 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This specification defines a new type of transaction that supplements (not replaces) |
|||
normal "non coalescing" bitcoin transactions. |
|||
|
|||
==Motivation== |
|||
|
|||
Normal "non-coalescing" Bitcoin Transactions have one large inefficiency: When you want to spend |
|||
from multiple inputs with the exact same scriptPubKey, you have to list each |
|||
input separately, along with the same signature multiple times, even though the signature expresses the same information. |
|||
This bloats the transaction size and makes it expensive to spend from small value inputs. |
|||
|
|||
Because small value inputs are expensive to send, they remain in the UTXO pool |
|||
which full nodes have to keep around. It is believed that long term increase of the UTXO |
|||
set can have negative scaling consequences on the network. |
|||
|
|||
If maximum blocksize is made to increase *slower* than the actual number of transactions bitcoin users are sending |
|||
to the network, this problem is projected to get worse. In other words, as transaction |
|||
fees increase, the minimum economical value of a spending a UTXO will increase. |
|||
|
|||
==Specification== |
|||
|
|||
=== Redefinition of Transaction version === |
|||
|
|||
First, this BIP redefines the version field on transactions. The first four bytes |
|||
are defined as the version number, while the last four bytes are defined as the |
|||
transaction type. Type "0000" denotes normal transactions, and "0001" defines |
|||
coalescing transaction. |
|||
|
|||
Examples: |
|||
|
|||
version 1 transaction with normal inputs: |
|||
version: 10000000 |
|||
|
|||
version 2 transaction with normal inputs: |
|||
version: 20000000 |
|||
|
|||
version 2 transaction with coalescing inputs: |
|||
version: 20000001 |
|||
|
|||
Essentially the last bit in the version field is set to 1 to enable wildcard inputs for all |
|||
inputs present in the transaction. |
|||
|
|||
=== Wildcard inputs === |
|||
|
|||
A coalescing transaction is formulated the exact same way as a version 1 transaction |
|||
with one exception: each input is treated as a "wildcard input". |
|||
|
|||
A wildcard input beings the value of all inputs with the exact same scriptPubKey |
|||
in a block lower or equal to the block the wildcard input is confirmed into. |
|||
|
|||
== Changes needed to implement == |
|||
|
|||
The bitcoin code needs to be modified in three places in order to handle Coalescing Transactions. |
|||
|
|||
1. <b>Full Node Coalescing validation</b> - When a full node receives a coalescing transaction, it has to |
|||
aggregate the value of all the UTXOs in the blockchain older than the input |
|||
with the same scriptPubKey. If this value is greater than or equal to the |
|||
amount of all outputs, then that coalescing transaction is valid and can be propagated. |
|||
|
|||
2. <b>Full Node Non-Coalescing validation</b> - When a non-coalescing transaction comes in, the code needs to be modified |
|||
to check if each input has not been spent by a coalescing transaction. If there exist any |
|||
coalescing transaction in the blockchain with the same scriptPubKey found in a block *after* that input, |
|||
then the UTXO has been spent and the transaction is invalid. |
|||
|
|||
3. <b>Wallet</b> - The user facing wallet portion of the reference client should notify |
|||
the user when their wallet contains many UTXOs that qualify it to benefit from |
|||
a coalescing transaction. Wallets should not simply replace non-coalescing transactions |
|||
with coalescing transactions in all instances. |
|||
|
|||
== Isn't this BIP bad because it encourage address re-use? == |
|||
|
|||
Address re-use comes in two forms: re-use by the ''sender'', and re-use by the ''receiver''. |
|||
|
|||
Re-use by the sender is basically using the same address for the change output. This is generally considered bad |
|||
since people looking through your transaction history can determine who you do business with. When |
|||
you generate a new address for every change, your privacy is conserved as it is impossible to know which |
|||
output is a recipient, and which output is the change output. This BIP has '''no effect''' on re-use |
|||
by the sender. |
|||
|
|||
On the other hand, address re-use by the ''receiver'' occurs under completely different circumstances. |
|||
When you publish an address and have multiple people send to that address, you are engaging in address re-use |
|||
from the receiver. This activity has historically been considered bad because it leads to re-using a private key. |
|||
When you re-use a private key too many times, you run the risk of an attacker performing statistical analysis |
|||
on the multiple signatures, which can lead to an attacker finding out your private key. |
|||
|
|||
This BIP introduces a way to spend multiple inputs ''without'' re-using the private key. In a sense, this BIP |
|||
fixes the problem that makes address re-use bad for the receiver. After this BIP becomes implemented |
|||
and deployed, address re-use by the receiver will no longer be considered bad form. |
|||
|
|||
==Copyright== |
|||
|
|||
This document is placed in the public domain. |
@ -0,0 +1,117 @@ |
|||
<pre> |
|||
BIP: 132 |
|||
Title: Committee-based BIP Acceptance Process |
|||
Author: Andy Chase <theandychase@gmail.com> |
|||
Status: Draft |
|||
Type: Process |
|||
Created: 2015-08-31 |
|||
</pre> |
|||
|
|||
== Abstract == |
|||
|
|||
The current process for accepting a BIP is not clearly defined. While [https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki BIP-0001] defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected. |
|||
|
|||
This proposal sets up a method for determining BIP acceptance. |
|||
|
|||
This BIP has two parts: |
|||
|
|||
* It sets up a '''process''' which a BIP goes through for comments and acceptance. The Process is: |
|||
** BIP Draft |
|||
** Submitted for comments (2 weeks) |
|||
** Waiting on opinion (2 weeks) |
|||
** BIP becomes either Accepted or Deferred |
|||
* It sets up '''committees''' for reviewing comments and indicating acceptance under precise conditions. |
|||
** Committees are authorized groups that represent client authors, miners, merchants, and users (each as a segment). Each one must represent at least 1% stake in the Bitcoin ecosystem. |
|||
|
|||
BIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments. |
|||
|
|||
== Copyright == |
|||
|
|||
This document is placed into the public domain. |
|||
|
|||
== Motivation == |
|||
|
|||
BIPs represent important improvements to Bitcoin infrastructure, and in order to foster continued innovation, the BIP process must have clearly defined stages and acceptance acknowledgement. |
|||
|
|||
== Rationale == |
|||
|
|||
A committee system is used to organize the essential concerns of each segment of the Bitcoin ecosystem. Although each segment may have many different viewpoints on each BIP, in order to seek a decisive yes/no on a BIP, a representational authoritative structure is sought. This structure should be fluid, allowing people to move away from committees that do not reflect their views and should be re-validated on each BIP evaluation. |
|||
|
|||
== Weaknesses == |
|||
|
|||
Each committee submits a declaration including their claim to represent a certain percentage of the Bitcoin ecosystem in some way. Though guidelines are given, it's up to each committee to prove their stake, and it's up to the reader of the opinions to decide if a BIP was truly accepted or rejected. |
|||
|
|||
The author doesn't believe this is a problem because a BIP cannot be forced on client authors, miners, merchants, or users. Ultimately this BIP is a tool for determining whether a BIP is overwhelmingly accepted. If one committee's validity claim becomes the factor that decides whether the BIP will succeed or fail, this process simply didn't return a clear answer and the BIP should be considered deferred. |
|||
|
|||
== Process == |
|||
|
|||
* '''Submit for Comments.''' The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Dev Mailing List] mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments. |
|||
** The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments. |
|||
* '''Comments.''' |
|||
** After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal. |
|||
* '''Reported Opinions.''' |
|||
** After the waiting period has past, committees must submit a summary of the comments which they have received from their represented communities. |
|||
** The deadline for this opinion is four weeks after the BIP was submitted for comments. |
|||
** Committees cannot reverse their decision after the deadline, but at their request may flag their decision as "likely to change if another submit for comments is called". Committees can change their decision if a resubmit is called. |
|||
** Opinions must include: |
|||
*** One of the following statements: "Intend to accept", "Intent to implement", "Decline to accept", "Intend to accept, but decline to implement". |
|||
*** If rejected, the opinion must cite clear and specific reasons for rejecting including a checklist for what must happen or be change for their committee to accept the proposal. |
|||
*** If accepted, the committee must list why they accepted the proposal and also include concerns they have or what about the BIP that, if things changed, would cause the committee to likely reverse their decision if another submit for comments was called. |
|||
* '''Accepted.''' |
|||
** If at least 70% of the represented percentage stake in 3 out of 4 segments accept a proposal, the BIP is considered accepted. |
|||
** If a committee fails to submit an opinion, consider the opinion "Decline to accept". |
|||
** The BIP cannot be substantially changed at this point, but can be replaced. Minor changes or clarifications are allowed but must be recorded in the document. |
|||
* '''Deferred.''' |
|||
** If the acceptance test above is not met, the BIP is sent back into suggestions. |
|||
** BIP can be modified and re-submitted for a comments no sooner than two months after the date of the previous submit for comments is called. |
|||
** The BIP is marked rejected after two failed submission attempts. A rejected BIP can still be modified and re-submitted. |
|||
|
|||
== Committees == |
|||
|
|||
'''BIP Committees.''' |
|||
|
|||
* BIP Committees are representational structures that represent critical segments of the Bitcoin ecosystem. |
|||
* Each committee must prove and maintain a clear claim that they represent at least 1% of the Bitcoin ecosystem in some form. |
|||
* If an organization or community does not meet that requirement, it should conglomerate itself with other communities and organizations so that it does. |
|||
* The segments that committees can be based around are: |
|||
** Bitcoin software |
|||
** Exchanges/Merchants/services/payment processors |
|||
** Mining operators |
|||
** User communities |
|||
* A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment. |
|||
|
|||
'''Committee Declarations.''' |
|||
* At any point, a Committee Declaration can be posted. |
|||
* This Declaration must contain details about: |
|||
** The segment the Committee is representing |
|||
** Who the committee claim to represent and it's compositional makeup (if made up of multiple miner orgs, user orgs, companies, clients, etc). |
|||
** Proof of claim and minimum 1% stake via: |
|||
*** Software: proof of ownership and user base (Min 1% of Bitcoin userbase) |
|||
*** Merchant: proof of economic activity (Min 1% of Bitcoin economic activity) |
|||
*** Mining: proof of work (Min 1% of Hashpower) |
|||
*** For a user organization, auditable signatures qualifies for a valid committee (Min 1% of Bitcoin userbase) |
|||
** Who is running the committee, their names and roles |
|||
** How represented members can submit comments to the committee |
|||
** A code of conduct and code of ethics which the committee promises to abide by |
|||
* A committee declaration is accepted if: |
|||
** The declaration includes all of the required elements |
|||
** The stake is considered valid |
|||
** Committee validation is considered when considering the results of opinions submitted by committee on a BIP. A committee must have met the required stake percentage before a BIP is submitted for comments, and have maintained that stake until a valid opinion is submitted. |
|||
* Committees can dissolve at any time or submit a declaration at any time |
|||
* Declaration must have been submitted no later than the third day following a BIP's request for comments to be eligible for inclusion in a BIP |
|||
|
|||
== BIP Process Management Role == |
|||
|
|||
BIPs, Opinions, and Committee Declaration must be public at all times. |
|||
|
|||
A BIP Process Manager should be chosen who is in charge of: |
|||
|
|||
* Declaring where and how BIPs, Opinions, and Committee Declaration should be posted and updated officially. |
|||
* Maintaining the security and authenticity of BIPs, Opinions, and Committee Declarations |
|||
* Publishing advisory documents about what kinds of proof of stakes are valid and what kinds should be rejected. |
|||
* Naming a series of successors for the roles of the BIP Process Manager and BIP Editor (BIP-001) as needed. |
|||
|
|||
== Conditions for activation == |
|||
|
|||
In order for this process BIP to become active, it must succeed by its own rules. At least a 4% sample of the Bitcoin community must be represented, with at least one committee in each segment included. Once at least one committee has submitted a declaration, a request for comments will be called and the process should be completed from there. |
|||
|
@ -0,0 +1,48 @@ |
|||
<pre> |
|||
BIP: 133 |
|||
Title: feefilter message |
|||
Author: Alex Morcos <morcos@chaincode.com> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2016-02-13 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. |
|||
|
|||
==Motivation== |
|||
|
|||
The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. |
|||
|
|||
However, there are limitations to the effectiveness of these approaches. The reject filter is reset after every block which means transactions that are inv'ed over a longer time period will be rerequested and there is no method to prevent requesting the transaction the first time. Furthermore, inv data is sent at least once either to or from each peer for every transaction accepted to the mempool and there is no mechanism by which to know that an inv sent to a given peer would not result in a getdata request because it represents a transaction with too little fee. |
|||
|
|||
After receiving a feefilter message, a node can know before sending an inv that a given transaction's fee rate is below the minimum currently required by a given peer, and therefore the node can skip relaying an inv for that transaction to that peer. |
|||
|
|||
==Specification== |
|||
|
|||
# The feefilter message is defined as a message containing an int64_t where pchCommand == "feefilter" |
|||
# Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte. |
|||
# The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters. |
|||
# Inv's generated from a mempool message are also subject to a fee filter if it exists. |
|||
# Feature discovery is enabled by checking protocol version >= 70013 |
|||
|
|||
==Considerations== |
|||
The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to a node's mempool are not relayed by this node and the functionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited. |
|||
|
|||
Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool. |
|||
|
|||
There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times. |
|||
|
|||
If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider disabling the fee filter to make sure it is exposed to all possible txid's. |
|||
|
|||
==Backward compatibility== |
|||
|
|||
Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages. |
|||
|
|||
==Implementation== |
|||
|
|||
https://github.com/bitcoin/bitcoin/pull/7542 |
|||
|
|||
==Copyright== |
|||
This document is placed in the public domain. |
@ -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. |
@ -0,0 +1,288 @@ |
|||
<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 signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki 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. For example, a new transaction digest algorithm for transaction signature verification is described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP143] |
|||
|
|||
==Specification== |
|||
|
|||
=== Transaction ID === |
|||
|
|||
A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs. |
|||
|
|||
Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format: |
|||
|
|||
[nVersion][txins][txouts][nLockTime] |
|||
|
|||
A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: |
|||
|
|||
[nVersion][marker][flag][txins][txouts][witness][nLockTime] |
|||
|
|||
Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization. |
|||
|
|||
The <code>marker</code> MUST be <code>0x00</code>. |
|||
|
|||
The <code>flag</code> MUST be a 1-byte non-zero value. Currently, <code>0x01</code> MUST be used. |
|||
|
|||
The <code>witness</code> is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a <code>var_int</code> to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a <code>var_int</code> to indicate the length. Witness data is NOT script. |
|||
|
|||
A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a <code>0x00</code>. If all txins are not witness program, a transaction's <code>wtxid</code> is equal to its <code>txid</code>. |
|||
|
|||
=== Commitment structure === |
|||
|
|||
A new block rule is added which requires a commitment to the <code>wtxid</code>. The <code>wtxid</code> of coinbase transaction is assumed to be <code>0x0000....0000</code>. |
|||
|
|||
A witness root hash is calculated with all those <code>wtxid</code> as leaves, in a way similar to the hashMerkleRoot in the block header. |
|||
|
|||
The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: |
|||
|
|||
1-byte - OP_RETURN (0x6a) |
|||
1-byte - Push the following 36 bytes (0x24) |
|||
4-byte - Commitment header (0xaa21a9ed) |
|||
32-byte - Commitment hash: Double-SHA256(witness root hash|witness nonce) |
|||
|
|||
39th byte onwards: Optional data with no consensus meaning |
|||
|
|||
and the coinbase's input's witness must consist of a single 32-byte array for the witness nonce. |
|||
|
|||
If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment. |
|||
|
|||
=== 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". |
|||
|
|||
There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: |
|||
# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty. |
|||
# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript. |
|||
|
|||
If the version byte is 0, and the witness program is 20 bytes: |
|||
* It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program. |
|||
* The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key. |
|||
* The HASH160 of the public key must match the 20-byte witness program. |
|||
* After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack. |
|||
|
|||
If the version byte is 0, and the witness program is 32 bytes: |
|||
* It is interpreted as a pay-to-witness-script-hash (P2WSH) program. |
|||
* The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript"). |
|||
* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program. |
|||
* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item). |
|||
* The script must not fail, and result in exactly a single TRUE on the stack. |
|||
|
|||
If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail. |
|||
|
|||
If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness. These versions are reserved for future extensions. |
|||
|
|||
=== Other consensus critical limits === |
|||
|
|||
==== Block size ==== |
|||
|
|||
Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows: |
|||
|
|||
''Block cost'' is defined. The cost of each byte in the existing header and transactions is 4, while the cost of each byte in witness data is 1. |
|||
|
|||
The new rule is total ''block cost'' ≤ 4,000,000. |
|||
|
|||
==== Sigops ==== |
|||
|
|||
Sigops per block is currently limited to 20,000. We change this restriction as follows: |
|||
|
|||
''Sigop cost'' is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1. |
|||
|
|||
The new rule is total ''sigop cost'' ≤ 80,000. |
|||
|
|||
== Examples == |
|||
|
|||
=== P2WPKH witness program === |
|||
|
|||
The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program: |
|||
|
|||
witness: <signature> <pubkey> |
|||
scriptSig: (empty) |
|||
scriptPubKey: 0 <20-byte-hash> |
|||
(0x0014{20-byte-hash}) |
|||
|
|||
The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program. |
|||
|
|||
The signature is verified as |
|||
|
|||
<signature> <pubkey> CHECKSIG |
|||
|
|||
Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness. |
|||
|
|||
=== P2WSH witness program === |
|||
|
|||
The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program. |
|||
|
|||
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> |
|||
scriptSig: (empty) |
|||
scriptPubKey: 0 <32-byte-hash> |
|||
(0x0020{32-byte-hash}) |
|||
|
|||
The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WSH type. The last item in the witness (the "witnessScript") is popped off, hashed with SHA256, compared against the 32-byte-hash in scriptPubKey, and deserialized: |
|||
|
|||
1 <pubkey1> <pubkey2> 2 CHECKMULTISIG |
|||
|
|||
The script is executed with the remaining data from witness: |
|||
|
|||
0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG |
|||
|
|||
A P2WSH 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 BIP16 P2SH. The increased size improves security against possible collision attacks, as 2<sup>80</sup> work is not infeasible anymore (By the end of 2015, 2<sup>84</sup> hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness. |
|||
|
|||
=== Witness program nested in BIP16 P2SH === |
|||
|
|||
The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output. |
|||
|
|||
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> |
|||
scriptSig: <0 <32-byte-hash>> |
|||
(0x0020{32-byte-hash}) |
|||
scriptPubKey: HASH160 <20-byte-hash> EQUAL |
|||
(0xA914{20-byte-hash}87) |
|||
|
|||
The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash in scriptPubKey, and interpreted as: |
|||
|
|||
0 <32-byte-hash> |
|||
|
|||
The P2WSH witness program is then executed as described in the previous example. |
|||
|
|||
Comparing with the previous 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. |
|||
|
|||
=== Extensible commitment structure === |
|||
|
|||
The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in |
|||
coinbase becomes: |
|||
|
|||
Double-SHA256(Witness root hash|Hash(new commitment|witness nonce)) |
|||
|
|||
For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way. |
|||
|
|||
Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness nonce to preserve the ability to do upgrades of the Bitcoin consensus protocol. |
|||
|
|||
The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose. |
|||
|
|||
=== 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. |
|||
|
|||
Extra witness data can be committed that allows short proofs of block invalidity that SPV nodes can quickly verify: |
|||
|
|||
# Sum trees for transaction fee can be committed making it possible to construct short proofs that the miner does not add excessive fees to the coinbase transaction. Similar for the block size and sigop count limit. |
|||
# 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. |
|||
|
|||
These commitments could be included in the extensible commitment structure 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. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 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 where the witness programs are equal to 0, which the script must fail). 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 and upgraded wallets with traditional P2PKH address (without any benefit of segregated witness) |
|||
* Sending bitcoin to upgraded wallets using a P2SH address |
|||
* Sending bitcoin to upgraded wallets using a native witness program through [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] payment protocol |
|||
|
|||
'''What a non-upgraded wallet cannot do''' |
|||
|
|||
* Validating segregated witness transaction. It assumes such a transaction is always valid |
|||
|
|||
== 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 |
|||
|
|||
== References == |
|||
|
|||
*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] |
|||
*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for Version 0 Witness Program]] |
|||
*[[bip-0144.mediawiki|BIP144 Segregated Witness (Peer Services)]] |
|||
|
|||
== Copyright == |
|||
|
|||
This document is placed in the public domain. |
@ -0,0 +1,153 @@ |
|||
<pre> |
|||
BIP: 142 |
|||
Title: Address Format for Segregated Witness |
|||
Author: Johnson Lau <jl2012@xbt.hk> |
|||
Status: Deferred |
|||
Type: Standards Track |
|||
Created: 2015-12-24 |
|||
</pre> |
|||
|
|||
== Abstract == |
|||
|
|||
This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program. |
|||
|
|||
== Motivation == |
|||
|
|||
To define standard payment address for native segregated witness (segwit) transactions to promote early adoption of the more efficient transaction method. |
|||
|
|||
== Specification == |
|||
|
|||
The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH). |
|||
|
|||
The new address is encoded in a way similar to existing address formats: |
|||
|
|||
base58-encode: |
|||
[1-byte address version] |
|||
[1-byte witness program version] |
|||
[0x00] |
|||
[20/32-byte-hash] |
|||
[4-byte checksum] |
|||
|
|||
For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address. |
|||
|
|||
For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address. |
|||
|
|||
The witness program version is a 1-byte value between 0 (0x00) and 16 (0x10). Only version 0 is defined in BIP141. Versions 1 to 16 are reserved for future extensions. |
|||
|
|||
Following the witness program version is a 0x00 padding to make sure that each witness program version will have a unique prefix. |
|||
|
|||
Following the padding is the program hash, 20 byte for a P2WPKH address and 32 byte for a P2WSH address. |
|||
|
|||
The 4-byte checksum is the first four bytes of the double SHA256 hash of the serialization of the previous items. |
|||
|
|||
All addresses generated with this scheme will have a constant length, with 36 digits for 20-byte and 53 digits for 32-byte. Different witness program versions will have a unique prefix, as shown in the following table: |
|||
|
|||
{|class="wikitable" style="text-align: center;" |
|||
|- |
|||
!rowspan=3 style=""|Witness program version |
|||
!colspan=4 style=""|Hash size |
|||
|- |
|||
!colspan=2 style=""|20-byte (36 characters) |
|||
!colspan=2 style=""|32-byte (53 characters) |
|||
|- |
|||
!Mainnet |
|||
!Testnet |
|||
!Mainnet |
|||
!Testnet |
|||
|- |
|||
|0||p2||QW||7Xh||T7n |
|||
|- |
|||
|1||p4||QY||7Xq||T7w |
|||
|- |
|||
|2||p6||Qa||7Xz||T85 |
|||
|- |
|||
|3||p7||Qc||7Y9||T8E |
|||
|- |
|||
|4||pA||Qe||7YH||T8N |
|||
|- |
|||
|5||pB||Qf||7YS||T8X |
|||
|- |
|||
|6||pD||Qh||7Ya||T8g |
|||
|- |
|||
|7||pF||Qj||7Yj||T8p |
|||
|- |
|||
|8||pG||Qm||7Yt||T8y |
|||
|- |
|||
|9||pJ||Qn||7Z2||T97 |
|||
|- |
|||
|10||pL||Qp||7ZB||T9G |
|||
|- |
|||
|11||pN||Qr||7ZK||T9Q |
|||
|- |
|||
|12||pQ||Qt||7ZU||T9Z |
|||
|- |
|||
|13||pS||Qv||7Zc||T9i |
|||
|- |
|||
|14||pT||Qw||7Zm||T9r |
|||
|- |
|||
|15||pV||Qy||7Zv||TA1 |
|||
|- |
|||
|16||pX||R1||7a4||TA9 |
|||
|- |
|||
|} |
|||
|
|||
|
|||
== Rationale == |
|||
|
|||
BIP141 defines 2 ways of encoding a "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; |
|||
* Segwit-in-P2SH is a BIP16 P2SH redeemScript with a push of version byte followed by a push of witness program, while the scriptPubKey looks like a normal P2SH output. |
|||
|
|||
Considering the BIP13 P2SH address has been defined in 2012, using segwit-in-P2SH allows most existing wallets to pay a segwit-compatible wallet without any upgrade. However, this method requires more block space 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 method of payment. |
|||
|
|||
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. It is believed that the proposed P2WPKH and P2WSH address format 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. |
|||
|
|||
While P2WPKH address is specific for simple payment to a single public key, P2WSH address allows arbitrarily complex segwit transactions, similar to the BIP13 P2SH address. |
|||
|
|||
== Compatibility == |
|||
|
|||
This proposal is not backward-compatible. However, an older implementation will report the new address type as invalid, and refuse to create a transaction. |
|||
|
|||
This proposal is forward-compatible with future versions of witness programs of 20 and 32 bytes. |
|||
|
|||
== Example == |
|||
|
|||
The following public key, |
|||
|
|||
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 |
|||
|
|||
when encoded as a P2PKH template, would become: |
|||
|
|||
DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG |
|||
|
|||
With the corresponding version 1 Bitcoin address being: |
|||
|
|||
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM |
|||
|
|||
When the same public key is encoded as P2WPKH, the scriptPubKey becomes: |
|||
|
|||
OP_0 <010966776006953D5567439E5E39F86A0D273BEE> |
|||
|
|||
Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is: |
|||
|
|||
p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm |
|||
|
|||
== Reference implementation == |
|||
|
|||
https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80 |
|||
|
|||
== References == |
|||
|
|||
* [[bip-0013.mediawiki|BIP 13: Address Format for pay-to-script-hash]] |
|||
* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash]] |
|||
* [[bip-0070.mediawiki|BIP 70: Payment Protocol]] |
|||
* [[bip-0141.mediawiki|BIP 141: Segregated Witness]] |
|||
|
|||
== Copyright == |
|||
This work is placed in the public domain. |
@ -0,0 +1,204 @@ |
|||
<pre> |
|||
BIP: 143 |
|||
Title: Transaction Signature Verification for Version 0 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 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/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141: Segregated Witness (Consensus layer)]</ref> |
|||
|
|||
== Specification == |
|||
A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program: |
|||
Double SHA256 of the serialization of: |
|||
1. nVersion of the transaction (4-byte little endian) |
|||
2. hashPrevouts (32-byte hash) |
|||
3. hashSequence (32-byte hash) |
|||
4. outpoint (32-byte hash + 4-byte little endian) |
|||
5. scriptCode of the input (varInt for the length + script) |
|||
6. value of the output spent by this input (8-byte little endian) |
|||
7. nSequence of the input (4-byte little endian) |
|||
8. hashOutputs (32-byte hash) |
|||
9. nLocktime of the transaction (4-byte little endian) |
|||
10. sighash type of the signature (4-byte little endian) |
|||
|
|||
All components in the original algorithm, including the behavior <code>OP_CODESEPERATOR</code>, remains unchanged. The only difference is the way of serialization and the inclusion of amount being spent. |
|||
|
|||
The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. <ref name=wiki></ref> |
|||
|
|||
The item 5: |
|||
*For P2WPKH witness program, the scriptCode is <code>0x1976a914{20-byte-pubkey-hash}88ac</code>. |
|||
*For P2WSH witness program, |
|||
**if the <code>witnessScript</code> does not contain any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is a <code>varInt</code> for the length of the <code>witnessScript</code>, followed by the <code>witnessScript</code>. |
|||
**if the <code>witnessScript</code> contains any <code>OP_CODESEPERATOR</code>, the <code>scriptCode</code> is the evaluated script, with all <code>OP_CODESEPARATOR</code> and everything up to the last <code>OP_CODESEPARATOR</code> before the signature checking opcode being executed removed, and prepended by a <code>varInt</code> for the length of the truncated script. |
|||
|
|||
The item 6 is a 8-byte value of the amount of bitcoin spent in this input. |
|||
|
|||
<code>hashPrevouts</code>: |
|||
*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints; |
|||
*Otherwise, <code>hashPrevouts</code> is a <code>uint256</code> of <code>0x0000......0000</code>. |
|||
|
|||
<code>hashSequence</code>: |
|||
*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, <code>hashSequence</code> is a <code>uint256</code> of <code>0x0000......0000</code>. |
|||
|
|||
<code>hashOutputs</code>: |
|||
*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (<code>varInt</code> for the length + script); |
|||
*If sighash type is SINGLE and the input index is not greater than the number of outputs, <code>hashOutputs</code> is the double SHA256 of the output value with <code>scriptPubKey</code> of the same index as the input; |
|||
*Otherwise, <code>hashOutputs</code> is a <code>uint256</code> of <code>0x0000......0000</code>. |
|||
|
|||
The <code>hashPrevouts</code>, <code>hashSequence</code>, and <code>hashOutputs</code> 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> |
|||
|
|||
== Example == |
|||
|
|||
|
|||
The following is an unsigned transaction: |
|||
0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 |
|||
|
|||
nVersion: 01000000 |
|||
txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff |
|||
ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff |
|||
txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac |
|||
9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac |
|||
nLockTime: 11000000 |
|||
|
|||
The first input comes from an ordinary P2PK: |
|||
scriptPubKey: 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 |
|||
|
|||
The second input comes from a P2WPKH witness program: |
|||
scriptPubKey: 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 |
|||
|
|||
To sign it with a nHashType of 1 (SIGHASH_ALL): |
|||
|
|||
hashPrevouts: |
|||
dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000) |
|||
= 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 |
|||
|
|||
hashSequence: |
|||
dSHA256(eeffffffffffffff) |
|||
= 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b |
|||
|
|||
hashOutputs: |
|||
dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac) |
|||
= 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 |
|||
|
|||
hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 |
|||
|
|||
nVersion: 01000000 |
|||
hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 |
|||
hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b |
|||
outpoint: ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000 |
|||
scriptCode: 1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac |
|||
amount: 0046c32300000000 |
|||
nSequence: ffffffff |
|||
hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 |
|||
nLockTime: 11000000 |
|||
nHashType: 01000000 |
|||
|
|||
sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 |
|||
signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee |
|||
|
|||
The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 |
|||
|
|||
nVersion: 01000000 |
|||
marker: 00 |
|||
flag: 01 |
|||
txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff |
|||
ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff |
|||
txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac |
|||
9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac |
|||
witness 00 |
|||
02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 |
|||
nLockTime: 11000000 |
|||
|
|||
The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BIP144: Segregated Witness (Peer Services)]]</ref> |
|||
== Deployment == |
|||
|
|||
This proposal is deployed with Segregated Witness softfork (BIP 141) |
|||
|
|||
== 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. |
@ -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: 2016-01-08 |
|||
</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 ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - 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+ |
|||
| script_witnesses |
|||
| script_witnesses[] |
|||
| 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 succeed, such a transaction would contain no inputs and a single output. |
|||
|
|||
If the witness is empty, the old serialization format should be used. |
|||
|
|||
Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. |
|||
|
|||
* '''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. |
After Width: | Height: | Size: 18 KiB |
@ -0,0 +1,96 @@ |
|||
<pre> |
|||
BIP: 145 |
|||
Title: getblocktemplate Updates for Segregated Witness |
|||
Author: Luke Dashjr <luke+bip22@dashjr.org> |
|||
Status: Draft |
|||
Type: Standards Track |
|||
Created: 2016-01-30 |
|||
</pre> |
|||
|
|||
==Abstract== |
|||
|
|||
This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]]. |
|||
|
|||
==Specification== |
|||
|
|||
===Block Template=== |
|||
|
|||
The template Object is revised to include these keys: |
|||
|
|||
{| class="wikitable" |
|||
!colspan=4| template |
|||
|- |
|||
! Key !! Required !! Type !! Description |
|||
|- |
|||
| costlimit || {{No}} || Number || total cost allowed in blocks |
|||
|- |
|||
| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4 |
|||
|- |
|||
| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5) |
|||
|} |
|||
|
|||
====Transactions Object Format==== |
|||
|
|||
The Objects listed in the response's "transactions" key is revised to include these keys: |
|||
|
|||
{| class="wikitable" |
|||
!colspan=3|template "transactions" element |
|||
|- |
|||
! Key !! Type !! Description |
|||
|- |
|||
| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data |
|||
|- |
|||
| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves |
|||
|- |
|||
| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal |
|||
|} |
|||
|
|||
Transactions with witness data may only be included if the template's block version is at least 5. |
|||
|
|||
===Block Assembly with Witness Transactions=== |
|||
|
|||
When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously. |
|||
|
|||
When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction. |
|||
|
|||
Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern. |
|||
|
|||
==Motivation== |
|||
|
|||
Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient. |
|||
It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well. |
|||
|
|||
==Rationale== |
|||
|
|||
Why doesn't "costlimit" simply redefine the existing "sizelimit"? |
|||
* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys. |
|||
* Servers may wish to limit the overall size of a block, independently from the "cost" of the block. |
|||
|
|||
Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added? |
|||
* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used. |
|||
|
|||
Why is "sigoplimit" divided by 4? |
|||
* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?) |
|||
|
|||
Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else? |
|||
* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it. |
|||
|
|||
Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data? |
|||
* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment. |
|||
* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose. |
|||
* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data. |
|||
|
|||
==Reference Implementation== |
|||
|
|||
* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker] |
|||
* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool] |
|||
* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core] |
|||
|
|||
==See Also== |
|||
* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]] |
|||
* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]] |
|||
* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]] |
|||
|
|||
==Copyright== |
|||
|
|||
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license. |
@ -0,0 +1,136 @@ |
|||
#!/usr/bin/perl |
|||
use strict; |
|||
use warnings; |
|||
|
|||
my $topbip = 9999; |
|||
|
|||
my %RequiredFields = ( |
|||
BIP => undef, |
|||
Title => undef, |
|||
Author => undef, |
|||
Status => undef, |
|||
Type => undef, |
|||
Created => undef, |
|||
); |
|||
my %MayHaveMulti = ( |
|||
Author => undef, |
|||
'Post-History' => undef, |
|||
); |
|||
my %DateField = ( |
|||
Created => undef, |
|||
); |
|||
my %EmailField = ( |
|||
Author => undef, |
|||
Editor => undef, |
|||
); |
|||
my %MiscField = ( |
|||
'Post-History' => undef, |
|||
); |
|||
|
|||
my %ValidLayer = ( |
|||
Process => undef, |
|||
); |
|||
my %ValidStatus = ( |
|||
Draft => undef, |
|||
Deferred => undef, |
|||
Accepted => "background-color: #ffffcf", |
|||
Rejected => "background-color: #ffcfcf", |
|||
Withdrawn => "background-color: #ffcfcf", |
|||
Final => "background-color: #cfffcf", |
|||
Active => "background-color: #cfffcf", |
|||
Replaced => "background-color: #ffcfcf", |
|||
); |
|||
my %ValidType = ( |
|||
'Standards Track' => 'Standard', |
|||
'Informational' => undef, |
|||
'Process' => undef, |
|||
); |
|||
|
|||
my %emails; |
|||
|
|||
my $bipnum = 0; |
|||
while (++$bipnum <= $topbip) { |
|||
my $fn = sprintf "bip-%04d.mediawiki", $bipnum; |
|||
-e $fn || next; |
|||
open my $F, "<$fn"; |
|||
while (<$F> !~ m[^(?:\xef\xbb\xbf)?<pre>$]) { |
|||
die "No <pre> in $fn" if eof $F; |
|||
} |
|||
my %found; |
|||
my ($title, $author, $status, $type); |
|||
my ($field, $val); |
|||
while (<$F>) { |
|||
m[^</pre>$] && last; |
|||
if (m[^ ([\w-]+)\: (.*\S)$]) { |
|||
$field = $1; |
|||
$val = $2; |
|||
die "Duplicate $field field in $fn" if exists $found{$field}; |
|||
} elsif (m[^ ( +)(.*\S)$]) { |
|||
die "Continuation of non-field in $fn" unless defined $field; |
|||
die "Too many spaces in $fn" if length $1 != 2 + length $field; |
|||
die "Not allowed for multi-value in $fn" unless exists $MayHaveMulti{$field}; |
|||
$val = $2; |
|||
} else { |
|||
die "Bad line in $fn preamble"; |
|||
} |
|||
++$found{$field}; |
|||
die "Extra spaces in $fn" if $val =~ /^\s/; |
|||
if ($field eq 'BIP') { |
|||
die "$fn claims to be BIP $val" if $val ne $bipnum; |
|||
} elsif ($field eq 'Title') { |
|||
$title = $val; |
|||
} elsif ($field eq 'Author') { |
|||
$val =~ m/^(\S[^<@>]*\S) \<([^@>]*\@[\w.]+\.\w+)\>$/ or die "Malformed Author line in $fn"; |
|||
my ($authorname, $authoremail) = ($1, $2); |
|||
$authoremail =~ s/(?<=\D)$bipnum(?=\D)/<BIPNUM>/g; |
|||
$emails{$authorname}->{$authoremail} = undef; |
|||
if (defined $author) { |
|||
$author .= ", $authorname"; |
|||
} else { |
|||
$author = $authorname; |
|||
} |
|||
} elsif ($field eq 'Status') { |
|||
if ($bipnum == 38) { # HACK |
|||
$val =~ s/\s+\(.*\)$//; |
|||
} |
|||
die "Invalid status in $fn" unless exists $ValidStatus{$val}; |
|||
$status = $val; |
|||
} elsif ($field eq 'Type') { |
|||
die "Invalid type in $fn" unless exists $ValidType{$val}; |
|||
if (defined $ValidType{$val}) { |
|||
$type = $ValidType{$val}; |
|||
} else { |
|||
$type = $val; |
|||
} |
|||
} elsif ($field eq 'Layer') { # BIP 123 |
|||
die "Invalid layer $val in $fn" unless exists $ValidLayer{$val}; |
|||
} elsif (exists $DateField{$field}) { |
|||
die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/; |
|||
} elsif (exists $EmailField{$field}) { |
|||
$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn"; |
|||
} elsif (not exists $MiscField{$field}) { |
|||
die "Unknown field $field in $fn"; |
|||
} |
|||
} |
|||
for my $field (keys %RequiredFields) { |
|||
die "Missing $field in $fn" unless $found{$field}; |
|||
} |
|||
print "|-"; |
|||
if (defined $ValidStatus{$status}) { |
|||
print " style=\"" . $ValidStatus{$status} . "\""; |
|||
} |
|||
print "\n"; |
|||
print "| [[${fn}|${bipnum}]]\n"; |
|||
print "| ${title}\n"; |
|||
print "| ${author}\n"; |
|||
print "| ${type}\n"; |
|||
print "| ${status}\n"; |
|||
close $F; |
|||
} |
|||
|
|||
for my $author (sort keys %emails) { |
|||
my @emails = sort keys %{$emails{$author}}; |
|||
my $email_count = @emails; |
|||
next unless $email_count > 1; |
|||
warn "NOTE: $author has $email_count email addresses: @emails\n"; |
|||
} |
Loading…
Reference in new issue