From 1f64d2b06d628dffdc297be9a8afbb9da4e6b6ca Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 21 Oct 2013 00:32:10 -0400 Subject: Rename to mediawiki extension --- bip-0001.md | 172 ---------------------------- bip-0001.mediawiki | 172 ++++++++++++++++++++++++++++ bip-0010.md | 98 ---------------- bip-0010.mediawiki | 98 ++++++++++++++++ bip-0011.md | 59 ---------- bip-0011.mediawiki | 59 ++++++++++ bip-0012.md | 85 -------------- bip-0012.mediawiki | 85 ++++++++++++++ bip-0013.md | 52 --------- bip-0013.mediawiki | 52 +++++++++ bip-0014.md | 90 --------------- bip-0014.mediawiki | 90 +++++++++++++++ bip-0015.md | 325 ----------------------------------------------------- bip-0015.mediawiki | 325 +++++++++++++++++++++++++++++++++++++++++++++++++++++ bip-0016.md | 108 ------------------ bip-0016.mediawiki | 108 ++++++++++++++++++ bip-0017.md | 102 ----------------- bip-0017.mediawiki | 102 +++++++++++++++++ bip-0019.md | 70 ------------ bip-0019.mediawiki | 70 ++++++++++++ bip-0020.md | 211 ---------------------------------- bip-0020.mediawiki | 211 ++++++++++++++++++++++++++++++++++ bip-0021.md | 119 -------------------- bip-0021.mediawiki | 119 ++++++++++++++++++++ bip-0022.md | 206 --------------------------------- bip-0022.mediawiki | 206 +++++++++++++++++++++++++++++++++ bip-0030.md | 48 -------- bip-0030.mediawiki | 48 ++++++++ bip-0031.md | 39 ------- bip-0031.mediawiki | 39 +++++++ bip-0032.md | 132 ---------------------- bip-0032.mediawiki | 132 ++++++++++++++++++++++ bip-0033.md | 136 ---------------------- bip-0033.mediawiki | 136 ++++++++++++++++++++++ bip-0034.md | 39 ------- bip-0034.mediawiki | 39 +++++++ bip-0035.md | 45 -------- bip-0035.mediawiki | 45 ++++++++ 38 files changed, 2136 insertions(+), 2136 deletions(-) delete mode 100644 bip-0001.md create mode 100644 bip-0001.mediawiki delete mode 100644 bip-0010.md create mode 100644 bip-0010.mediawiki delete mode 100644 bip-0011.md create mode 100644 bip-0011.mediawiki delete mode 100644 bip-0012.md create mode 100644 bip-0012.mediawiki delete mode 100644 bip-0013.md create mode 100644 bip-0013.mediawiki delete mode 100644 bip-0014.md create mode 100644 bip-0014.mediawiki delete mode 100644 bip-0015.md create mode 100644 bip-0015.mediawiki delete mode 100644 bip-0016.md create mode 100644 bip-0016.mediawiki delete mode 100644 bip-0017.md create mode 100644 bip-0017.mediawiki delete mode 100644 bip-0019.md create mode 100644 bip-0019.mediawiki delete mode 100644 bip-0020.md create mode 100644 bip-0020.mediawiki delete mode 100644 bip-0021.md create mode 100644 bip-0021.mediawiki delete mode 100644 bip-0022.md create mode 100644 bip-0022.mediawiki delete mode 100644 bip-0030.md create mode 100644 bip-0030.mediawiki delete mode 100644 bip-0031.md create mode 100644 bip-0031.mediawiki delete mode 100644 bip-0032.md create mode 100644 bip-0032.mediawiki delete mode 100644 bip-0033.md create mode 100644 bip-0033.mediawiki delete mode 100644 bip-0034.md create mode 100644 bip-0034.mediawiki delete mode 100644 bip-0035.md create mode 100644 bip-0035.mediawiki diff --git a/bip-0001.md b/bip-0001.md deleted file mode 100644 index 433126b..0000000 --- a/bip-0001.md +++ /dev/null @@ -1,172 +0,0 @@ -
-  BIP: 1
-  Title: BIP Purpose and Guidelines
-  Author: Amir Taaki 
-  Status: Active
-  Type: Standards Track
-  Created: 19-08-2011
-
- -==What is a BIP?== - -BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. - -We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. - -Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal -. -==BIP Types== - -There are three kinds of BIP: - -* 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. -* 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 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. - -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. - -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. - -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. - -The BIP author may update the Draft as necessary on the wiki. - -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. - -For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. - -Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". - -A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. - -A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. - -BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1. - -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). - -==What belongs in a successful BIP?== - -Each BIP should have the following parts: - -* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. - -* 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]. - -* 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). - -* 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. - -* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. - -* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. - -* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright. - -* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. - -* The final implementation must include test code and documentation appropriate for the Bitcoin protocol. - -==BIP Formats and Templates== - -BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP. - -==BIP Header Preamble== - -Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. - -
-  BIP: 
-  Title: 
-  Author: 
-* Discussions-To: 
-  Status: 
-  Type: 
-  Created: 
-* Post-History: 
-* Replaces: 
-* Superseded-By: 
-* Resolution: 
-
- -The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be - - Random J. User - -if the email address is included, and just - - Random J. User - -if the address is not given. - -If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. - -Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made. - -While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists. - -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. - -BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. - -BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete. -Auxiliary Files - -BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). - -==Transferring BIP Ownership== - -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 - -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!). - -For each new BIP that comes in an editor does the following: - -* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. -* The title should accurately describe the content. -* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7). - -If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. - -Once the BIP is ready for the repository, the BIP editor will: - -* 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 wiki. - -* Send email back to the BIP author with next steps (post to bitcoin mailing list). - -Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. - -The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. - -==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. - diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki new file mode 100644 index 0000000..433126b --- /dev/null +++ b/bip-0001.mediawiki @@ -0,0 +1,172 @@ +
+  BIP: 1
+  Title: BIP Purpose and Guidelines
+  Author: Amir Taaki 
+  Status: Active
+  Type: Standards Track
+  Created: 19-08-2011
+
+ +==What is a BIP?== + +BIP stands for Bitcoin Improvement Proposal. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. + +We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. + +Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal +. +==BIP Types== + +There are three kinds of BIP: + +* 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. +* 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 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. + +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. + +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. + +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. + +The BIP author may update the Draft as necessary on the wiki. + +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. + +For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. + +Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". + +A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. + +A BIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. + +BIPs can also be superseded by a different BIP, rendering the original obsolete. This is intended for Informational BIPs, where version 2 of an API can replace version 1. + +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). + +==What belongs in a successful BIP?== + +Each BIP should have the following parts: + +* Preamble -- RFC 822 style headers containing meta-data about the BIP, including the BIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. + +* 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]. + +* 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). + +* 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. + +* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + +* The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. + +* Backwards Compatibility -- All BIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BIP must explain how the author proposes to deal with these incompatibilities. BIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +* Reference Implementation -- The reference implementation must be completed before any BIP is given status "Final", but it need not be completed before the BIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. + +* The final implementation must include test code and documentation appropriate for the Bitcoin protocol. + +==BIP Formats and Templates== + +BIPs should be written in mediawiki wiki syntax. Image files should be included in the current subdirectory for that BIP. + +==BIP Header Preamble== + +Each BIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. + +
+  BIP: 
+  Title: 
+  Author: 
+* Discussions-To: 
+  Status: 
+  Type: 
+  Created: 
+* Post-History: 
+* Replaces: 
+* Superseded-By: 
+* Resolution: 
+
+ +The Author header lists the names, and optionally the email addresses of all the authors/owners of the BIP. The format of the Author header value must be + + Random J. User + +if the email address is included, and just + + Random J. User + +if the address is not given. + +If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. + +Note: The Resolution header is required for Standards Track BIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the BIP is made. + +While a BIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the BIP is being discussed. No Discussions-To header is necessary if the BIP is being discussed privately with the author, or on the bitcoin email mailing lists. + +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. + +BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. + +BIPs may also have a Superseded-By header indicating that a BIP has been rendered obsolete by a later document; the value is the number of the BIP that replaces the current document. The newer BIP must have a Replaces header containing the number of the BIP that it rendered obsolete. +Auxiliary Files + +BIPs may include auxiliary files such as diagrams. Such files must be named BIP-XXXX-Y.ext, where "XXXX" is the BIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). + +==Transferring BIP Ownership== + +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 + +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!). + +For each new BIP that comes in an editor does the following: + +* Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted. +* The title should accurately describe the content. +* Edit the BIP for language (spelling, grammar, sentence structure, etc.), markup (for reST BIPs), code style (examples should match BIP 8 & 7). + +If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the BIP is ready for the repository, the BIP editor will: + +* 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 wiki. + +* Send email back to the BIP author with next steps (post to bitcoin mailing list). + +Many BIPs are written and maintained by developers with write access to the Bitcoin codebase. The BIP editors monitor BIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. + +The editors don't pass judgement on BIPs. We merely do the administrative & editorial part. Except for times like this, there's relatively low volume. + +==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. + diff --git a/bip-0010.md b/bip-0010.md deleted file mode 100644 index bd96ed6..0000000 --- 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 0000000..bd96ed6 --- /dev/null +++ b/bip-0010.mediawiki @@ -0,0 +1,98 @@ +
+  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-0011.md b/bip-0011.md deleted file mode 100644 index 3eba933..0000000 --- a/bip-0011.md +++ /dev/null @@ -1,59 +0,0 @@ -
-  BIP: 11
-  Title: M-of-N Standard Transactions
-  Author: Gavin Andresen 
-  Status: Accepted
-  Type: Standards Track
-  Created: 18-10-2011
-  Post-History: 02-10-2011
-
- -==Abstract== - -This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. - -==Motivation== - -Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. - -A couple of motivating use cases: - -* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. - -* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP. - -==Specification== - -A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks: - - m {pubkey}...{pubkey} n OP_CHECKMULTISIG - -But only for n less than or equal to 3. - -OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: - OP_0 ...signatures... - -(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack). - -The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes. - -==Rationale== - -OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. - -One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block. - -The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and '''will''' be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time. - -A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes. - -==Implementation== - -OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. - -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-0011.mediawiki b/bip-0011.mediawiki new file mode 100644 index 0000000..3eba933 --- /dev/null +++ b/bip-0011.mediawiki @@ -0,0 +1,59 @@ +
+  BIP: 11
+  Title: M-of-N Standard Transactions
+  Author: Gavin Andresen 
+  Status: Accepted
+  Type: Standards Track
+  Created: 18-10-2011
+  Post-History: 02-10-2011
+
+ +==Abstract== + +This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. + +==Motivation== + +Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. + +A couple of motivating use cases: + +* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. + +* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP. + +==Specification== + +A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks: + + m {pubkey}...{pubkey} n OP_CHECKMULTISIG + +But only for n less than or equal to 3. + +OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: + OP_0 ...signatures... + +(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack). + +The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes. + +==Rationale== + +OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. + +One argument against using OP_CHECKMULTISIG is that old clients and miners count it as "20 sigops" for purposes of computing how many signature operations are in a block, and there is a hard limit of 20,000 sigops per block-- meaning a maximum of 1,000 multisig transactions per block. Creating multisig transactions using multiple OP_CHECKSIG operations allows more of them per block. + +The counter-argument is that these new multi-signature transactions will be used in combination with OP_EVAL (see the OP_EVAL BIP), and '''will''' be counted accurately. And in any case, as transaction volume rises the hard-coded maximum block size will have to be addressed, and the rules for counting number-of-signature-operations-in-a-block can be addressed at that time. + +A weaker argument is OP_CHECKMULTISIG should not be used because it pops one too many items off the stack during validation. Adding an extra OP_0 placeholder to the scriptSig adds only 1 byte to the transaction, and any alternative that avoids OP_CHECKMULTISIG adds at least several bytes of opcodes. + +==Implementation== + +OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. + +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.md deleted file mode 100644 index 37542eb..0000000 --- a/bip-0012.md +++ /dev/null @@ -1,85 +0,0 @@ -
-  BIP: 12
-  Title: OP_EVAL
-  Author: Gavin Andresen 
-  Status: Withdrawn
-  Type: Standards Track
-  Created: 18-10-2011
-
- -==Abstract== - -This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. - -==Motivation== - -Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. - -==Specification== - -OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: - -* When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. -* If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. -* If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. -* If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. -* Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. - -A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined: - - DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL - -Which is redeemed by a standard scriptSig: - ...signatures... {serialized script} - -Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types. - -==Rationale== - -OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions. - -If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. - -The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. - -That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. - -There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: - -# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. -# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. -# Attacker manages to mine 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. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions. - -==Backwards Compatibility== - -Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners). - -Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner. - -Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases: - -# An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. -# An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. - -For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved). - -For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. -Example of a transaction that must fail for both old and new miners/clients: - scriptSig: {serialized OP_11} - scriptPubKey: OP_EVAL OP_11 OP_EQUAL - -==Reference Implementation== - -https://github.com/gavinandresen/bitcoin-git/tree/op_eval - -==See Also== - -https://bitcointalk.org/index.php?topic=46538 - -"Bitcoin Address 01" BIP - -M-of-N Multisignature Transactions BIP 11 - - diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki new file mode 100644 index 0000000..37542eb --- /dev/null +++ b/bip-0012.mediawiki @@ -0,0 +1,85 @@ +
+  BIP: 12
+  Title: OP_EVAL
+  Author: Gavin Andresen 
+  Status: Withdrawn
+  Type: Standards Track
+  Created: 18-10-2011
+
+ +==Abstract== + +This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. + +==Motivation== + +Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. + +==Specification== + +OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: + +* When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. +* If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. +* If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. +* If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. +* Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. + +A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined: + + DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL + +Which is redeemed by a standard scriptSig: + ...signatures... {serialized script} + +Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types. + +==Rationale== + +OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions. + +If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. + +The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. + +That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. + +There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: + +# Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. +# Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. +# Attacker manages to mine 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. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions. + +==Backwards Compatibility== + +Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners). + +Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner. + +Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases: + +# An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. +# An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. + +For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved). + +For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. +Example of a transaction that must fail for both old and new miners/clients: + scriptSig: {serialized OP_11} + scriptPubKey: OP_EVAL OP_11 OP_EQUAL + +==Reference Implementation== + +https://github.com/gavinandresen/bitcoin-git/tree/op_eval + +==See Also== + +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.md deleted file mode 100644 index 97b8b8b..0000000 --- a/bip-0013.md +++ /dev/null @@ -1,52 +0,0 @@ -
-  BIP: 13
-  Title: Address Format for OP_EVAL
-  Author: Gavin Andresen 
-  Status: Accepted
-  Type: Standards Track
-  Created: 18-10-2011
-
-==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. - -In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key. - -==Motivation== - -Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. - -==Specification== - -The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]): - - 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. -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. - -==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. - -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? - -Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used. - -This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker. - -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. - -==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 Also== - -The OP_EVAL BIP. - diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki new file mode 100644 index 0000000..97b8b8b --- /dev/null +++ b/bip-0013.mediawiki @@ -0,0 +1,52 @@ +
+  BIP: 13
+  Title: Address Format for OP_EVAL
+  Author: Gavin Andresen 
+  Status: Accepted
+  Type: Standards Track
+  Created: 18-10-2011
+
+==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. + +In essence, an address encoded under this proposal represents the encoded hash of a [[script]], rather than the encoded hash of an ECDSA public key. + +==Motivation== + +Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. + +==Specification== + +The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]): + + 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. +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. + +==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. + +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? + +Furthermore, truncating SHA256 is not an optimal checksum; there are much better error-detecting algorithms. If we are introducing a new form of Bitcoin address, then perhaps a better algorithm should be used. + +This is one piece of the simplest path to a more secure bitcoin infrastructure. It is not intended to solve all of bitcoin's usability or security issues, but to be an incremental improvement over what exists today. A future BIP or BIPs should propose more user-friendly mechanisms for making payments, or for verifying that you're sending a payment to the Free Software Foundation and not Joe Random Hacker. + +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. + +==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 Also== + +The OP_EVAL BIP. + diff --git a/bip-0014.md b/bip-0014.md deleted file mode 100644 index 12cbacb..0000000 --- a/bip-0014.md +++ /dev/null @@ -1,90 +0,0 @@ -
-  BIP: 14
-  Title: Protocol Version and User Agent
-  Author: Amir Taaki 
-          Patrick Strateman 
-  Status: Accepted
-  Type: Standards Track
-  Created: 10-11-2011
-  Post-History: 02-11-2011
-
- -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. - -== Past Situation == - -Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets. - -Embedded in the protocol is a version number. Primarily this version number is in the "version" and "getblocks" messages, but is also in the "block" message to indicate the software version that created that block. Currently this version number is the same version number as that of the client. This document is a proposal to separate the protocol version from the client version, together with a proposed method to do so. - -== Rationale == - -With non-separated version numbers, every release of the Satoshi client will increase its internal version number. Primarily this holds every other client hostage to a game of catch-up with Satoshi version number schemes. This plays against the decentralised nature of bitcoin, by forcing every software release to remain in step with the release schedule of one group of bitcoin developers. - -Version bumping can also introduce incompatibilities and fracture the network. In order that the health of the network is maintained, the development of the protocol as a shared common collaborative process requires being split off from the implementation of that protocol. Neutral third entities to guide the protocol with representatives from all groups, present the chance for bitcoin to grow in a positive manner with minimal risks. - -By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network. - -Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). - -User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing. - -In short: - -* Protocol version: way to distinguish between nodes and behave different accordingly. -* User agent: simple informational tool. Protocol should not be modified depending on user agent. - -== Browser User-Agents == - -[http://tools.ietf.org/html/rfc1945 RFC 1945] vaguely specifies a user agent to be a string of the product with optional comments. - - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20100127 Gentoo Shiretoko/3.5.6 - -User agents are most often parsed by computers more than humans. The space delimited format, does not provide an easy, fast or efficient way for parsing. The data contains no structure indicating hierarchy in this placement. - -The most immediate pieces of information there are the browser product, rendering engine and the build (Gentoo Shiretoko) together with version number. Various other pieces of information as included as comments such as desktop environment, platform, language and revision number of the build. - -== Proposal == - -The version field in "version" and "getblocks" packets will become the protocol version number. The version number in the "blocks" reflects the protocol version from when that block was created. - -The currently unused sub_version_num field in "version" packets will become the new user-agent string. - -Bitcoin user agents are a modified browser user agent with more structure to aid parsers and provide some coherence. In bitcoin, the software usually works like a stack starting from the core code-base up to the end graphical interface. Therefore the user agent strings codify this relationship. - -Basic format: - - /Name:Version/Name:Version/.../ - -Example: - - /Satoshi:5.64/bitcoin-qt:0.4/ - /Satoshi:5.12/Spesmilo:0.8/ - -Here bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal codebase they use are different versions of the same software. The version numbers are not defined to any strict format, although this guide recommends: - -* 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. - -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. - -An optional comments field after the version number is also allowed. Comments should be delimited by brackets (...). The contents of comments is entirely implementation defined although this BIP recommends the use of semi-colons ; as a delimiter between pieces of information. - -Example: - - /BitcoinJ:0.2(iPad; U; CPU OS 3_2_1)/AndroidBuild:0.8/ - -Reserved symbols are therefore: / : ( ) - -They should not be misused beyond what is specified in this section. - -* / seperates 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-0014.mediawiki b/bip-0014.mediawiki new file mode 100644 index 0000000..12cbacb --- /dev/null +++ b/bip-0014.mediawiki @@ -0,0 +1,90 @@ +
+  BIP: 14
+  Title: Protocol Version and User Agent
+  Author: Amir Taaki 
+          Patrick Strateman 
+  Status: Accepted
+  Type: Standards Track
+  Created: 10-11-2011
+  Post-History: 02-11-2011
+
+ +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. + +== Past Situation == + +Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets. + +Embedded in the protocol is a version number. Primarily this version number is in the "version" and "getblocks" messages, but is also in the "block" message to indicate the software version that created that block. Currently this version number is the same version number as that of the client. This document is a proposal to separate the protocol version from the client version, together with a proposed method to do so. + +== Rationale == + +With non-separated version numbers, every release of the Satoshi client will increase its internal version number. Primarily this holds every other client hostage to a game of catch-up with Satoshi version number schemes. This plays against the decentralised nature of bitcoin, by forcing every software release to remain in step with the release schedule of one group of bitcoin developers. + +Version bumping can also introduce incompatibilities and fracture the network. In order that the health of the network is maintained, the development of the protocol as a shared common collaborative process requires being split off from the implementation of that protocol. Neutral third entities to guide the protocol with representatives from all groups, present the chance for bitcoin to grow in a positive manner with minimal risks. + +By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network. + +Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type). + +User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing. + +In short: + +* Protocol version: way to distinguish between nodes and behave different accordingly. +* User agent: simple informational tool. Protocol should not be modified depending on user agent. + +== Browser User-Agents == + +[http://tools.ietf.org/html/rfc1945 RFC 1945] vaguely specifies a user agent to be a string of the product with optional comments. + + Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20100127 Gentoo Shiretoko/3.5.6 + +User agents are most often parsed by computers more than humans. The space delimited format, does not provide an easy, fast or efficient way for parsing. The data contains no structure indicating hierarchy in this placement. + +The most immediate pieces of information there are the browser product, rendering engine and the build (Gentoo Shiretoko) together with version number. Various other pieces of information as included as comments such as desktop environment, platform, language and revision number of the build. + +== Proposal == + +The version field in "version" and "getblocks" packets will become the protocol version number. The version number in the "blocks" reflects the protocol version from when that block was created. + +The currently unused sub_version_num field in "version" packets will become the new user-agent string. + +Bitcoin user agents are a modified browser user agent with more structure to aid parsers and provide some coherence. In bitcoin, the software usually works like a stack starting from the core code-base up to the end graphical interface. Therefore the user agent strings codify this relationship. + +Basic format: + + /Name:Version/Name:Version/.../ + +Example: + + /Satoshi:5.64/bitcoin-qt:0.4/ + /Satoshi:5.12/Spesmilo:0.8/ + +Here bitcoin-qt and Spesmilo may use protocol version 5.0, however the internal codebase they use are different versions of the same software. The version numbers are not defined to any strict format, although this guide recommends: + +* 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. + +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. + +An optional comments field after the version number is also allowed. Comments should be delimited by brackets (...). The contents of comments is entirely implementation defined although this BIP recommends the use of semi-colons ; as a delimiter between pieces of information. + +Example: + + /BitcoinJ:0.2(iPad; U; CPU OS 3_2_1)/AndroidBuild:0.8/ + +Reserved symbols are therefore: / : ( ) + +They should not be misused beyond what is specified in this section. + +* / seperates 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.md deleted file mode 100644 index 8f86335..0000000 --- a/bip-0015.md +++ /dev/null @@ -1,325 +0,0 @@ -
-  BIP: 15
-  Title: Aliases
-  Author: Amir Taaki 
-  Status: Withdrawn
-  Type: Standards Track
-  Created: 10-12-2011
-
- -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. - -== Schemes == - -Here are a few different proposals and the properties of each system. - -=== FirstBits === - -FirstBits is a proposal for using the blockchain as an address book. - -When bitcoins are sent to an address, that address becomes recorded in the blockchain. It is therefore known that this address exists or did exist by simply seeing that there was a payment to that address. FirstBits is a method to have a memorable alias. One first converts the address to lower-case, then takes the first few unique characters. This is your FirstBits alias. - -As an example, brmlab hackerspace in Prague has an address for purchasing food or drink, or making donations: - - 1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX - -Their FirstBits alias becomes: - - 1brmlab - -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. - -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. - -FirstBits scales extremely poorly as the network grows. Each indexer or lookup node needs to keep track of every bitcoin address ever in existence and provide a fast lookup from the aliases to those addresses. As the network grows linearly, the number of addresses should grow exponentially (assuming a networked effect of (n-1)*(n-2)/2) rapidly making this scheme unfeasible. - -Light clients of the partial merkle root types become dependent on a trusted third party for their alias lookups. The cost of storing every bitcoin address is too high considering their typical use-case on low-resource devices. This factor more than the others, means this scheme is sub-optimal and must be rejected. - -=== DNS TXT Records === - -DNS allows TXT records to be created containing arbitrary data. In a bitcoin alias system, a custom format mutually agreed upon by a BIP standard would be used to store mappings to bitcoin addresses from domain names. How such a format would look is out of the scope of this document. - -An issue is that it requires people who wish to create such mappings to be familiar with configuring DNS records, and be able to run the necessary toolsets to insert the correct data. Although not a huge concern, it is a usability issue. - -Security wise, DNS is unsafe and insecure by design. It is possible to spoof records by being on the same network as another host. A number of revisions to mitigate the issue under the guise of DNSSEC have been in the works since the 1990s and are still being rolled out. - -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. - -=== 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. - -# User wishes to send to foo@bar.net -# Client uses DNS to find the IP address of bar.net: 123.123.123.123 -# Client connects to port 123.123.123.123:4567 and requests the bitcoin address for the user ''foo'' -# Server responds with the address or error code and terminates the connection. -# Client sends the funds to the address - -The service would be responsible for providing the mechanisms for changing and storing the mappings on their service. A front-end web interface could be provided to users wishing to use the service and customise their accounts on the server. - -This approach has the positive aspect of providing the best flexibility for the implementer to store the records however they wish in a database or plaintext file, and then serve them up quickly using a small server side daemon typically written in C. This approach is highly scalable. - -However this approach also suffers the problem of being reliant on DNS and hence also being vulnerable to spoofing. Hence DNSSEC is also required. This approach is slightly better than the DNS TXT records though since it makes inserting new users and modifying aliases very easy which allows people to run these server services more cheaply. - -=== HTTPS Web Service === - -HTTPS provides an additional layer of security by encrypting the connection, providing much needed privacy for users. Together with using Certificate Authorities, it fixes the issue with using DNSSEC since an error would be thrown up were someone to try to spoof a domain name on the local network. - -When trying to send to: - - genjix@foo.org - -The request is broken into the handle (genjix) and domain (foo.org) at the last occurrence of the @. The client then constructs a request that will query for the address. - - https://foo.org/bitcoin-alias/?handle=genjix - -bitcoin-alias has been chosen as the query suffix because it allows this system to co-exist easily within another web root without the fear of name clashes. - -The query will then return an address which is used to make the payment. - - 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ - -The details of whether a unique address is returned per query, whether an address is fetched from a pre-existing pool of addresses, and so on is an implementation detail unique to every server. How alias to address mappings are setup is dependent on the site which could have a web-interface and be providing a free service to users or be a private customised service serving pre-existing addresses. This is left up to sysop policy, and deliberately not defined here. - -A web service is trivial to setup and the cost is low. There are many free out of the box providers on the net that allows anyone with the most basic knowledge of web technologies to create their own website. By providing users with a package, anybody can quickly set themselves up with a bitcoin alias. It could be something as simple as a PHP script that the user edits with their custom settings and uploads themselves to their website. - -It also scales reasonably- anybody wishing to run a naming service can attach a backend with a variety of database technologies then provide a web frontend for users to customise and create their own aliases. - -A naive implementation is provided below as an example. - - -// resolv.h -#ifndef NOMRESOLV_H__ -#define NOMRESOLV_H__ - -#include -#include "curl/curl.h" - -using std::string; - -/* - -This class resolves against a server to lookup addresses. -To not conflict with the bitcoin addresses, we refer here to people's handles. -A handle is of the form: - - genjix@foo.org - -Most characters are valid for the username + password (and handled accordingly), but the domain follows usual web standards. It is possible to affix a path if needed, - - genjix@bar.com/path/to/ - -*/ - -class NameResolutionService -{ -public: - NameResolutionService(); - ~NameResolutionService(); - - // Three main methods map to RPC actions. - string FetchAddress(const string& strHandle, string& strAddy); - -private: - // A POST block - class PostVariables - { - public: - PostVariables(); - ~PostVariables(); - // Add a new key, value pair - bool Add(const string& strKey, const string& strVal); - curl_httppost* operator()() const; - private: - // CURL stores POST blocks as linked lists. - curl_httppost *pBegin, *pEnd; - }; - - // Explodes user@domain => user, domain - static void ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain); - // Perform the HTTP request. Returns true on success. - bool Perform(); - - // CURL error message - char pErrorBuffer[CURL_ERROR_SIZE]; - // CURL response - string strBuffer; - // CURL handle - CURL *curl; -}; - -#endif - - - -// resolv.cpp -#include "resolv.h" - -#include - -#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; -} - -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); - // 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_POSTREDIR, CURL_REDIR_POST_302); - 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); - pErrorBuffer[0] = '\0'; -} -NameResolutionService::~NameResolutionService() -{ - curl_easy_cleanup(curl); -} - -void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain) -{ - // split address at @ furthrest to the right - size_t nPosAtsym = strHandle.rfind('@'); - strNickname = strHandle.substr(0, nPosAtsym); - strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size()); -} -bool NameResolutionService::Perform() -{ - // Called after everything has been setup. This actually does the request. - CURLcode result = curl_easy_perform(curl); - return (result == CURLE_OK); -} - -string NameResolutionService::FetchAddress(const string& strHandle, string& strAddy) -{ - // GET is defined for 'getting' data, so we use GET for the low risk fetching of people's addresses - if (!curl) - // For some reason CURL didn't start... - return pErrorBuffer; - // Expand the handle - string strNickname, strDomain; - ExplodeHandle(strHandle, strNickname, strDomain); - // url encode the nickname for get request - const char* pszEncodedNick = curl_easy_escape(curl, strNickname.c_str(), strNickname.size()); - if (!pszEncodedNick) - return "Unable to encode nickname."; - // 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()); - if (!Perform()) - return pErrorBuffer; - // Server should respond with a JSON that has the address in. - strAddy = strBuffer; - return ""; // no error -} - -NameResolutionService::PostVariables::PostVariables() -{ - // pBegin/pEnd *must* be null before calling curl_formadd - pBegin = NULL; - pEnd = NULL; -} -NameResolutionService::PostVariables::~PostVariables() -{ - curl_formfree(pBegin); -} -bool NameResolutionService::PostVariables::Add(const string& strKey, const string& strVal) -{ - // Copy strings to this block. Return true on success. - return curl_formadd(&pBegin, &pEnd, CURLFORM_COPYNAME, strKey.c_str(), CURLFORM_COPYCONTENTS, strVal.c_str(), CURLFORM_END) == CURL_FORMADD_OK; -} - -curl_httppost* NameResolutionService::PostVariables::operator()() const -{ - return pBegin; -} - - - -// rpc.cpp -... - -const Object CheckMaybeThrow(const string& strJsonIn) -{ - // Parse input JSON - Value valRequest; - if (!read_string(strJsonIn, valRequest) || valRequest.type() != obj_type) - throw JSONRPCError(-32700, "Parse error"); - const Object& request = valRequest.get_obj(); - // 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) - throw JSONRPCError(-4, error.get_str()); - // Return JSON object - return request; -} - -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. - string strHandle = strIn, strAddy; - string strError = ns.FetchAddress(strHandle, strAddy); - if (!strError.empty()) - throw JSONRPCError(-4, strError); - - const Object& request(CheckMaybeThrow(strAddy)); - // Get the BTC address from the JSON - const Value& address = find_value(request, "address"); - if (address.type() != str_type) - throw JSONRPCError(-32600, "Server responded with malformed reply."); - return address.get_str(); -} - -// Named this way to prevent possible conflicts. -Value rpc_send(const Array& params, bool fHelp) -{ - if (fHelp || params.size() != 2) - 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]); - // Do the send - CWalletTx wtx; - string strError = SendMoneyToBitcoinAddress(strAddy, nAmount, wtx); - if (!strError.empty()) - throw JSONRPCError(-4, strError); - return wtx.GetHash().GetHex(); -} - -... - - diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki new file mode 100644 index 0000000..8f86335 --- /dev/null +++ b/bip-0015.mediawiki @@ -0,0 +1,325 @@ +
+  BIP: 15
+  Title: Aliases
+  Author: Amir Taaki 
+  Status: Withdrawn
+  Type: Standards Track
+  Created: 10-12-2011
+
+ +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. + +== Schemes == + +Here are a few different proposals and the properties of each system. + +=== FirstBits === + +FirstBits is a proposal for using the blockchain as an address book. + +When bitcoins are sent to an address, that address becomes recorded in the blockchain. It is therefore known that this address exists or did exist by simply seeing that there was a payment to that address. FirstBits is a method to have a memorable alias. One first converts the address to lower-case, then takes the first few unique characters. This is your FirstBits alias. + +As an example, brmlab hackerspace in Prague has an address for purchasing food or drink, or making donations: + + 1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX + +Their FirstBits alias becomes: + + 1brmlab + +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. + +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. + +FirstBits scales extremely poorly as the network grows. Each indexer or lookup node needs to keep track of every bitcoin address ever in existence and provide a fast lookup from the aliases to those addresses. As the network grows linearly, the number of addresses should grow exponentially (assuming a networked effect of (n-1)*(n-2)/2) rapidly making this scheme unfeasible. + +Light clients of the partial merkle root types become dependent on a trusted third party for their alias lookups. The cost of storing every bitcoin address is too high considering their typical use-case on low-resource devices. This factor more than the others, means this scheme is sub-optimal and must be rejected. + +=== DNS TXT Records === + +DNS allows TXT records to be created containing arbitrary data. In a bitcoin alias system, a custom format mutually agreed upon by a BIP standard would be used to store mappings to bitcoin addresses from domain names. How such a format would look is out of the scope of this document. + +An issue is that it requires people who wish to create such mappings to be familiar with configuring DNS records, and be able to run the necessary toolsets to insert the correct data. Although not a huge concern, it is a usability issue. + +Security wise, DNS is unsafe and insecure by design. It is possible to spoof records by being on the same network as another host. A number of revisions to mitigate the issue under the guise of DNSSEC have been in the works since the 1990s and are still being rolled out. + +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. + +=== 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. + +# User wishes to send to foo@bar.net +# Client uses DNS to find the IP address of bar.net: 123.123.123.123 +# Client connects to port 123.123.123.123:4567 and requests the bitcoin address for the user ''foo'' +# Server responds with the address or error code and terminates the connection. +# Client sends the funds to the address + +The service would be responsible for providing the mechanisms for changing and storing the mappings on their service. A front-end web interface could be provided to users wishing to use the service and customise their accounts on the server. + +This approach has the positive aspect of providing the best flexibility for the implementer to store the records however they wish in a database or plaintext file, and then serve them up quickly using a small server side daemon typically written in C. This approach is highly scalable. + +However this approach also suffers the problem of being reliant on DNS and hence also being vulnerable to spoofing. Hence DNSSEC is also required. This approach is slightly better than the DNS TXT records though since it makes inserting new users and modifying aliases very easy which allows people to run these server services more cheaply. + +=== HTTPS Web Service === + +HTTPS provides an additional layer of security by encrypting the connection, providing much needed privacy for users. Together with using Certificate Authorities, it fixes the issue with using DNSSEC since an error would be thrown up were someone to try to spoof a domain name on the local network. + +When trying to send to: + + genjix@foo.org + +The request is broken into the handle (genjix) and domain (foo.org) at the last occurrence of the @. The client then constructs a request that will query for the address. + + https://foo.org/bitcoin-alias/?handle=genjix + +bitcoin-alias has been chosen as the query suffix because it allows this system to co-exist easily within another web root without the fear of name clashes. + +The query will then return an address which is used to make the payment. + + 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ + +The details of whether a unique address is returned per query, whether an address is fetched from a pre-existing pool of addresses, and so on is an implementation detail unique to every server. How alias to address mappings are setup is dependent on the site which could have a web-interface and be providing a free service to users or be a private customised service serving pre-existing addresses. This is left up to sysop policy, and deliberately not defined here. + +A web service is trivial to setup and the cost is low. There are many free out of the box providers on the net that allows anyone with the most basic knowledge of web technologies to create their own website. By providing users with a package, anybody can quickly set themselves up with a bitcoin alias. It could be something as simple as a PHP script that the user edits with their custom settings and uploads themselves to their website. + +It also scales reasonably- anybody wishing to run a naming service can attach a backend with a variety of database technologies then provide a web frontend for users to customise and create their own aliases. + +A naive implementation is provided below as an example. + + +// resolv.h +#ifndef NOMRESOLV_H__ +#define NOMRESOLV_H__ + +#include +#include "curl/curl.h" + +using std::string; + +/* + +This class resolves against a server to lookup addresses. +To not conflict with the bitcoin addresses, we refer here to people's handles. +A handle is of the form: + + genjix@foo.org + +Most characters are valid for the username + password (and handled accordingly), but the domain follows usual web standards. It is possible to affix a path if needed, + + genjix@bar.com/path/to/ + +*/ + +class NameResolutionService +{ +public: + NameResolutionService(); + ~NameResolutionService(); + + // Three main methods map to RPC actions. + string FetchAddress(const string& strHandle, string& strAddy); + +private: + // A POST block + class PostVariables + { + public: + PostVariables(); + ~PostVariables(); + // Add a new key, value pair + bool Add(const string& strKey, const string& strVal); + curl_httppost* operator()() const; + private: + // CURL stores POST blocks as linked lists. + curl_httppost *pBegin, *pEnd; + }; + + // Explodes user@domain => user, domain + static void ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain); + // Perform the HTTP request. Returns true on success. + bool Perform(); + + // CURL error message + char pErrorBuffer[CURL_ERROR_SIZE]; + // CURL response + string strBuffer; + // CURL handle + CURL *curl; +}; + +#endif + + + +// resolv.cpp +#include "resolv.h" + +#include + +#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; +} + +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); + // 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_POSTREDIR, CURL_REDIR_POST_302); + 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); + pErrorBuffer[0] = '\0'; +} +NameResolutionService::~NameResolutionService() +{ + curl_easy_cleanup(curl); +} + +void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain) +{ + // split address at @ furthrest to the right + size_t nPosAtsym = strHandle.rfind('@'); + strNickname = strHandle.substr(0, nPosAtsym); + strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size()); +} +bool NameResolutionService::Perform() +{ + // Called after everything has been setup. This actually does the request. + CURLcode result = curl_easy_perform(curl); + return (result == CURLE_OK); +} + +string NameResolutionService::FetchAddress(const string& strHandle, string& strAddy) +{ + // GET is defined for 'getting' data, so we use GET for the low risk fetching of people's addresses + if (!curl) + // For some reason CURL didn't start... + return pErrorBuffer; + // Expand the handle + string strNickname, strDomain; + ExplodeHandle(strHandle, strNickname, strDomain); + // url encode the nickname for get request + const char* pszEncodedNick = curl_easy_escape(curl, strNickname.c_str(), strNickname.size()); + if (!pszEncodedNick) + return "Unable to encode nickname."; + // 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()); + if (!Perform()) + return pErrorBuffer; + // Server should respond with a JSON that has the address in. + strAddy = strBuffer; + return ""; // no error +} + +NameResolutionService::PostVariables::PostVariables() +{ + // pBegin/pEnd *must* be null before calling curl_formadd + pBegin = NULL; + pEnd = NULL; +} +NameResolutionService::PostVariables::~PostVariables() +{ + curl_formfree(pBegin); +} +bool NameResolutionService::PostVariables::Add(const string& strKey, const string& strVal) +{ + // Copy strings to this block. Return true on success. + return curl_formadd(&pBegin, &pEnd, CURLFORM_COPYNAME, strKey.c_str(), CURLFORM_COPYCONTENTS, strVal.c_str(), CURLFORM_END) == CURL_FORMADD_OK; +} + +curl_httppost* NameResolutionService::PostVariables::operator()() const +{ + return pBegin; +} + + + +// rpc.cpp +... + +const Object CheckMaybeThrow(const string& strJsonIn) +{ + // Parse input JSON + Value valRequest; + if (!read_string(strJsonIn, valRequest) || valRequest.type() != obj_type) + throw JSONRPCError(-32700, "Parse error"); + const Object& request = valRequest.get_obj(); + // 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) + throw JSONRPCError(-4, error.get_str()); + // Return JSON object + return request; +} + +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. + string strHandle = strIn, strAddy; + string strError = ns.FetchAddress(strHandle, strAddy); + if (!strError.empty()) + throw JSONRPCError(-4, strError); + + const Object& request(CheckMaybeThrow(strAddy)); + // Get the BTC address from the JSON + const Value& address = find_value(request, "address"); + if (address.type() != str_type) + throw JSONRPCError(-32600, "Server responded with malformed reply."); + return address.get_str(); +} + +// Named this way to prevent possible conflicts. +Value rpc_send(const Array& params, bool fHelp) +{ + if (fHelp || params.size() != 2) + 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]); + // Do the send + CWalletTx wtx; + string strError = SendMoneyToBitcoinAddress(strAddy, nAmount, wtx); + if (!strError.empty()) + throw JSONRPCError(-4, strError); + return wtx.GetHash().GetHex(); +} + +... + + diff --git a/bip-0016.md b/bip-0016.md deleted file mode 100644 index 68c0354..0000000 --- a/bip-0016.md +++ /dev/null @@ -1,108 +0,0 @@ -
-  BIP: 16
-  Title: Pay to Script Hash
-  Author: Gavin Andresen 
-  Status: Accepted
-  Type: Standards Track
-  Created: 03-01-2012
-
- -==Abstract== - -This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions. - -==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== - -A new standard transaction type that is relayed and included in mined blocks is defined: - - OP_HASH160 [20-byte-hash-value] OP_EQUAL - -[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes. - -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. - -The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows: - -# Validation fails if there are any operations other than "push data" operations in the scriptSig. -# 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). - -For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: - - scriptSig: [signature] {[pubkey] OP_CHECKSIG} - scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL - -Signature operations in the {serialized script} 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 BIP 12, which proposed a new Script opcode ("OP_EVAL") to accomplish everything in this BIP and more. - -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. - -Recognizing one 'special' form of scriptPubKey and performing extra validation when it is detected is ugly. However, the consensus is that the alternatives are either uglier, are more complex to implement, and/or expand the power of the expression language in dangerous ways. - -The signature operation counting rules are intended to be easy and quick to implement by statically scanning the {serialized script}. 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 as seen by old software, but invalid for new implementation, 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== - -These transactions are non-standard to old implementations, which will (typically) not relay them or include them in blocks. - -Old implementations will validate that the {serialize script}'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. - -On February 1, 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 15 Feb 2012, 00:00:00 GMT 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). - -==Reference Implementation== - -Coming Soon - -==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]] - diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki new file mode 100644 index 0000000..68c0354 --- /dev/null +++ b/bip-0016.mediawiki @@ -0,0 +1,108 @@ +
+  BIP: 16
+  Title: Pay to Script Hash
+  Author: Gavin Andresen 
+  Status: Accepted
+  Type: Standards Track
+  Created: 03-01-2012
+
+ +==Abstract== + +This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions. + +==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== + +A new standard transaction type that is relayed and included in mined blocks is defined: + + OP_HASH160 [20-byte-hash-value] OP_EQUAL + +[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes. + +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. + +The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows: + +# Validation fails if there are any operations other than "push data" operations in the scriptSig. +# 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). + +For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: + + scriptSig: [signature] {[pubkey] OP_CHECKSIG} + scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL + +Signature operations in the {serialized script} 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 BIP 12, which proposed a new Script opcode ("OP_EVAL") to accomplish everything in this BIP and more. + +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. + +Recognizing one 'special' form of scriptPubKey and performing extra validation when it is detected is ugly. However, the consensus is that the alternatives are either uglier, are more complex to implement, and/or expand the power of the expression language in dangerous ways. + +The signature operation counting rules are intended to be easy and quick to implement by statically scanning the {serialized script}. 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 as seen by old software, but invalid for new implementation, 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== + +These transactions are non-standard to old implementations, which will (typically) not relay them or include them in blocks. + +Old implementations will validate that the {serialize script}'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. + +On February 1, 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 15 Feb 2012, 00:00:00 GMT 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). + +==Reference Implementation== + +Coming Soon + +==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]] + diff --git a/bip-0017.md b/bip-0017.md deleted file mode 100644 index 0cd5d70..0000000 --- a/bip-0017.md +++ /dev/null @@ -1,102 +0,0 @@ -
-  BIP: 17
-  Title: OP_CHECKHASHVERIFY (CHV)
-  Author: Luke Dashjr 
-  Status: Withdrawn
-  Type: Standards Track
-  Created: 18-01-2012
-
- -==Abstract== - -This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. - -==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== - -OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function as follows when executed: - -* First, hash the end of the prior script (in the general case, scriptSig; if no prior script, a null string is hashed) beginning from the last evaluated OP_CODESEPARATOR onward (or from the beginning of the script, if no OP_CODESEPARATOR was present) -* Then, compare this with the item on the top of the stack (if there is none, the script fails immediately) -* 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). - -A new standard transaction type that is relayed and included in mined blocks is defined: - - [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP - -[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes. - -This new transaction type is redeemed by a standard scriptSig: - - ...signatures... OP_CODESEPARATOR {script} - -Transactions that redeem these pay-to-script outpoints are only considered standard if they contain exactly one OP_CODESEPARATOR and the appended ''script'' is, itself, one of the other standard transaction types. - -==Example== - -For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: - - scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG - scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP - -2-of-3: - - scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG - scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP - -==Rationale== - -This BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash. - -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. - -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 as seen by old software, but invalid for new implementation, 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== - -These transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks. - -Old implementations will not validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP. - -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/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. - -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). - -OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain can still be redeemed. - -==Reference Implementation== - -[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify Validation, sending, and receiving for bitcoind git master] - -[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify_backport Validation only for 0.3.19+] - -==See Also== - -* The [[BIP 0013|Address format for Pay to Script Hash BIP]] -* [[BIP 0011|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-0017.mediawiki b/bip-0017.mediawiki new file mode 100644 index 0000000..0cd5d70 --- /dev/null +++ b/bip-0017.mediawiki @@ -0,0 +1,102 @@ +
+  BIP: 17
+  Title: OP_CHECKHASHVERIFY (CHV)
+  Author: Luke Dashjr 
+  Status: Withdrawn
+  Type: Standards Track
+  Created: 18-01-2012
+
+ +==Abstract== + +This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. + +==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== + +OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function as follows when executed: + +* First, hash the end of the prior script (in the general case, scriptSig; if no prior script, a null string is hashed) beginning from the last evaluated OP_CODESEPARATOR onward (or from the beginning of the script, if no OP_CODESEPARATOR was present) +* Then, compare this with the item on the top of the stack (if there is none, the script fails immediately) +* 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). + +A new standard transaction type that is relayed and included in mined blocks is defined: + + [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP + +[20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes. + +This new transaction type is redeemed by a standard scriptSig: + + ...signatures... OP_CODESEPARATOR {script} + +Transactions that redeem these pay-to-script outpoints are only considered standard if they contain exactly one OP_CODESEPARATOR and the appended ''script'' is, itself, one of the other standard transaction types. + +==Example== + +For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: + + scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG + scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP + +2-of-3: + + scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG + scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP + +==Rationale== + +This BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash. + +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. + +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 as seen by old software, but invalid for new implementation, 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== + +These transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks. + +Old implementations will not validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP. + +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/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. + +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). + +OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain can still be redeemed. + +==Reference Implementation== + +[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify Validation, sending, and receiving for bitcoind git master] + +[https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify_backport Validation only for 0.3.19+] + +==See Also== + +* The [[BIP 0013|Address format for Pay to Script Hash BIP]] +* [[BIP 0011|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-0019.md b/bip-0019.md deleted file mode 100644 index b17175e..0000000 --- a/bip-0019.md +++ /dev/null @@ -1,70 +0,0 @@ -
-  BIP: 19
-  Title: M-of-N Standard Transactions (Low SigOp)
-  Author: Luke Dashjr 
-  Status: Draft
-  Type: Standards Track
-  Created: 30-01-2012
-
- -==Abstract== - -This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. - -==Motivation== - -Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. - -A couple of motivating use cases: - -* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. - -* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP. - -==Specification== - -Two new standard transaction types (scriptPubKey) that are relayed by clients and included in mined blocks. - -N-of-N (all signatures required): - - ( {pubkey} OP_CHECKSIGVERIFY )*n - -N-of-M (some signatures required): - - {pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL - -But only for n less than or equal to 3. - -These transactions are redeemed using a standard scriptSig: - ...signatures... - -The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes. - -===Templates=== -scriptPubKey: - - {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY - - {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY - - {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL - - {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL - -scriptSig: - - ...signatures... up to 500 bytes - -==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]]. -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-0019.mediawiki b/bip-0019.mediawiki new file mode 100644 index 0000000..b17175e --- /dev/null +++ b/bip-0019.mediawiki @@ -0,0 +1,70 @@ +
+  BIP: 19
+  Title: M-of-N Standard Transactions (Low SigOp)
+  Author: Luke Dashjr 
+  Status: Draft
+  Type: Standards Track
+  Created: 30-01-2012
+
+ +==Abstract== + +This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. + +==Motivation== + +Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. + +A couple of motivating use cases: + +* A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the transaction and that the transaction details are correct. Details for how clients and WPS's communicate are outside the scope of this BIP. Side note: customers should insist that their wallet protection service provide them with copies of the private key(s) used to secure their wallets that they can safely store off-line, so that their coins can be spent even if the WPS goes out of business. + +* Three-party escrow (buyer, seller and trusted dispute agent). 2-of-3 signatures required transactions will be used. The buyer and seller and agent will each provide a public key, and the buyer will then send coins into a 2-of-3 CHECKMULTISIG transaction and send the seller and the agent the transaction id. The seller will fulfill their obligation and then ask the buyer to co-sign a transaction ( already signed by seller ) that sends the tied-up coins to him (seller).
If the buyer and seller cannot agree, then the agent can, with the cooperation of either buyer or seller, decide what happens to the tied-up coins. Details of how buyer, seller, and agent communicate to gather signatures or public keys are outside the scope of this BIP. + +==Specification== + +Two new standard transaction types (scriptPubKey) that are relayed by clients and included in mined blocks. + +N-of-N (all signatures required): + + ( {pubkey} OP_CHECKSIGVERIFY )*n + +N-of-M (some signatures required): + + {pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL + +But only for n less than or equal to 3. + +These transactions are redeemed using a standard scriptSig: + ...signatures... + +The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes. + +===Templates=== +scriptPubKey: + + {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY + + {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY + + {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL + + {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL + +scriptSig: + + ...signatures... up to 500 bytes + +==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]]. +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.md deleted file mode 100644 index a96d8d0..0000000 --- a/bip-0020.md +++ /dev/null @@ -1,211 +0,0 @@ -
-  BIP: 20
-  Title: URI Scheme
-  Author: Luke Dashjr 
-  Status: Rejected
-  Type: Standards Track
-  Created: 10-01-2011
-
- -BIP 0020 is based off an earlier document by Nils Schneider. - -==Abstract== -This BIP proposes a URI scheme for making Bitcoin payments. - -==Motivation== -The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. - -==Specification== - -=== General rules for handling (important!) === - -Bitcoin clients MUST NOT act on URIs without getting the user's authorization. -They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision. - -=== 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 === - -(See also [[#Simpler syntax|a simpler representation of syntax]]) - - bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ] - bitcoinaddress = base58 *base58 - bitcoinversion = "1.0" - bitcoinparams = *bitcoinparam - bitcoinparam = amountparam | labelparam | messageparam | sendparam | otherparam - amountparam = "amount=" amount - amount = amountdecimal | amounthex - amountdecimal = *digit [ "." *digit ] [ "X" *digit ] - amounthex = "x" *hexdigit [ "." *hexdigit ] [ "X" *hexdigit ] - labelparam = "label=" *pchar - messageparam = "message=" *pchar - sendparam = "send=" *pchar - otherparam = pchar *pchar "=" *pchar - -=== Query Keys === - -*label: Label for that address (e.g. name of receiver) -*address: bitcoin address -*message: message that shown to the user after scanning the QR code -*size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) -*send: used to send bitcoin, rather than to request them -*(others): optional, for future extensions - -==== 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. -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). -If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers. -I.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC. -When specifying bitcoin base units, "X0" SHOULD be used. - -Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. -They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. -For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount. - -== Rationale == - -===Payment identifiers, not person identifiers=== -Current best practices are that a unique address should be used for every transaction. -Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment. - -===Accessibility (URI scheme name)=== -Should someone from the outside happen to see such a URI, the URI scheme name already gives a description. -A quick search should then do the rest to help them find the resources needed to make their payment. -Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer. -Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin. - -==Forward compatibility== -We want URIs generated in 2011 to still work in 2036: think about extensibility. -Of course we can make only educated guesses about the future, but don't act as if there is none. -This should be the best we can do, but it should not be seen as set in stone. -Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. - -== Appendix == - -=== 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. - -[foo] means optional, are placeholders - - bitcoin:
[;version=1.0][?amount=][?label=