diff --git a/README b/README deleted file mode 100644 index e87a4913..00000000 --- a/README +++ /dev/null @@ -1,3 +0,0 @@ -Bitcoin Improvement Proposals - -See BIP 0001 for more information. diff --git a/README.mediawiki b/README.mediawiki new file mode 100644 index 00000000..ea9783a7 --- /dev/null +++ b/README.mediawiki @@ -0,0 +1,264 @@ +People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. + +We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. + +Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community. + +Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]). + +{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Number +!Title +!Owner +!Type +!Status +|- style="background-color: #cfffcf" +| [[bip-0001.mediawiki|1]] +| BIP Purpose and Guidelines +| Amir Taaki +| Standard +| Active +|- +| [[bip-0010.mediawiki|10]] +| Multi-Sig Transaction Distribution +| Alan Reiner +| Informational +| Draft +|- style="background-color: #cfffcf" +| [[bip-0011.mediawiki|11]] +| M-of-N Standard Transactions +| Gavin Andresen +| Standard +| Accepted +|- style="background-color: #ffcfcf" +| [[bip-0012.mediawiki|12]] +| OP_EVAL +| Gavin Andresen +| Standard +| Withdrawn +|- style="background-color: #cfffcf" +| [[bip-0013.mediawiki|13]] +| Address Format for pay-to-script-hash +| Gavin Andresen +| Standard +| Final +|- style="background-color: #cfffcf" +| [[bip-0014.mediawiki|14]] +| Protocol Version and User Agent +| Amir Taaki, Patrick Strateman +| Standard +| Accepted +|- style="background-color: #ffcfcf" +| [[bip-0015.mediawiki|15]] +| Aliases +| Amir Taaki +| Standard +| Deferred +|- style="background-color: #cfffcf" +| [[bip-0016.mediawiki|16]] +| Pay To Script Hash +| Gavin Andresen +| Standard +| Final +|- style="background-color: #ffcfcf" +| [[bip-0017.mediawiki|17]] +| OP_CHECKHASHVERIFY (CHV) +| Luke Dashjr +| Withdrawn +| Draft +|- +| [[bip-0018.mediawiki|18]] +| hashScriptCheck +| Luke Dashjr +| Standard +| Draft +|- +| [[bip-0019.mediawiki|19]] +| M-of-N Standard Transactions (Low SigOp) +| Luke Dashjr +| Standard +| Draft +|- style="background-color: #ffcfcf" +| [[bip-0020.mediawiki|20]] +| URI Scheme +| Luke Dashjr +| Standard +| Replaced +|- style="background-color: #cfffcf" +| [[bip-0021.mediawiki|21]] +| URI Scheme +| Nils Schneider, Matt Corallo +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0022.mediawiki|22]] +| getblocktemplate - Fundamentals +| Luke Dashjr +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0023.mediawiki|23]] +| getblocktemplate - Pooled Mining +| Luke Dashjr +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0030.mediawiki|30]] +| Duplicate transactions +| Pieter Wuille +| Standard +| Final +|- style="background-color: #cfffcf" +| [[bip-0031.mediawiki|31]] +| Pong message +| Mike Hearn +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0032.mediawiki|32]] +| Hierarchical Deterministic Wallets +| Pieter Wuille +| Informational +| Accepted +|- +| [[bip-0033.mediawiki|33]] +| Stratized Nodes +| Amir Taaki +| Standard +| Draft +|- style="background-color: #cfffcf" +| [[bip-0034.mediawiki|34]] +| Block v2, Height in coinbase +| Gavin Andresen +| Standard +| Accepted +|- style="background-color: #cfffcf" +| [[bip-0035.mediawiki|35]] +| mempool message +| Jeff Garzik +| Standard +| Accepted +|- +| [[bip-0036.mediawiki|36]] +| Custom Services +| Stefan Thomas +| Standard +| Draft +|- style="background-color: #cfffcf" +| [[bip-0037.mediawiki|37]] +| Bloom filtering +| Mike Hearn and Matt Corallo +| Standard +| Accepted +|- +| [[bip-0038.mediawiki|38]] +| Passphrase-protected private key +| Mike Caldwell +| Standard +| Draft +|- +| [[bip-0039.mediawiki|39]] +| Mnemonic code for generating deterministic keys +| Slush +| Standard +| Draft +|- +| 40 +| Stratum wire protocol +| Slush +| Standard +| BIP number allocated +|- +| 41 +| Stratum mining protocol +| Slush +| Standard +| BIP number allocated +|- +| [[bip-0042.mediawiki|42]] +| A finite monetary supply for Bitcoin +| Pieter Wuille +| Standard +| Draft +|- +| [[bip-0043.mediawiki|43]] +| Purpose Field for Deterministic Wallets +| Slush +| Standard +| Draft +|- +| [[bip-0044.mediawiki|44]] +| Multi-Account Hierarchy for Deterministic Wallets +| Slush +| Standard +| Draft +|- +| [[bip-0045.mediawiki|45]] +| Structure for Deterministic P2SH Multisignature Wallets +| Manuel Araoz +| Standard +| Draft +|- +| [[bip-0050.mediawiki|50]] +| March 2013 Chain Fork Post-Mortem +| Gavin Andresen +| Informational +| Draft + +|- +| [[bip-0060.mediawiki|60]] +| Fixed Length "version" Message (Relay-Transactions Field) +| Amir Taaki +| Standard +| Draft +|- +| [[bip-0061.mediawiki|61]] +| "reject" P2P message +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0062.mediawiki|62]] +| Dealing with malleability +| Pieter Wuille +| Standard +| Draft +|- +| 63 +| Stealth Addresses +| Peter Todd +| Standard +| BIP number allocated +|- +| [[bip-0064.mediawiki|64]] +| getutxos message +| Mike Hearn +| Standard +| Draft +|- +| [[bip-0070.mediawiki|70]] +| Payment protocol +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0071.mediawiki|71]] +| Payment protocol MIME types +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0072.mediawiki|72]] +| Payment protocol URIs +| Gavin Andresen +| Standard +| Final +|- +| [[bip-0073.mediawiki|73]] +| Use "Accept" header with Payment Request URLs +| Stephen Pair +| Standard +| Draft +|} + + diff --git a/bip-0001.md b/bip-0001.mediawiki similarity index 81% rename from bip-0001.md rename to bip-0001.mediawiki index 433126b1..5c8a544f 100644 --- a/bip-0001.md +++ b/bip-0001.mediawiki @@ -1,10 +1,9 @@ 
   BIP: 1
   Title: BIP Purpose and Guidelines
-  Author: Amir Taaki 
-  Status: Active
+  Status: Accepted
   Type: Standards Track
-  Created: 19-08-2011
+  Created: 2011-08-19
==What is a BIP?== @@ -13,37 +12,36 @@ BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providin We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. -Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal -. +Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. ==BIP Types== There are three kinds of BIP: -* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validitity rules, or any change or addition that affects the interoperability of applications using Bitcoin. +* A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. * An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice. * A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP. ==BIP Work Flow== -The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to (no cross-posting please). Also see BIP Editor Responsibilities & Workflow below. +The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focussed the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocussed or too broad. If in doubt, split your BIP into several well-focussed ones. +The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. -Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum or the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list is the best way to go about this. +Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this. Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. -Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. +Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. -If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and create and create a page for it on the [[Bitcoin_Improvement_Proposals|Bitcoin Wiki]]. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. +If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. -The BIP author may update the Draft as necessary on the wiki. +The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests. Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. -BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page, etc. BIP authors should use their discretion here. +BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. @@ -57,7 +55,7 @@ BIPs can also be superseded by a different BIP, rendering the original obsolete. The possible paths of the status of BIPs are as follows: -[[File:bip-0001-1.png]] + Some Informational and Process BIPs may also have a status of "Active" if they are never meant to be completed. E.g. BIP 1 (this BIP). @@ -69,9 +67,9 @@ Each BIP should have the following parts: * Abstract -- a short (~200 word) description of the technical issue being addressed. -* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License [7]. +* Copyright/public domain -- Each BIP must either be explicitly labelled as placed in the public domain (see this BIP as an example) or licensed under the Open Publication License. -* Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). +* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). * Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright. @@ -87,7 +85,7 @@ Each BIP should have the following parts: ==BIP Formats and Templates== -BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP. +BIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that BIP. ==BIP Header Preamble== @@ -101,7 +99,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe Status: Type: - Created: + Created: * Post-History: * Replaces: * Superseded-By: @@ -126,7 +124,7 @@ While a BIP is in private discussions (usually during the initial Draft phase), The Type header specifies the type of BIP: Standards Track, Informational, or Process. -The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. +The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. @@ -139,10 +137,15 @@ BIPs may include auxiliary files such as diagrams. Such files must be named BIP- It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP. -If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor . If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). -BIP Editor Responsibilities & Workflow +If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :). -A BIP editor must subscribe to the list. All BIP-related correspondence should be sent (or CC'd) to (but please do not cross-post!). +==BIP Editors== + +The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]]. + +==BIP Editor Responsibilities & Workflow== + +A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com. For each new BIP that comes in an editor does the following: @@ -156,9 +159,9 @@ Once the BIP is ready for the repository, the BIP editor will: * Assign a BIP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141). -* List the BIP in BIP 0 (in two places: the categorized list, and the numeric list). +* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub. -* Add the BIP to the wiki. +* List the BIP in [[README.mediawiki]] * Send email back to the BIP author with next steps (post to bitcoin mailing list). @@ -168,5 +171,4 @@ The editors don't pass judgement on BIPs. We merely do the administrative & edit ==History== -This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the Bitcoin editors or the forums at bitcointalk.org. - +This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Improvement Process, and should not be bothered with technical questions specific to Bitcoin or the BIP process. Please direct all comments to the BIP editors or the Bitcoin development mailing list. diff --git a/bip-0001-1.png b/bip-0001/process.png similarity index 100% rename from bip-0001-1.png rename to bip-0001/process.png diff --git a/bip-0010.md b/bip-0010.md deleted file mode 100644 index bd96ed6b..00000000 --- a/bip-0010.md +++ /dev/null @@ -1,98 +0,0 @@ -
-  BIP: 10
-  Title: Multi-Sig Transaction Distribution
-  Author: Alan Reiner  
-  Status: Draft 
-  Type: Informational
-  Created: 28-10-2011
-
- -A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the final, proposed transaction, and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction. - -This BIP describes a protocol to standardize the representation of proposal transactions and the subsequent collection of signatures to execute multi-signature transactions. The goal is to encourage a standard that guarantees interoperability of all programs that implement it. - -==Motivation== - -The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection. - -==Specification== - -This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations. - -# One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP -# Transaction preparation -- the user creating the TxDP will create the transaction as they would like to see it spent (obviously without the signatures). Then they will go through each input and replace its script with the script of the txout that the input is spending. The reason for is so that ''receiving parties can sign with their private key without needing access to the blockchain.'' -# This TxDP will be serialized (see below), which will include a tag identifying the TxDP in the serialization, as well as in the filename, if it is saved to file. -# The TxDP will have an "DP ID" which is the hash of the TxDP in Base58 -- the reason for the specific naming convention is to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. -# The TxDP will have an unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. -# Identical TxDP objects with different signatures can be easily combined -# For cases where the TxDP might be put into a file to be sent via email, it should use .txdp or .btcdp suffix - - -Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation): - - '-----BEGIN-TRANSACTION-TXDPID-------' - ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize) - (preparedTxSerializedHexLine0) - (preparedTxSerializedHexLine1) - (preparedTxSerializedHexLine2) - ... - ("_TXINPUT_") (00) (InputValue) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_TXINPUT_") (01) (InputValue) - ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0) - (SigHexRemainingLines) - ("_TXINPUT_") (02) (InputValue) - '-------END-TRANSACTION-TXDPID-------' - -A multi-signature proposal that has 3 signatures on it could be stored in a file "Tx_QrtZ3K42n.txdp" and it would look something like: - - '''-----BEGIN-TXDP-----''' - '''_TXDIST_f9beb4d9_QrtZ3K42n_fda5''' - 204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e642062 - 61696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104 - 678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 - 49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f - ac00000000f9beb4d9d7000000010000006fe28c0ab6f1b372c1a6a246ae63f7 - 4f931e8365e15a089c68d6190000000000982051fd1e4ba744bbbe680e1fee14 - 677ba1a3c3540bf7b1cdb606e857233e0e61bc6649ffff001d01e36299010100 - fe328f9a3920119cbd3f1311f830039832abb3baf284625151f328f9a3920 - '''_TXINPUT_00_23.13000000''' - _SIG_1Gffm3Kj3_02_7e_fa8d9127149200f568383a089c68d61900000000009 - 8205bbbe680e1fee1467744bbbe680e1fee14677ba1a3c3540bf7b1cdb606e85 - 7233e0e61bc6649 - '''_TXINPUT_01_4.00000000''' - '''_TXINPUT_02_10.00000000''' - _SIG_1QRTt83p8_007f ffff00db606e857233e0e61bc6649ffff00db60831f9 - 6efa8d9127149200f568383a089c68d619000000000098205bbbe680e1fee1 - 46770e1fee14677ba1a3c35 - _SIG_1m3Rk38fd_007f - ffff00db606e857233e0e61bc6649ffff00db606efa8d9127149200f568383a0 - 89c68d619000000000098205bbbe680e1fee146770e1fee14677ba1a3c35 - '''------END-TXDP------''' - -In this transaction, there are 3 inputs, providing 23.13, 4.0 and 10.0 BTC, respectively. Input 0 has one signature, input 1 has zero signatures, and input 2 has two signatures. - -The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program/parser to simply determine the core elements of the TxDP. - -A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it should not be the recommended method for combining TxDPs. - -== Reference Implementation == - -This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Armory does not have Multi-signature transaction support yet, but all the code is implemented, just untested. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. The PyTxDistProposal class implements all features of BIP 0010: - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4616 Create TxDP from list of unspent TxOuts] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4840 Serialization of TxDP] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4879 Unserialize a TxDP] - -[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4795 Convert Completed TxDP to Broadcast-Tx] - -==Known Issues== - -One of the reasons TxDPs are versatile, is the ability for a device to "understand" and sign a transaction '''without''' access to the blockchain. However, this means that any information included in the TxDP that is not part of the final broadcast transaction (such as input values), cannot be verified by the device. i.e. Someone could create a TxDP and lie about the values of each input, knowing that the signing device will not be able to verify those values. Since the final, serialized transaction does not include input values, the subsequent signature will be valid no matter what inputs values were provided. - -This is only a minor issue, since developers who are concerned about such "attacks" can choose to ignore non-signed fields in the TxDP. Or, they can guarantee that all TxDPs will pass through a trusted system that ''does'' have access to the blockchain and can verify such information. diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki new file mode 100644 index 00000000..b3d750ba --- /dev/null +++ b/bip-0010.mediawiki @@ -0,0 +1,100 @@ +
+  BIP: 10
+  Title: Multi-Sig Transaction Distribution
+  Author: Alan Reiner
+  Status: Draft
+  Type: Informational
+  Created: 2011-10-28
+
+ +A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction. + +This BIP describes a way standardize the encoding of proposal transactions, to assist with signature collection and broadcast (which includes regular, 1-of-1 transactions requiring signatures from an offline computer). The goal is to encourage a standard that guarantees interoperability of all programs that implement it. + + +==Motivation== + +The enabling of multi-signature transactions in Bitcoin will introduce a great deal of extra functionality to the users of the network, but also a great deal of extra complexity. Executing a multi-signature tx will be a multi-step process, and will potentially get worse with multiple clients, each implementing this process differently. By providing an efficient, standardized technique, we can improve the chance that developers will adopt compatible protocols and not bifurcate the user-base based on client selection. + +In addition to providing a general encoding scheme for transaction signing/collection, it does not require the signing device to hold any blockchain information (all information needed for verification and signing is part of the encoding). This enables the existence of very lightweight devices that can be used for signing since they do not need the blockchain -- only a minimal set of Bitcoin tools and an ECDSA module. Therefore, BIP 0010 has benefit beyond just multi-signature transactions. + +==Specification== + +This BIP proposes the following process, with terms in quotes referring to recommended terminology that should be encouraged across all implementations. + +# One party will initiate this process by creating a "Distribution Proposal", which could be abbreviated DP, or TxDP +# The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go). +# The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain. +# The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. +# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. +# Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around". +# For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix + +Anyone adopting BIP 0010 for multi-sig transactions will use the following format (without indentation): + +
+ '-----BEGIN-TRANSACTION-TXDPID-------'
+ ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
+    (serializedTxListInHex_Line1)
+    (serializedTxListInHex_Line2)
+    (serializedTxListInHex_Line3)
+    ...
+ ("_TXINPUT_") (00) (InputValue)
+    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+    (SigHexRemainingLines)
+    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+    (SigHexRemainingLines)
+ ("_TXINPUT_") (01) (InputValue)
+    ("_SIG_") (AddrBase58) (SigBytes) (SigHexPart0)
+    (SigHexRemainingLines)
+ ("_TXINPUT_") (02) (InputValue)
+ '-------END-TRANSACTION-TXDPID-------'
+
+ +The following is an example TxDP from Armory, produced while running on the test network. Its DPID is 3fX59xPj: + + + -----BEGIN-TRANSACTION-3fX59xPj------------------------------------------------- + _TXDIST_fabfb5da_3fX59xPj_00a0 + 010000000292807c8e70a28c687daea2998d6273d074e56fa8a55a0b10556974cf2b526e61000000 + 0000ffffffffe3c1ee0711611b01af3dee55b1484f0d6b65d17dce4eff0e6e06242e6cf457e10000 + 000000ffffffff02b0feea0b000000001976a91457996661391fa4e95bed27d7e8fe47f47cb8e428 + 88ac00a0acb9030000001976a914dc504e07b1107110f601fb679dd3f56cee9ff71e88ac00000000 + 0100000001eb626e4f73d88f415a8e8cb32b8d73eed47aa1039d0ed2f013abdc741ce6828c010000 + 008c493046022100b0da540e4924518f8989a9da798ca2d9e761b69a173b8cc41a3e3e3c6d77cd50 + 022100ecfa61730e58005338420516744ef680428dcfc05022dec70a851365c8575b190141042dc5 + be3afa5887aee4a377032ed014361b0b9b61eb3ea6b8a8821bfe13ee4b65cd25d9630e4f227a53e8 + bf637f85452c9981bcbd64ef77e22ce97b0f547c783effffffff0200d6117e030000001976a914cf + f580fd243f64f0ad7bf69faf41c0bf42d86d8988ac00205fa0120000001976a9148d573ef6984fd9 + f8847d420001f7ac49b222a24988ac000000000100000001f2782db40ae147398a31cff9c7cc3423 + 014a073a92e463741244330cc304168f000000008c493046022100c9311b9eef0cc69219cb96838f + dd621530a80c46269a00dccc66498bc03ccf7a0221003742ee652a0a76fd28ad81aa73bb7f7a0a6a + 81850af58f62d9a184d10e5eec30014104f815e8ef4cad584e04974889d7636e8933803d2e72991d + b5288c9e953c2465533905f98b7b688898c7c1f0708f2e49f0dd0abc06859ffed5144e8a1018a4e8 + 63ffffffff02008c8647000000001976a914d4e211215967f8e3744693bf85f47eb4ee9567fc88ac + 603d4e95010000001976a914e9a6b50901c1969d2b0fd43a3ccfa3fef3291efe88ac00000000 + _TXINPUT_00_150.00000000 + _SIG_mzUYGfqGpyXmppYpmWJ31Y4zTxR4ZCod22_00_008c + 4930460221007699967c3ec09d072599558d2e7082fae0820206b63aa66afea124634ed11a080221 + 0003346f7e963e645ecae2855026dc7332eb7237012539b34cd441c3cef97fbd4d01410497d5e1a0 + 0e1db90e893d1f2e547e2ee83b5d6bf4ddaa3d514e6dc2d94b6bcb5a72be1fcec766b8c382502caa + 9ec09fe478bad07d3f38ff47b2eb42e681c384cc + _TXINPUT_01_12.00000000 + _SIG_mzvaN8JUhHLz3Gdec1zBRxs5rNaYLQnbD1_01_008c + 49304602210081554f8b08a1ad8caa69e34f4794d54952dac7c5efcf2afe080985d6bd5b00770221 + 00dea20ca3dbae1d15ec61bec57b4b8062e7d7c47614aba032c5a32f651f471cfd014104c30936d2 + 456298a566aa76fefeab8a7cb7a91e8a936a11757c911b4c669f0434d12ab0936fc13986b156156f + 9b389ed244bbb580112be07dbe23949a4764dffb + -------END-TRANSACTION-3fX59xPj------------------------------------------------- + + +In this transaction, there are two inputs, one of 150 BTC and the other of 12 BTC. This transaction combines 162 BTC to create two outputs, one of 160 BTC, one 1.9995 BTC, and a tx fee of 0.0005. In this TxDP, both inputs have been signed, and thus could broadcast immediately. + +The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures. This serialization is compact, and will be interpretted the same in all character encodings. It can be copied inline into an email, or saved in a text file. The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP. + +A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs. + +== Reference Implementation == + +This proposal has been implemented and tested in the ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction), and will eventually use it for multi-signature transcations. The source code for this implementation be found in the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py Armory Github project]. Specifically, the [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L4704 PyTxDistProposal class] implements all features of BIP 0010. It contains reference code for both +[https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5095 serializing a TxDP] and [https://github.com/etotheipi/BitcoinArmory/blob/qtdev/armoryengine.py#L5143 unserializing a TxDP]. diff --git a/bip-0011.md b/bip-0011.mediawiki similarity index 98% rename from bip-0011.md rename to bip-0011.mediawiki index 3eba9337..2499ac03 100644 --- a/bip-0011.md +++ b/bip-0011.mediawiki @@ -4,8 +4,8 @@ Author: Gavin Andresen Status: Accepted Type: Standards Track - Created: 18-10-2011 - Post-History: 02-10-2011 + Created: 2011-10-18 + Post-History: 2011-10-02 ==Abstract== @@ -56,4 +56,3 @@ https://github.com/gavinandresen/bitcoin-git/tree/op_eval == Post History == * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal] - diff --git a/bip-0012.md b/bip-0012.mediawiki similarity index 99% rename from bip-0012.md rename to bip-0012.mediawiki index 37542ebd..ee2fda6b 100644 --- a/bip-0012.md +++ b/bip-0012.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen Status: Withdrawn Type: Standards Track - Created: 18-10-2011 + Created: 2011-10-18 ==Abstract== @@ -81,5 +81,3 @@ https://bitcointalk.org/index.php?topic=46538 "Bitcoin Address 01" BIP M-of-N Multisignature Transactions BIP 11 - - diff --git a/bip-0013.md b/bip-0013.mediawiki similarity index 78% rename from bip-0013.md rename to bip-0013.mediawiki index 97b8b8b5..a537d16a 100644 --- a/bip-0013.md +++ b/bip-0013.mediawiki @@ -1,11 +1,12 @@ 
   BIP: 13
-  Title: Address Format for OP_EVAL
+  Title: Address Format for pay-to-script-hash
   Author: Gavin Andresen 
-  Status: Accepted
+  Status: Final
   Type: Standards Track
-  Created: 18-10-2011
+  Created: 2011-10-18
+ ==Abstract== This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. @@ -22,13 +23,13 @@ The new bitcoin address type is constructed in the same manner as existing bitco base58-encode: [one-byte version][20-byte hash][4-byte checksum] -Version byte is 2 for a main-network address, 109 for a testnet address. +Version byte is 5 for a main-network address, 196 for a testnet address. The 20-byte hash is the hash of the script that will be used to redeem the coins. -And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash. +And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. ==Rationale== -One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. +One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. Another criticism is that bitcoin addresses are inherently insecure because there is no identity information tied to them; if you only have a bitcoin address, how can you be certain that you're paying who or what you think you're paying? @@ -38,15 +39,18 @@ This is one piece of the simplest path to a more secure bitcoin infrastructure. Assuming that typing in bitcoin addresses manually will become increasingly rare in the future, and given that the existing checksum method for bitcoin addresses seems to work "well enough" in practice and has already been implemented multiple times, the Author believes no change to the checksum algorithm is necessary. +The leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'. + ==Backwards Compatibility== This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. ==Reference Implementation== -https://github.com/gavinandresen/bitcoin-git/tree/op_eval +See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src ==See Also== -The OP_EVAL BIP. - +* [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]] +* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] +* [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]] diff --git a/bip-0014.md b/bip-0014.mediawiki similarity index 97% rename from bip-0014.md rename to bip-0014.mediawiki index 12cbacbc..111eb78b 100644 --- a/bip-0014.md +++ b/bip-0014.mediawiki @@ -1,12 +1,12 @@ 
   BIP: 14
-  Title: Protocol Version and User Agent
+  Title: BIP Protocol Version and User Agent
   Author: Amir Taaki 
           Patrick Strateman 
   Status: Accepted
   Type: Standards Track
-  Created: 10-11-2011
-  Post-History: 02-11-2011
+  Created: 2011-11-10
+  Post-History: 2011-11-02
In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. @@ -66,7 +66,7 @@ Here bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal * Version numbers in the form of Major.Minor.Revision (2.6.41) * Repository builds using a date in the format of YYYYMMDD (20110128) -For git repository builds, implementations are free to use the git commitish. However the issue lies in that it is not immediately obvious without the repository which version proceeds another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement. +For git repository builds, implementations are free to use the git commitish. However the issue lies in that it is not immediately obvious without the repository which version precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement. Optional -r1, -r2, ... can be appended to user agent version numbers. This is another light recommendation, but not a requirement. Implementations are free to specify version numbers in whatever format needed insofar as it does not include (, ), : or / to interfere with the user agent syntax. @@ -80,11 +80,10 @@ Reserved symbols are therefore: / : ( ) They should not be misused beyond what is specified in this section. -* / seperates the code-stack +* / separates the code-stack * : specifies the implementation version of the particular stack * ( and ) delimits a comment which optionally separates data using ; == Timeline == When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other. - diff --git a/bip-0015.md b/bip-0015.mediawiki similarity index 73% rename from bip-0015.md rename to bip-0015.mediawiki index 8f86335d..c08498f1 100644 --- a/bip-0015.md +++ b/bip-0015.mediawiki @@ -1,12 +1,14 @@ 
   BIP: 15
-  Title: Aliases
+  Title: BIP Aliases
   Author: Amir Taaki 
-  Status: Withdrawn
+  Status: Deferred
   Type: Standards Track
-  Created: 10-12-2011
+  Created: 2011-12-10
+[[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases. + Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist. This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure. @@ -31,7 +33,7 @@ Their FirstBits alias becomes: It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments. -Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination. +Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination. However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing. @@ -49,6 +51,8 @@ Security wise, DNS is unsafe and insecure by design. It is possible to spoof rec As of Dec 2011, DNSSEC is still not yet a defacto standard on the internet. Should a participant in the bitcoin network wish to use DNS TXT records, they would in addition to having to configure DNS, be able to setup DNSSEC. This may not be feasible, especially where some registrars provide access to DNS through a web interface only. +The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues. + === Server Service === Aside from using DNS TXT records, another possibility is using the domain name system to lookup hosts and then contact a service running on a predefined port to get the bitcoin address. @@ -91,7 +95,7 @@ It also scales reasonably- anybody wishing to run a naming service can attach a A naive implementation is provided below as an example. - +
 // resolv.h
 #ifndef NOMRESOLV_H__
 #define NOMRESOLV_H__
@@ -145,7 +149,7 @@ private:
     bool Perform();
 
     // CURL error message
-    char pErrorBuffer[CURL_ERROR_SIZE];  
+    char pErrorBuffer[CURL_ERROR_SIZE];
     // CURL response
     string strBuffer;
     // CURL handle
@@ -153,9 +157,9 @@ private:
 };
 
 #endif
-
+
- +
 // resolv.cpp
 #include "resolv.h"
 
@@ -164,16 +168,16 @@ private:
 #include "access.h"
 
 // callback used to write response from the server
-static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)  
-{  
-  int nResult = 0;  
-  if (pBuffer != NULL)  
-  {  
-    pBuffer->append(pData, nSize * nNmemb);  
-    // How much did we write?  
-    nResult = nSize * nNmemb;  
-  }  
-  return nResult;  
+static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)
+{
+  int nResult = 0;
+  if (pBuffer != NULL)
+  {
+    pBuffer->append(pData, nSize * nNmemb);
+    // How much did we write?
+    nResult = nSize * nNmemb;
+  }
+  return nResult;
 }
 
 NameResolutionService::NameResolutionService()
@@ -181,17 +185,17 @@ NameResolutionService::NameResolutionService()
     // Initialise CURL with our various options.
     curl = curl_easy_init();
     // This goes first in case of any problems below. We get an error message.
-    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);  
+    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);
     // fail when server sends >= 404
-    curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);  
-    curl_easy_setopt(curl, CURLOPT_HEADER, 0);  
-    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);  
+    curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);
+    curl_easy_setopt(curl, CURLOPT_HEADER, 0);
+    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);
     curl_easy_setopt(curl, CURLOPT_POSTREDIR, CURL_REDIR_POST_302);
-    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);  
+    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);
     curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
     // server response goes in strBuffer
-    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);  
+    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);
     pErrorBuffer[0] = '\0';
 }
 NameResolutionService::~NameResolutionService()
@@ -209,7 +213,7 @@ void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNi
 bool NameResolutionService::Perform()
 {
     // Called after everything has been setup. This actually does the request.
-    CURLcode result = curl_easy_perform(curl);  
+    CURLcode result = curl_easy_perform(curl);
     return (result == CURLE_OK);
 }
 
@@ -229,7 +233,7 @@ string NameResolutionService::FetchAddress(const string& strHandle, string& strA
     // construct url for GET request
     string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;
     // Pass URL to CURL
-    curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());  
+    curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());
     if (!Perform())
         return pErrorBuffer;
     // Server should respond with a JSON that has the address in.
@@ -273,7 +277,7 @@ const Object CheckMaybeThrow(const string& strJsonIn)
     // Now check for a key called "error"
     const Value& error  = find_value(request, "error");
     // It's an error JSON! so propagate the error.
-    if (error.type() != null_type)   
+    if (error.type() != null_type)
         throw JSONRPCError(-4, error.get_str());
     // Return JSON object
     return request;
@@ -284,7 +288,7 @@ const string CollectAddress(const string& strIn)
     // If the handle does not have an @ in it, then it's a normal base58 bitcoin address
     if (strIn.find('@') == (size_t)-1)
         return strIn;
-    
+
     // Open the lookup service
     NameResolutionService ns;
     // We established that the input string is not a BTC address, so we use it as a handle now.
@@ -308,7 +312,7 @@ Value rpc_send(const Array& params, bool fHelp)
         throw runtime_error(
             "send  \n"
             " is a real and is rounded to the nearest 0.01");
-    
+
     // Intelligent function which looks up address given handle, or returns address
     string strAddy = CollectAddress(params[0].get_str());
     int64 nAmount = AmountFromValue(params[1]);
@@ -321,5 +325,77 @@ Value rpc_send(const Array& params, bool fHelp)
 }
 
 ...
-
+
+ +=== IP Transactions === + +An IP transaction is an old transaction format in bitcoin that is disabled and possibly could be deprecated. It involves being given an IP address to make payment to. Upon connecting to the node and requesting their public key using "checkorder", they will respond with a script in the form: + + OP_CHECKSIG + +Similar to coinbase output transactions. IP transactions have the advantage of being able to contain additional metadata which can be useful in many transactions. Currently no authentication is done making the scheme insecure against man in the middle (MITM) attacks. + +This proposal seeks to enable DNS lookups for IP transactions. + +The "checkorder" message would contain a destination account, which could map to different isolated sets of keypairs/wallets running under the same host. The exact mapping from the checkorder reference info to the local system is implementation defined. + +By using DNS lookups, the MITM problem with IP transactions could be mitigated by storing a public key in a DNS TXT record. This public key would be used for all future "reply" messages originating from that host. First time use would require a confirmation for acceptance of that public key; like with SSH. Should the "reply" message not match the accepted public key, then the host will be given an error. + +[[Category:BIP|E]] + +=== Namecoin ID === + +This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias. + +Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases). + +Two examples are presented below. The first shows a simpler format, while the second shows several Bitcoin addresses in a structured format. + + $ namecoind name_show id/khal + { + "bitcoin" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T" + } + + $ namecoind name_show id/khal + { + "bitcoin" : + { + "default" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", + "donation": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4" + } + } + +'''More possibilities :''' + +* Allow to securely use '''unsecured channels''' +You can put an url and a bitcoin address that will be used to sign the result. It means that a query to this url will return a bitcoin address and a signature. Bitcoin can then check (with the verify_message function) that the returned address has not been replaced by another one. + $ namecoind name_show id/khal + { + "bitcoin" : + { + "url" : "http://merchant.com/bitcoin/getnewaddres/", + "signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T" + } + } + +* Allow to get a different address each time, or per user, per order, etc + $ namecoind name_show id/khal + { + "bitcoin" : + { + "url" : "http://merchant.com/bitcoin/getaddres/{Your customer id}", + "signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T", + "useOnce": false + } + } +In the above example, bitcoin will ask the user for "Your customer id" and replace that value in the url before making the http request. The merchant will receive the request and give the user a payment address associated with that customer. + +Any text can be put into the brackets, allowing merchants to adapt it to all their needs. + + +* Specification is extensible + +New features can be added later to support uncovered cases. + +See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations. diff --git a/bip-0016.md b/bip-0016.mediawiki similarity index 78% rename from bip-0016.md rename to bip-0016.mediawiki index 68c03547..0a539fc2 100644 --- a/bip-0016.md +++ b/bip-0016.mediawiki @@ -2,9 +2,9 @@ BIP: 16 Title: Pay to Script Hash Author: Gavin Andresen - Status: Accepted + Status: Final Type: Standards Track - Created: 03-01-2012 + Created: 2012-01-03 ==Abstract== @@ -29,7 +29,7 @@ This new transaction type is redeemed by a standard scriptSig: ...signatures... {serialized script} -Transactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' is, itself, one of the other standard transaction types. +Transactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' - also referred to as the ''redeemScript'' - is, itself, one of the other standard transaction types. The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows: @@ -37,7 +37,7 @@ The rules for validating these outpoints when relaying transactions or consideri # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. -These same rules shall be applied when validating transactions in blocks with timestamps after February 15, 2012 (see the Backwards Compatibility section for details). +These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transaction earlier than 13333238400 in the block chain that fail these new validation rules. [http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: @@ -88,7 +88,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners. -To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. +To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create. @@ -96,13 +96,21 @@ On February 1, 2012, the block-chain will be examined to determine the number of If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved). +===520-byte limitation on serialized script size=== + +As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus is it not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. + + ==Reference Implementation== -Coming Soon +https://gist.github.com/gavinandresen/3966071 ==See Also== * https://bitcointalk.org/index.php?topic=46538 -* The [[BIP 0013|Address format for Pay to Script Hash BIP]] -* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]] +* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] +* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]] +* [[bip-0016/qa.mediawiki|Quality Assurance test checklist]] +== References == + diff --git a/bip-0016/qa.mediawiki b/bip-0016/qa.mediawiki new file mode 100644 index 00000000..6a8a08dc --- /dev/null +++ b/bip-0016/qa.mediawiki @@ -0,0 +1,190 @@ +This page is a Quality Assurance test plan for [[BIP 16]]. If you see a test missing, please add it. +If you can help test, please edit this page to sign-off on it. + +{| class="wikitable" +|- +! Done !! Test Procedure !! Tested by + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 0.6 on testnet and main net
+Send coins using GUI, RCP sendtoaddress, and RCP sendmany commands
+Result: coins sent in all cases +| Gavin Andresen + +|- style="color:green;" +| ✓ +| Test multisig 1-of-1
+Run 0.6 bitcoind, get a public key with: ./bitcoind -testnet validateaddress $(./bitcoind -testnet getnewaddress)
+Generate a multisig 1-of-1 address: ./bitcoind addmultisigaddress 1 {public key from above}
+Send-to-self some bitcoins using that address
+Result: transaction is confirmed by network, displays properly in listtransactions. +Result: balance is unaffected +| Gavin Andresen; see transactions in [http://blockexplorer.com/testnet/block/000000001bdceba3936f2ea6a55311ac7b6030e327f1960e892620fcde6abf5f testnet block 44989] + + +|- style="color:green;" +| ✓ +| Test multisig 1-of-2
+Run 0.6 bitcoind, get 2 new bitcoin addresses
+Generate a multisig 1-of-2 address: ./bitcoind addmultisigaddress 1 {address1} {address2}
+Send-to-self some bitcoins using that address
+Result: transaction is confirmed by network, displays properly in listtransactions. +Result: bitcoin balance is unaffected. +| Gavin Andresen; see transactions in [http://blockexplorer.com/testnet/block/000000001bdceba3936f2ea6a55311ac7b6030e327f1960e892620fcde6abf5f testnet block 44989] + + +|- style="color:green;" +| ✓ +| Test multisig 1-of-3, 2-of-3, 3-of-3
+Repeat test procedures above, with the other new multisignature transaction types +| Gavin Andresen; see transactions in [http://blockexplorer.com/testnet/block/000000001bdceba3936f2ea6a55311ac7b6030e327f1960e892620fcde6abf5f testnet block 44989] + +|- style="color:green;" +| ✓ +| Test multisig send-to-other
+Repeat test procedures above, but use two bitcoinds, prepared as follows:
+bitcoind 1 : Run getnewaddress and addmultisigaddress
+bitcoind 2 : Just addmultisigaddress
+Send coins from 2 to 1 using the address
+Result: transaction is accepted/confirmed by network
+Result: balance for 2 goes down, listtransactions for 2 displays correct result
+Result: balance for 1 goes up, listtransactions for 1 displays correct result
+| Gavin Andresen; see transactions in [http://blockexplorer.com/testnet/block/000000001bdceba3936f2ea6a55311ac7b6030e327f1960e892620fcde6abf5f testnet block 44989] + + +|- style="color:green;" +| ✓ +| Test redeeming multisignature transactions
+Fund a new, empty wallet entirely with multisig transactions
+Wait for transactions to confirm
+Use sendtoaddress and sendmany to generate spend-from-multisig transactions
+Spend to both single-address and multisig address, and test send-to-other and send-to-self
+Result: transactions are accepted/confirmed by network
+Result: balance decreases, listtransactions displays correct information
+| Gavin Andresen; see transactions in [http://blockexplorer.com/testnet/block/000000001bdceba3936f2ea6a55311ac7b6030e327f1960e892620fcde6abf5f testnet block 44989] + + +|- style="color:green;" +| ✓ +| Run 0.6 Bitcoin-Qt GUI on one of the test wallets from above
+Result: balance and transactions displayed correctly +| Gavin Andresen + +|- style="color:orange;" +| ✓ +| Run BIP-16-capable backport Bitcoin 0.3.19 through 0.5.1 on testnet and main net
+Send coins using GUI, RCP sendtoaddress, and RCP sendmany commands
+Result: coins sent in all cases +| Gavin Andresen (tested 0.3.19, 0.3.24 and 0.5.1) + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 0.6.0 on testnet
+Mine coins using built-in miner
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 0.6.0 on testnet
+Mine coins using getwork interface
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen + +|- style="color:green;" +| +| Run BIP-16-capable Bitcoin 0.6.0 on testnet
+Mine coins using getmemorypool interface
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gregory Maxwell; Using p2pool see [https://blockexplorer.com/testnet/rawblock/00000000040367fcb750b6f064db6955b6c7c6218fb625e3dfed6b5c19c97107 testnet block 45400] (and many others, also tested on mainnet) + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 0.3.19 through 0.5.1 backports on testnet
+Mine coins using built-in miner
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen (tested all on a testnet-in-a-box) + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 3.19 through 0.5.1 backports on testnet
+Mine coins using getwork interface
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen (tested all on a testnet-in-a-box) + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 0.3.19 through 0.5.1 backports on testnet
+Mine coins using built-in miner
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen (tested all on a testnet-in-a-box) + +|- style="color:green;" +| ✓ +| Run BIP-16-capable Bitcoin 3.19 through 0.5.1 backports on testnet
+Mine coins using getwork interface
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| Gavin Andresen (tested all on a testnet-in-a-box) +|- style="color:red;" + +|- style="color:red;" +| +| Run BIP-16-capable Bitcoin 3.19 through 0.5.1 backports on testnet
+Mine coins using getmemorypool interface
+Result: blocks accepted, show up on blockexplorer.com/testnet
+Result: mined blocks' coinbase contains /P2SH/ string +| + +|- style="color:green;" +| ✓ +| Create/run unit tests for:
+multisignature signing/verification
+multisignature invalid signature failure
+multisignature IsStandard() success/failure
+extraction of addresses from multisignature transactions
+BIP 16 IsStandard() success/failure (including failure with OP_PUSHDATA1/2/4)
+BIP 16 AreInputsStandard() success/failure
+BIP 16 compatibility with other 3 standard transaction types
+BIP 16 no-recursion test
+BIP 16 switchover date logic
+OP_CHECKMULTISIG counting of signature operations inside BIP 16 transactions
+| Gavin Andresen (see test/multisig_tests.cpp, test/script_tests.cpp, test/script_P2SH_tests.cpp, test/sigopcount_tests.cpp in the bitcoin source tree; 'make test_bitcoin' in src/ directory to compile) + +|- style="color:green;" +| ✓ +| Create/run 'transaction fuzzer' to stress-test BIP 16 transactions +| Gavin Andresen (https://github.com/gavinandresen/bitcoin-git/tree/fuzzer , run twice on both testnet-in-a-box and testnet with 100,000 'fuzzed' transactions each test run) Valid fuzzed transactions appeared in (for example) [http://blockexplorer.com/testnet/block/000000001587c859649cea954e921ba4efd77707fb327dd53e122fd7b89636c4 testnet block 44987] + +|- style="color:green;" +| ✓ +| Run Bitcoin 0.6 on main net
+Result: blocks created properly +Result: blocks include /P2SH/ string in their coinbase +| various mining pools + +|- style="color:green;" +| ✓ +| Run BIP 16 vinced_mergedmine backport on main net
+Result: blocks created properly +Result: blocks include /P2SH/ string in their coinbase +| (Gavin for slush: after bug fixes, running with no issues)
+ +|- style="color:green;" +| ✓ +| Test chain-split handling on testnet-in-a-box
+Create two valid hash, invalid signature transactions in two blocks separated in time on a testnet-in-a-box chain
+Run a bitcoind to synchronize with the chain, with -paytoscripthashtime set in between the two blocks
+Result: first transaction/block accepted, second causes a chain split
+Re-run bitcoind with -paytoscripthashtime in the future
+Result: entire chain accepted +| Gavin Andresen: testnet-in-a-box files at: http://www.skypaint.com/bitcoin/bip16chain.tar.gz first half-valid BIP16 transaction at block 2431 (time 1328202835) second at block 2436 (time 1328204241)
+ +|} diff --git a/bip-0017.md b/bip-0017.mediawiki similarity index 94% rename from bip-0017.md rename to bip-0017.mediawiki index 0cd5d708..07dca967 100644 --- a/bip-0017.md +++ b/bip-0017.mediawiki @@ -2,9 +2,9 @@ BIP: 17 Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr - Status: Withdrawn - Type: Standards Track - Created: 18-01-2012 + Status: Draft + Type: Withdrawn + Created: 2012-01-18 ==Abstract== @@ -26,7 +26,7 @@ OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function * If the hashes match, do nothing, proceed as if an OP_NOP; if they do not match, the script fails immediately. * Note that in the case of a matched hash, the top stack item (the hash being compared with) is not popped off the stack. This is for backward compatibility. -This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 20, 2012 (see the Backwards Compatibility section for details). +This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 23, 2012 (see the Backwards Compatibility section for details). A new standard transaction type that is relayed and included in mined blocks is defined: @@ -82,7 +82,7 @@ To gracefully upgrade and ensure no long-lasting block-chain split occurs, more To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create. -On February 3, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 18 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated. +On February 8, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 23 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated. If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved). @@ -96,7 +96,6 @@ OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain ca ==See Also== -* The [[BIP 0013|Address format for Pay to Script Hash BIP]] -* [[BIP 0011|M-of-N Multisignature Transactions (BIP 11)]] +* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] +* [[bip-0011.mediawiki|M-of-N Multisignature Transactions (BIP 11)]] * Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d] - diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki new file mode 100644 index 00000000..023b2bfb --- /dev/null +++ b/bip-0018.mediawiki @@ -0,0 +1,126 @@ +
+  BIP: 18
+  Title: hashScriptCheck
+  Author: Luke Dashjr 
+  Status: Draft
+  Type: Standards Track
+  Created: 2012-01-27
+
+ +==Abstract== + +This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck. + +==Motivation== + +The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. + +The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted. + +==Specification== + +scriptSig and scriptPubKey are hereby deemed to be deprecated. +Bitcoin-compatible clients MUST still continue to support them for compatibility, but it should not be used for any new transaction types. +Services and people which send Bitcoins SHOULD continue to support old pubkey-based addresses for the time being. +Services and people which receive Bitcoins MAY continue to generate and use old pubkey-based addresses. + +To replace these, there are 3 new elements: +* dataSig is included in place of scriptSig in transaction inputs, and contains multiple serialized data elements +* scriptCheck is the final element of dataSig, and is executed with the preceding dataSig elements preloaded onto the stack (the element immediately before scriptCheck is the top of the stack) +* hashScriptCheck is included in place of scriptPubKey in transaction outputs, to specify the hash of the scriptCheck allowed to redeem it + +dataSig is to be encoded the same as a push-only script. + +hashScriptCheck must be encoded exactly so: + + 0xa9 0x14 (20-byte-hash-value) 0x87 + +This can be interpreted by legacy (pre-BIP 18) clients as the following script: + + OP_HASH160 [20-byte-hash-value] OP_EQUAL + +If this template is not matched exactly OR the transaction is in a block with a timestamp before the hashScriptCheck activation date, validation MUST proceed in backward-compatibility mode, using scriptSig+scriptPubKey rather than dataSig+scriptCheck+hashScriptCheck. + +A hashScriptCheck-compliant input is valid only if: +* dataSig MUST NOT contain any operations other than "push data" (it is data, not a script; no mixing scriptSig with hashScriptCheck) +* scriptCheck MUST hash (using Bitcoin's Hash160 algorithm) to the output's hashScriptCheck. +* scriptCheck MUST be executed with the dataSig-based stack specified above (ie, not including scriptCheck itself) to perform validation (this does not imply clients are required to validate transactions). +* scriptCheck must not abort, and must leave a true value on the top of the stack. This is the current behaviour for scriptSig+scriptPubKey. + +The new scriptCheck SHOULD be checked against "standard transaction" templates by miners. + +For example, the hashScriptCheck and corresponding dataSig for a one-signature-required transaction is: + + scriptCheck: [pubkey] OP_CHECKSIG + dataSig: [signature] {[pubkey] OP_CHECKSIG} + hashScriptCheck: [20-byte-hash of {[pubkey] OP_CHECKSIG}] + +===Signature operation limits for scriptCheck=== + +Signature operations in scriptCheck do not follow the same rules previously applied to scriptSig and scriptPubKey. +Instead, they shall contribute to the maximum number allowed per block (20,000) as follows: + +# OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated. +# OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated. +# All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations. + +Examples: + ++3 signature operations: + 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG + ++22 signature operations + OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF + +==Rationale== + +This BIP replaces BIPs 12 and 17, which propose extensions to the Script system to allow scriptPubKey to outsource its verification. +It also replaces BIP 16, which is identical in terms of protocol, but suggests a specific implementation and does not deprecate scriptPubKey to maintain protocol consistency. + +The Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial; several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}. The author believes that this BIP will minimize the changes needed to all of the supporting infrastructure that has already been created to send funds to a base58-encoded-20-byte bitcoin addresses, allowing merchants and exchanges and other software to start supporting multisignature transactions sooner. + +The signature operation counting rules are intended to be easy and quick to implement by statically scanning scriptCheck. +Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners. +If there was no limit, a rogue miner might broadcast a block that required hundreds of thousands of ECDSA signature operations to validate, and it might be able to get a head start computing the next block while the rest of the network worked to validate the current one. + +There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is: + +# Attacker creates a pay-to-script-hash transaction that is valid when interpreted as scriptPubKey, but contains an invalid scriptCheck, and sends themselves some coins using it. +# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software. +# Attacker mines a block that contains both transactions. + +If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. + +The attack is expensive because it requires the attacker create a block that they know will be invalidated by the rest of the network. It is difficult because creating blocks is difficult and users should not accept 1-confirmation transactions for higher-value transactions. + +==Backwards Compatibility== + +hashScriptCheck transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks. + +Old implementations will validate that scriptCheck's hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation. + +Avoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case: + +* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners. + +To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. + +To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create. + +At 00:00:00 UTC on 15 Mar 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 00:00:00 UTC on 1 Apr 2012 shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature. + +If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved). + +==Forwards Compatibility == +The first two bytes of hashScriptCheck specify the hash algorithm and length used to verify scriptCheck. +This BIP only allows Bitcoin's Hash160 algorithm, but leaves open the possibility of a future BIP implementing others. + +==Reference Implementation== + +https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash + +==See Also== + +* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] +* [[bip-0016.mediawiki|BIP 16 - Pay to Script Hash (aka "/P2SH/")]] +* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]] diff --git a/bip-0019.md b/bip-0019.mediawiki similarity index 97% rename from bip-0019.md rename to bip-0019.mediawiki index b17175ec..7784e084 100644 --- a/bip-0019.md +++ b/bip-0019.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr Status: Draft Type: Standards Track - Created: 30-01-2012 + Created: 2012-01-30 ==Abstract== @@ -58,13 +58,10 @@ scriptSig: ==Rationale== OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. -This is already specified in [[BIP 0011]]. +This is already specified in [[bip-0011.mediawiki|BIP 0011]]. However, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block. Using OP_CHECKSIG only counts as 1 per signature, so can scale better. ==Implementation== All used operations are already supported by old clients and miners as a non-standard transaction type. - -[[Category:BIP|C]] - diff --git a/bip-0020.md b/bip-0020.mediawiki similarity index 93% rename from bip-0020.md rename to bip-0020.mediawiki index a96d8d03..fad634b7 100644 --- a/bip-0020.md +++ b/bip-0020.mediawiki @@ -2,12 +2,12 @@ BIP: 20 Title: URI Scheme Author: Luke Dashjr - Status: Rejected + Status: Replaced Type: Standards Track - Created: 10-01-2011 + Created: 2011-01-10 -BIP 0020 is based off an earlier document by Nils Schneider. +BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021''' ==Abstract== This BIP proposes a URI scheme for making Bitcoin payments. @@ -55,7 +55,7 @@ Graphical bitcoin clients SHOULD register themselves as the handler for the "bit ==== Transfer amount/size ==== If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal. -The number SHOULD be followed by "X" to signify an exponent to the base multiplier. +The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier. Thus, "X8" multiplies your number by 100,000,000. For decimal values, this means the standard BTC unit. For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC). @@ -92,9 +92,11 @@ Make it possible for later generations to improve our work, to mend our errors, This section is non-normative and does not cover all possible syntax. Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax. -[foo] means optional, are placeholders +[foo] means optional, <bar> are placeholders +
  bitcoin:
[;version=1.0][?amount=][?label=
=== Examples === @@ -127,15 +129,21 @@ Characters must be URI encoded properly. ===Sending money via private key=== To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output: +
   OP_CHECKSIG
+
Construct an address from the public key. Encode the URI as below: +
  bitcoin:
?send=
+
-You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where
matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form: +You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form: +
  
+
This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back. @@ -145,6 +153,7 @@ This claims the money you were sent. Until your claim transaction has confirmed === Parsing amount === ==== ECMAScript ==== +
  reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
  function parseAmount(txt) {
     var m = txt.match(reAmount);
@@ -161,8 +170,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
             (m[4] ? Math.pow(10, m[4]) : 1e8)
     );
  }
+
==== Python ==== +
  m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
  if m.group(5):
      amount = float(int(m.group(5), 16))
@@ -178,8 +189,10 @@ This claims the money you were sent. Until your claim transaction has confirmed
          amount *= 10 ** int(m.group(4))
      else:
          amount *= 100000000
+
==== C# ==== +
  Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
  Match match = amountExpression.Match(value);
  if (match.Success)
@@ -189,11 +202,11 @@ This claims the money you were sent. Until your claim transaction has confirmed
          long hexDecimal = 0;
          if (match.Groups[7].Success)
              hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);
- 
+
          long hexExponent = 0x10000;
          if (match.Groups[9].Success)
              hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));
- 
+
          Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
      }
      else
@@ -204,8 +217,4 @@ This claims the money you were sent. Until your claim transaction has confirmed
          Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
      }
  }
-
-[[Category:Developer]]
-[[Category:Technical]]
-[[Category:BIP|D]]
-
+
diff --git a/bip-0021.md b/bip-0021.mediawiki similarity index 72% rename from bip-0021.md rename to bip-0021.mediawiki index fa77e4b5..00d9a537 100644 --- a/bip-0021.md +++ b/bip-0021.mediawiki @@ -5,10 +5,10 @@ Matt Corallo Status: Accepted Type: Standards Track - Created: 29-01-2012 + Created: 2012-01-29 -This BIP is a modification of an earlier [[BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. +This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. ==Abstract== This BIP proposes a URI scheme for making Bitcoin payments. @@ -26,20 +26,29 @@ They SHOULD require the user to manually approve each payment individually, thou === Operating system integration === Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client. -=== BNF grammar === +=== General Format === + +Bitcoin URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a bitcoin address, and the query component provides additional payment options. + +Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. + +=== ABNF grammar === (See also [[#Simpler syntax|a simpler representation of syntax]]) bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] - bitcoinaddress = base58 *base58 - bitcoinparams = *bitcoinparam - standardparam = amountparam | labelparam | messageparam | otherparam - bitcoinparam = standardparam | reqparam + bitcoinaddress = *base58 + bitcoinparams = bitcoinparam [ "&" bitcoinparams ] + bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ] amountparam = "amount=" *digit [ "." *digit ] - labelparam = "label=" *pchar - messageparam = "message=" *pchar - otherparam = pchar *pchar "=" *pchar - reqparam = "req-" standardparam + labelparam = "label=" *qchar + messageparam = "message=" *qchar + otherparam = qchar *qchar [ "=" *qchar ] + reqparam = "req-" qchar *qchar [ "=" *qchar ] + +Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this BIP takes as separators. + +The scheme component ("bitcoin:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys. === Query Keys === @@ -71,7 +80,7 @@ Other proposed names sound much more cryptic; the chance that someone googles th Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin. ==Forward compatibility== -Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored. +Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored. ==Backward compatibility== As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "req-" prefix requirement. Thus, it is recommended that additional variables prefixed with req- not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade. @@ -81,11 +90,11 @@ As this BIP is written, several clients already implement a bitcoin: URI scheme === Simpler syntax === This section is non-normative and does not cover all possible syntax. -Please see the [[#BNF grammar|BNF grammar]] above for the normative syntax. +Please see the BNF grammar above for the normative syntax. -[foo] means optional, are placeholders +[foo] means optional, <bar> are placeholders - bitcoin:
[?amount=][?label=