diff --git a/appdx-bips.asciidoc b/appdx-bips.asciidoc index 33d85495..41eee8ce 100644 --- a/appdx-bips.asciidoc +++ b/appdx-bips.asciidoc @@ -4,7 +4,7 @@ ((("Bitcoin improvement proposals", id="ix_appdx-bips-asciidoc0", range="startofrange")))Bitcoin improvement proposals are design documents providing information to the bitcoin community, or describing a new feature for bitcoin or its processes or environment. -As per BIP0001 _BIP Purpose and Guidelines_, there are three kinds of BIP: +As per BIP-01 _BIP Purpose and Guidelines_, there are three kinds of BIP: _Standard_ BIP:: Describes any change that affects most or all bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using bitcoin. _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 may ignore informational BIPs or follow their advice. @@ -17,120 +17,120 @@ Bitcoin improvement proposals are recorded in a versioned repository on https:// [options="header"] |======================================================================= |BIP# | Link | Title |Owner |Type |Status -|[[bip0001]]1|https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki|BIP Purpose and Guidelines |Amir Taaki +|[[bip-01]]1|https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki|BIP Purpose and Guidelines |Amir Taaki |Standard |Active -|[[bip0010]]10|https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki|Multi-Sig Transaction Distribution |Alan +|[[bip-10]]10|https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki|Multi-Sig Transaction Distribution |Alan Reiner |Informational |Draft -|[[bip0011]]11|https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki|M-of-N Standard Transactions |Gavin +|[[bip-11]]11|https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki|M-of-N Standard Transactions |Gavin Andresen |Standard |Accepted -|[[bip0012]]12|https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki|OP_EVAL |Gavin Andresen |Standard +|[[bip-12]]12|https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki|OP_EVAL |Gavin Andresen |Standard |Withdrawn -|[[bip0013]]13|https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki|Address Format for pay-to-script-hash +|[[bip-13]]13|https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki|Address Format for pay-to-script-hash |Gavin Andresen |Standard |Final -|[[bip0014]]14|https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki|Protocol Version and User Agent |Amir +|[[bip-14]]14|https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki|Protocol Version and User Agent |Amir Taaki, Patrick Strateman |Standard |Accepted -|[[bip0015]]15|https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki|Aliases |Amir Taaki |Standard |Withdrawn +|[[bip-15]]15|https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki|Aliases |Amir Taaki |Standard |Withdrawn -|[[bip0016]]16|https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki|Pay To Script Hash |Gavin Andresen +|[[bip-16]]16|https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki|Pay To Script Hash |Gavin Andresen |Standard |Accepted -|[[bip0017]]17|https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki|OP_CHECKHASHVERIFY (CHV) |Luke Dashjr +|[[bip-17]]17|https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki|OP_CHECKHASHVERIFY (CHV) |Luke Dashjr |Withdrawn |Draft -|[[bip0018]]18|https://github.com/bitcoin/bips/blob/master/bip-0018.mediawikilink:|hashScriptCheck |Luke Dashjr |Standard +|[[bip-18]]18|https://github.com/bitcoin/bips/blob/master/bip-0018.mediawikilink:|hashScriptCheck |Luke Dashjr |Standard |Draft -|[[bip0019]]19|https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki|M-of-N Standard Transactions (Low SigOp) +|[[bip-19]]19|https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki|M-of-N Standard Transactions (Low SigOp) |Luke Dashjr |Standard |Draft -|[[bip0020]]20|https://github.com/bitcoin/bips/blob/master/bip-0020.mediawiki|URI Scheme |Luke Dashjr |Standard +|[[bip-20]]20|https://github.com/bitcoin/bips/blob/master/bip-0020.mediawiki|URI Scheme |Luke Dashjr |Standard |Replaced -|[[bip0021]]21|https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|URI Scheme |Nils Schneider, Matt Corallo +|[[bip-21]]21|https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|URI Scheme |Nils Schneider, Matt Corallo |Standard |Accepted -|[[bip0022]]22|https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki|getblocktemplate - Fundamentals |Luke +|[[bip-22]]22|https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki|getblocktemplate - Fundamentals |Luke Dashjr |Standard |Accepted -|[[bip0023]]23|https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki|getblocktemplate - Pooled Mining |Luke +|[[bip-23]]23|https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki|getblocktemplate - Pooled Mining |Luke Dashjr |Standard |Accepted -|[[bip0030]]30|https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|Duplicate transactions |Pieter Wuille +|[[bip-30]]30|https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|Duplicate transactions |Pieter Wuille |Standard |Accepted -|[[bip0031]]31|https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki|Pong message |Mike Hearn |Standard +|[[bip-31]]31|https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki|Pong message |Mike Hearn |Standard |Accepted -|[[bip0032]]32|https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki|Hierarchical Deterministic Wallets |Pieter +|[[bip-32]]32|https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki|Hierarchical Deterministic Wallets |Pieter Wuille |Informational |Accepted -|[[bip0033]]33|https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki|Stratized Nodes |Amir Taaki |Standard +|[[bip-33]]33|https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki|Stratized Nodes |Amir Taaki |Standard |Draft -|[[bip0034]]34|https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in coinbase |Gavin +|[[bip-34]]34|https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki|Block v2, Height in coinbase |Gavin Andresen |Standard |Accepted -|[[bip0035]]35|https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki|mempool message |Jeff Garzik |Standard +|[[bip-35]]35|https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki|mempool message |Jeff Garzik |Standard |Accepted -|[[bip0036]]36|https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki|Custom Services |Stefan Thomas |Standard +|[[bip-36]]36|https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki|Custom Services |Stefan Thomas |Standard |Draft -|[[bip0037]]37|https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki|Bloom filtering |Mike Hearn and Matt +|[[bip-37]]37|https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki|Bloom filtering |Mike Hearn and Matt Corallo |Standard |Accepted -|[[bip0038]]38|https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki|Passphrase-protected private key |Mike +|[[bip-38]]38|https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki|Passphrase-protected private key |Mike Caldwell |Standard |Draft -|[[bip0039]]39|https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki|Mnemonic code for generating deterministic +|[[bip-39]]39|https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki|Mnemonic code for generating deterministic keys |Slush |Standard |Draft -|[[bip0040]]40||Stratum wire protocol |Slush |Standard |BIP number allocated +|[[bip-40]]40||Stratum wire protocol |Slush |Standard |BIP number allocated -|[[bip0041]]41||Stratum mining protocol |Slush |Standard |BIP number allocated +|[[bip-41]]41||Stratum mining protocol |Slush |Standard |BIP number allocated -|[[bip0042]]42|https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki|A finite monetary supply for bitcoin +|[[bip-42]]42|https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki|A finite monetary supply for bitcoin |Pieter Wuille |Standard |Draft -|[[bip0043]]43|https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki|Purpose Field for Deterministic Wallets +|[[bip-43]]43|https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki|Purpose Field for Deterministic Wallets |Slush |Standard |Draft -|[[bip0044]]44|https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki|Multi-Account Hierarchy for Deterministic +|[[bip-44]]44|https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki|Multi-Account Hierarchy for Deterministic Wallets |Slush |Standard |Draft -|[[bip0050]]50|https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki|March 2013 Chain Fork Post-Mortem |Gavin +|[[bip-50]]50|https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki|March 2013 Chain Fork Post-Mortem |Gavin Andresen |Informational |Draft -|[[bip0060]]60|https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki|Fixed Length "version" Message +|[[bip-60]]60|https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki|Fixed Length "version" Message (Relay-Transactions Field) |Amir Taaki |Standard |Draft -|[[bip0061]]61|https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki|"reject" P2P message |Gavin Andresen +|[[bip-61]]61|https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki|"reject" P2P message |Gavin Andresen |Standard |Draft -|[[bip0062]]62|https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|Dealing with malleability |Pieter Wuille +|[[bip-62]]62|https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki|Dealing with malleability |Pieter Wuille |Standard |Draft -|[[bip0063]]63||Stealth Addresses |Peter Todd |Standard |BIP number allocated +|[[bip-63]]63||Stealth Addresses |Peter Todd |Standard |BIP number allocated -|[[bip0064]]64|https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki|getutxos message |Mike Hearn |Standard +|[[bip-64]]64|https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki|getutxos message |Mike Hearn |Standard |Draft -|[[bip0070]]70|https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki|Payment protocol |Gavin Andresen |Standard +|[[bip-70]]70|https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki|Payment protocol |Gavin Andresen |Standard |Draft -|[[bip0071]]71|https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki|Payment protocol MIME types |Gavin +|[[bip-71]]71|https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki|Payment protocol MIME types |Gavin Andresen |Standard |Draft -|[[bip0072]]72|https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki|Payment protocol URIs |Gavin Andresen +|[[bip-72]]72|https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki|Payment protocol URIs |Gavin Andresen |Standard |Draft -|[[bip0073]]73|https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki|Use "Accept" header with Payment Request +|[[bip-73]]73|https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki|Use "Accept" header with Payment Request URLs |Stephen Pair |Standard |Draft(((range="endofrange", startref="ix_appdx-bips-asciidoc0"))) |======================================================================= diff --git a/appdx-bx.asciidoc b/appdx-bx.asciidoc index 61fd2f92..64b1c7dd 100644 --- a/appdx-bx.asciidoc +++ b/appdx-bx.asciidoc @@ -114,7 +114,7 @@ $ bx ec-to-address < public_key 17re1S4Q8ZHyCP8Kw7xQad1Lr6XUzWUnkG ---- -Keys generated in this manner produce a type-0 nondeterministic wallet. That means that each key is generated from an independent seed. Bitcoin Explorer commands can also generate keys deterministically, in accordance with BIP0032. In this case, a "master" key is created from a seed and then extended deterministically to produce a tree of subkeys, resulting in a type-2 deterministic wallet. +Keys generated in this manner produce a type-0 nondeterministic wallet. That means that each key is generated from an independent seed. Bitcoin Explorer commands can also generate keys deterministically, in accordance with BIP-32. In this case, a "master" key is created from a seed and then extended deterministically to produce a tree of subkeys, resulting in a type-2 deterministic wallet. First, we we use the((("Bitcoin Explorer","seed command")))((("seed command (bx)"))) +seed+ and((("Bitcoin Explorer","hd-new command")))((("hd-new command (bx)"))) +hd-new+ commands to generate a master key that will be used as the basis to derive a hierarchy of keys. diff --git a/appdx01.asciidoc b/appdx01.asciidoc deleted file mode 100644 index 1eca6acf..00000000 --- a/appdx01.asciidoc +++ /dev/null @@ -1,81 +0,0 @@ -[[appdx01]] -[appendix] -== Bitcoin financial services - - - -This appendix describes the main financial services offered in the bitcoin economy, comparing them to traditional financial services that are already familiar to consumers. It's not a list of sites or companies, as that would go stale immediately. Instead it is a list of service primitives with examples of existing implementations. For example, an escrow -service would be described as an archetype, by analogy to a real-estate escrow, showing the unique characteristics, use case and need for escrow in the bitcoin world. The escrow service archetype would be followed by two or three examples of well implemented actual escrow services, each demonstrating a capability unique to bitcoin. - -=== Currency Exchanges - -=== Bitcoin market data services - -=== Bitcoin ticker, order book, chart and analysis services - -=== Peer-to-peer exchange - -=== OTC and Web-of-Trust (WoT) - -=== Escrow services - -=== Monitoring services - -=== Alert and notification services - -=== Lending - -=== P2P Lending - -=== Securities - -=== Mutual Funds - -=== Angel investing - -== Appendix: Bitcoin markets and applications - -As above, this appendix describes services offered in the bitcoin economy. Each service is described a a service archetype which is compared to a real-world example familiar to anyone. The description of such a service is followed by real-world examples that express -these bitcoin features. - -=== Currency transfer - -=== US domestic - -=== Other in-country - -=== International - -=== Retail commerce - -=== Physical (tangible) goods - -=== Intangible products - -=== Services - -=== Technology services - -=== Re-selling and Cross-selling - -=== Wholesale commerce - - -== Appendix: Bitcoin Protocol Structure and Conventions - -Reference index of main protocol primitives, packet structure, opcodes, state enumerations, protocol mechanics, time diagrams and protocol validation mechanisms. - - -== Appendix: Bitcoin Transaction Script Operands and Tokens - -More reference material as above - - -== Appendix: Bitcoin Cryptography Algorithms, Conventions and Conversions. - -More reference material as above - - -== Appendix: Bitcoin Meta-protocols: Mining Pool Protocols, Lightweight Client Protocols - -More reference material as above diff --git a/ch02.asciidoc b/ch02.asciidoc index c1b13189..dd72d41e 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -57,7 +57,7 @@ image::images/msbt_0202.png["payment-request"] Try to scan this with your wallet! ==== [[payment-request-URL]] -.The payment request QR code encodes the following URL, defined in BIP0021: +.The payment request QR code encodes the following URL, defined in BIP-21: ---- bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA? amount=0.015& diff --git a/ch04.asciidoc b/ch04.asciidoc index 2fdf6c8f..afb0a634 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -595,24 +595,24 @@ BTC public key: 029ade3effb0a67d5c8609850d797366af428f4a0d5194cb221d807770a15228 In the following sections we will look at advanced forms of keys and addresses, such as encrypted private keys, script and multisignature addresses, vanity addresses, and paper wallets. -==== Encrypted Private Keys (BIP0038) +==== Encrypted Private Keys (BIP-38) -((("BIP0038")))((("encrypted private keys")))((("private keys","encrypted")))((("security","encrypted private keys")))((("security","of private keys")))Private keys must remain secret. The need for _confidentiality_ of the private keys is a truism that is quite difficult to achieve in practice, because it conflicts with the equally important security objective of _availability_. ((("security","of wallet backups")))Keeping the private key private is much harder when you need to store backups of the private key to avoid losing it. A private key stored in a wallet that is encrypted by a password might be secure, but that wallet needs to be backed up. At times, users need to move keys from one wallet to another—to upgrade or replace the wallet software, for example. Private key backups might also be stored on paper (see <>) or on external storage media, such as a USB flash drive. But what if the backup itself is stolen or lost? These conflicting security goals led to the introduction of a portable and convenient standard for encrypting private keys in a way that can be understood by many different wallets and bitcoin clients, standardized by Bitcoin Improvement Proposal 38 or BIP0038 (see <>). +((("BIP-38")))((("encrypted private keys")))((("private keys","encrypted")))((("security","encrypted private keys")))((("security","of private keys")))Private keys must remain secret. The need for _confidentiality_ of the private keys is a truism that is quite difficult to achieve in practice, because it conflicts with the equally important security objective of _availability_. ((("security","of wallet backups")))Keeping the private key private is much harder when you need to store backups of the private key to avoid losing it. A private key stored in a wallet that is encrypted by a password might be secure, but that wallet needs to be backed up. At times, users need to move keys from one wallet to another—to upgrade or replace the wallet software, for example. Private key backups might also be stored on paper (see <>) or on external storage media, such as a USB flash drive. But what if the backup itself is stolen or lost? These conflicting security goals led to the introduction of a portable and convenient standard for encrypting private keys in a way that can be understood by many different wallets and bitcoin clients, standardized by Bitcoin Improvement Proposal 38 or BIP-38 (see <>). -BIP0038 proposes a common standard for encrypting private keys with a passphrase and encoding them with Base58Check so that they can be stored securely on backup media, transported securely between wallets, or kept in any other conditions where the key might be exposed. The standard for encryption uses the((("Advanced Encryption Standard (AES)"))) Advanced Encryption Standard (AES), a standard established by the National Institute of Standards and Technology (NIST) and used broadly in data encryption implementations for commercial and military applications. +BIP-38 proposes a common standard for encrypting private keys with a passphrase and encoding them with Base58Check so that they can be stored securely on backup media, transported securely between wallets, or kept in any other conditions where the key might be exposed. The standard for encryption uses the((("Advanced Encryption Standard (AES)"))) Advanced Encryption Standard (AES), a standard established by the National Institute of Standards and Technology (NIST) and used broadly in data encryption implementations for commercial and military applications. -((("Wallet Import Format (WIF)","from BIP0038 encryption")))A BIP0038 encryption scheme takes as input a bitcoin private key, usually encoded in the Wallet Import Format (WIF), as a Base58Check string with a prefix of "5". Additionally, the BIP0038 encryption scheme takes a passphrase—a long password—usually composed of several words or a complex string of alphanumeric characters. The result of the BIP0038 encryption scheme is a Base58Check-encoded encrypted private key that begins with the prefix +6P+. If you see a key that starts with +6P+, that means it is encrypted and requires a passphrase in order to convert (decrypt) it back into a WIF-formatted private key (prefix +5+) that can be used in any wallet. Many wallet applications now recognize BIP0038-encrypted private keys and will prompt the user for a passphrase to decrypt and import the key. Third-party applications, such as the incredibly useful browser-based http://bitaddress.org[Bit Address] (Wallet Details tab), can be used to decrypt BIP0038 keys. +((("Wallet Import Format (WIF)","from BIP-38 encryption")))A BIP-38 encryption scheme takes as input a bitcoin private key, usually encoded in the Wallet Import Format (WIF), as a Base58Check string with a prefix of "5". Additionally, the BIP-38 encryption scheme takes a passphrase—a long password—usually composed of several words or a complex string of alphanumeric characters. The result of the BIP-38 encryption scheme is a Base58Check-encoded encrypted private key that begins with the prefix +6P+. If you see a key that starts with +6P+, that means it is encrypted and requires a passphrase in order to convert (decrypt) it back into a WIF-formatted private key (prefix +5+) that can be used in any wallet. Many wallet applications now recognize BIP-38-encrypted private keys and will prompt the user for a passphrase to decrypt and import the key. Third-party applications, such as the incredibly useful browser-based http://bitaddress.org[Bit Address] (Wallet Details tab), can be used to decrypt BIP-38 keys. -((("paper wallets","BIP0038 encryption and")))The most common use case for BIP0038 encrypted keys is for paper wallets that can be used to back up private keys on a piece of paper. As long as the user selects a strong passphrase, a paper wallet with BIP0038 encrypted private keys is incredibly secure and a great way to create offline bitcoin storage (also known as "cold storage"). +((("paper wallets","BIP-38 encryption and")))The most common use case for BIP-38 encrypted keys is for paper wallets that can be used to back up private keys on a piece of paper. As long as the user selects a strong passphrase, a paper wallet with BIP-38 encrypted private keys is incredibly secure and a great way to create offline bitcoin storage (also known as "cold storage"). Test the encrypted keys in <> using((("bitaddress.org"))) bitaddress.org to see how you can get the decrypted key by entering the passphrase. [[table_4-10]] -.Example of BIP0038 encrypted private key +.Example of BIP-38 encrypted private key |======= | *Private Key (WIF)* | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn | *Passphrase* | MyTestPassphrase -| *Encrypted Key (BIP0038)* | 6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctLJ3z5yxE87MobKoXdTsJ +| *Encrypted Key (BIP-38)* | 6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctLJ3z5yxE87MobKoXdTsJ |======= @@ -621,7 +621,7 @@ Test the encrypted keys in <> using((("bitaddress.org"))) bitaddress ((("addresses, bitcoin","multi-signature addresses")))((("addresses, bitcoin","Pay-to-Script Hash (P2SH)")))((("multi-signature addresses")))((("Pay-to-Script Hash (P2SH)")))As we know, traditional bitcoin addresses begin with the number “1” and are derived from the public key, which is derived from the private key. Although anyone can send bitcoin to a “1” address, that bitcoin can only be spent by presenting the corresponding private key signature and public key hash. -Bitcoin addresses that begin with the number “3” are pay-to-script hash (P2SH) addresses, sometimes erroneously called multi-signature or multi-sig addresses. They designate the beneficiary of a bitcoin transaction as the hash of a script, instead of the owner of a public key. The feature was introduced in January 2012 with Bitcoin Improvement Proposal 16, or BIP0016 (see <>), and is being widely adopted because it provides the opportunity to add functionality to the address itself. Unlike transactions that "send" funds to traditional “1” bitcoin addresses, also known as((("BIP0016")))((("Pay-to-Public-Key-Hash (P2PKH)"))) pay-to-public-key-hash (P2PKH), funds sent to “3” addresses require something more than the presentation of one public key hash and one private key signature as proof of ownership. The requirements are designated at the time the address is created, within the script, and all inputs to this address will be encumbered with the same requirements. +Bitcoin addresses that begin with the number “3” are pay-to-script hash (P2SH) addresses, sometimes erroneously called multi-signature or multi-sig addresses. They designate the beneficiary of a bitcoin transaction as the hash of a script, instead of the owner of a public key. The feature was introduced in January 2012 with Bitcoin Improvement Proposal 16, or BIP-16 (see <>), and is being widely adopted because it provides the opportunity to add functionality to the address itself. Unlike transactions that "send" funds to traditional “1” bitcoin addresses, also known as((("BIP-16")))((("Pay-to-Public-Key-Hash (P2PKH)"))) pay-to-public-key-hash (P2PKH), funds sent to “3” addresses require something more than the presentation of one public key hash and one private key signature as proof of ownership. The requirements are designated at the time the address is created, within the script, and all inputs to this address will be encumbered with the same requirements. A pay-to-script hash address is created from a transaction script, which defines who can spend a transaction output (for more detail, see <>). Encoding a pay-to-script hash address involves using the same double-hash function as used during creation of a bitcoin address, only applied on the script instead of the public key: @@ -782,7 +782,7 @@ Paper wallets come in many shapes, sizes, and designs, but at a very basic level .An example of a simple paper wallet from bitaddress.org image::images/msbt_0414.png[] -The disadvantage of the simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoins locked with those keys. A more sophisticated paper wallet storage system uses BIP0038 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. <> shows a paper wallet with an encrypted private key (BIP0038) created on the bitaddress.org site. +The disadvantage of the simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoins locked with those keys. A more sophisticated paper wallet storage system uses BIP-38 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. <> shows a paper wallet with an encrypted private key (BIP-38) created on the bitaddress.org site. [[paper_wallet_encrypted]] .An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test." diff --git a/ch05-orig.asciidoc b/ch05-orig.asciidoc index 2f89fce8..b6b23435 100644 --- a/ch05-orig.asciidoc +++ b/ch05-orig.asciidoc @@ -561,7 +561,7 @@ If the redeem script hash matches, the unlocking script is executed on its own, ===== Pay-to-script-hash addresses -((("addresses, bitcoin","Pay-to-Script-Hash (P2SH)")))((("Pay-to-script-hash (P2SH)","addresses")))Another important part of the P2SH feature is the ability to encode a script hash as an address, as defined in BIP0013. P2SH addresses are Base58Check encodings of the 20-byte hash of a script, just like bitcoin addresses are Base58Check encodings of the 20-byte hash of a public key. P2SH addresses use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". For example, Mohammed's complex script, hashed and Base58Check-encoded as a P2SH address becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+. Now, Mohammed can give this "address" to his customers and they can use almost any bitcoin wallet to make a simple payment, as if it were a bitcoin address. The 3 prefix gives them a hint that this is a special type of address, one corresponding to a script instead of a public key, but otherwise it works in exactly the same way as a payment to a bitcoin address. +((("addresses, bitcoin","Pay-to-Script-Hash (P2SH)")))((("Pay-to-script-hash (P2SH)","addresses")))Another important part of the P2SH feature is the ability to encode a script hash as an address, as defined in BIP-13. P2SH addresses are Base58Check encodings of the 20-byte hash of a script, just like bitcoin addresses are Base58Check encodings of the 20-byte hash of a public key. P2SH addresses use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". For example, Mohammed's complex script, hashed and Base58Check-encoded as a P2SH address becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+. Now, Mohammed can give this "address" to his customers and they can use almost any bitcoin wallet to make a simple payment, as if it were a bitcoin address. The 3 prefix gives them a hint that this is a special type of address, one corresponding to a script instead of a public key, but otherwise it works in exactly the same way as a payment to a bitcoin address. P2SH addresses hide all of the complexity, so that the person making a payment does not see the script. diff --git a/ch05.asciidoc b/ch05.asciidoc index 8a3e7adf..df9fb3bf 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -46,7 +46,7 @@ image::images/deterministic_wallet.png["Deterministic Wallet"] ==== Seeds and Mnemonic Code Words -Deterministic wallets are a very powerful model for managing many keys and addresses. They are even more useful if they are combined with a standardized way of creating seeds from a sequence of english words that are easy to transcribe, export and import across wallets. This is known as a _mnemonic_ and the standard is defined by BIP0039. Today, most bitcoin wallets (as well as wallets for other crypto-currencies) use this standard and can import and export seeds for backup and recovery using interoperable mnemonics. +Deterministic wallets are a very powerful model for managing many keys and addresses. They are even more useful if they are combined with a standardized way of creating seeds from a sequence of english words that are easy to transcribe, export and import across wallets. This is known as a _mnemonic_ and the standard is defined by BIP-39. Today, most bitcoin wallets (as well as wallets for other crypto-currencies) use this standard and can import and export seeds for backup and recovery using interoperable mnemonics. Let's look at this from a practical perspective. Which of the following seeds is easier to transcribe, record on paper, read without error, export and import into another wallet? @@ -72,7 +72,7 @@ garbage claim echo media make crunch |=== [[mnemonic_code_words]] -===== Mnemonic Code Words (BIP0039) +===== Mnemonic Code Words (BIP-39) ((("deterministic wallets","mnemonic code words")))((("mnemonic code words")))((("seeded wallets","mnemonic code words")))Mnemonic code words are word sequences that represent (encode) a random number used as a seed to derive a deterministic wallet. The sequence of words is sufficient to re-create the seed and from there re-create the wallet and all the derived keys. A wallet application that implements deterministic wallets with mnemonic words will show the user a sequence of 12 to 24 words when first creating a wallet. That sequence of words is the wallet backup and can be used to recover and re-create all the keys in the same or any compatible wallet application. Mnemonic words make it easier for users to back up wallets because they are easy to read and correctly transcribe, as compared to a random sequence of numbers. @@ -81,14 +81,14 @@ garbage claim echo media make crunch Mnemonic words are often confused with "brainwallets". They are not the same. The primary difference is that a brainwallet consists of words chosen by the user, whereas menmonic words are created randomly by the wallet and presented to the user. This important difference makes mnemonic words much more secure, because humans are very poor sources of randomness. ==== -Mnemonic codes are defined in((("BIP0039"))) Bitcoin Improvement Proposal 39 (see <>). Note that BIP0039 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP0039. BIP0039 was proposed by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) company behind the Trezor hardware wallet and is incompatible with Electrum's implementation. However, BIP0039 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. +Mnemonic codes are defined in((("BIP-39"))) Bitcoin Improvement Proposal 39 (see <>). Note that BIP-39 is one implementation of a mnemonic code standard. Specifically, there is a different standard, with a different set of words, used by the((("Electrum wallet")))((("mnemonic code words","Electrum wallet and"))) Electrum wallet and predating BIP-39. BIP-39 was proposed by the((("mnemonic code words","Trezor wallet and")))((("Trezor wallet"))) company behind the Trezor hardware wallet and is incompatible with Electrum's implementation. However, BIP-39 has now achieved broad industry support across dozens of interoperable implementations and should be considered the de-facto industry standard. -BIP0039 defines the creation of a mnemonic code and seed, which we describe here in 9 steps. For clarity, the process is split in two parts: Steps 1 through 6 are shown in <> and steps 7 through 9 are shown in <>. +BIP-39 defines the creation of a mnemonic code and seed, which we describe here in 9 steps. For clarity, the process is split in two parts: Steps 1 through 6 are shown in <> and steps 7 through 9 are shown in <>. [[generating_mnemonic_words]] ===== Generating Mnemonic Words -Mnemonic words are generated automatically by the wallet, using a standardized process defined in BIP0039. The wallet starts from a source of entropy, adds a checksum and then maps the entropy to a word list: +Mnemonic words are generated automatically by the wallet, using a standardized process defined in BIP-39. The wallet starts from a source of entropy, adds a checksum and then maps the entropy to a word list: 1. Create a random sequence (entropy) of 128 to 256 bits. 2. Create a checksum of the random sequence by taking the first four bits of its SHA256 hash. @@ -119,7 +119,7 @@ The table <>, shows the relationship between the size of entropy data The mnemonic words represent entropy with a length of 128 to 256 bits. The entropy is then used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The seed produced is then used to build a deterministic wallet and derive its keys. -The key-stretching function takes two parameters: the mnemonic and a _salt_. The purpose of a salt in a key-stretching function is to make it difficult to build a lookup table enabling a brute force attack. In the BIP0039 standard, the salt has another purpose - it allows the introduction of a passphrase which serves as an additional security factor protecting the seed, as we will describe in more detail in <>. +The key-stretching function takes two parameters: the mnemonic and a _salt_. The purpose of a salt in a key-stretching function is to make it difficult to build a lookup table enabling a brute force attack. In the BIP-39 standard, the salt has another purpose - it allows the introduction of a passphrase which serves as an additional security factor protecting the seed, as we will describe in more detail in <>. The process described in steps 7 through 9 below continues from the process described previously in <>. @@ -172,13 +172,13 @@ luggage oxygen faint major edit measure invite love trap field dilemma oblige+ |======= [[mnemonic_passphrase]] -===== Optional Passphrase in BIP0039 +===== Optional Passphrase in BIP-39 -The BIP0039 standard allows the use of an optional passphrase in the derivation of the seed. If no passphrase is used, the mnemonic is stretched with a salt consisting of the constant string "+mnemonic+", producing a specific 512-bit seed from any given mnemonic. If a passphrase is used, the stretching function produces a _different_ seed from that same mnemonic. In fact, given a single mnemonic, every possible passphrase leads to a different seed. Essentially, there is no "wrong" passphrase. All passphrases are valid and they all lead to different seeds, forming a vast set of possible uninitialized wallets. The set of possible wallets is so large (2^512^) that there is no practical possibility of brute-forcing or accidentally guessing one that is in use. +The BIP-39 standard allows the use of an optional passphrase in the derivation of the seed. If no passphrase is used, the mnemonic is stretched with a salt consisting of the constant string "+mnemonic+", producing a specific 512-bit seed from any given mnemonic. If a passphrase is used, the stretching function produces a _different_ seed from that same mnemonic. In fact, given a single mnemonic, every possible passphrase leads to a different seed. Essentially, there is no "wrong" passphrase. All passphrases are valid and they all lead to different seeds, forming a vast set of possible uninitialized wallets. The set of possible wallets is so large (2^512^) that there is no practical possibility of brute-forcing or accidentally guessing one that is in use. [TIP] ==== -There are no "wrong" passphrases in BIP0039. Every passphrase leads to some wallet, which unless previously used will be empty. +There are no "wrong" passphrases in BIP-39. Every passphrase leads to some wallet, which unless previously used will be empty. ==== The optional passphrase creates two important features: @@ -196,9 +196,9 @@ However, it is important to note that the use of a passphrase also introduces th While passphrases are very useful, they should only be used in combination with a carefully planned process for backup and recovery, considering the possibility of surviving the owner and allowing their family to recover their crypto-currency estate. [[hd_wallets]] -==== Hierarchical Deterministic Wallets (BIP0032/BIP0044) +==== Hierarchical Deterministic Wallets (BIP-32/BIP-44) -((("deterministic wallets","hierarchical", id="ix_ch04-asciidoc24", range="startofrange")))((("hierarchical deterministic wallets (HD wallets)", id="ix_ch04-asciidoc25", range="startofrange")))((("BIP0032", id="ix_ch04-asciidoc25a", range="startofrange")))((("BIP0044", id="ix_ch04-asciidoc25b", range="startofrange")))Deterministic wallets were developed to make it easy to derive many keys from a single "seed." The most advanced form of deterministic wallets is the _hierarchical deterministic wallet_ or _HD wallet_ defined by the BIP0032 standard. Hierarchical deterministic wallets contain keys derived in a tree structure, such that a parent key can derive a sequence of children keys, each of which can derive a sequence of grandchildren keys, and so on, to an infinite depth. This tree structure is illustrated in <>.((("hierarchical deterministic wallets (HD wallets)","tree structure for"))) +((("deterministic wallets","hierarchical", id="ix_ch04-asciidoc24", range="startofrange")))((("hierarchical deterministic wallets (HD wallets)", id="ix_ch04-asciidoc25", range="startofrange")))((("BIP-32", id="ix_ch04-asciidoc25a", range="startofrange")))((("BIP-44", id="ix_ch04-asciidoc25b", range="startofrange")))Deterministic wallets were developed to make it easy to derive many keys from a single "seed." The most advanced form of deterministic wallets is the _hierarchical deterministic wallet_ or _HD wallet_ defined by the BIP-32 standard. Hierarchical deterministic wallets contain keys derived in a tree structure, such that a parent key can derive a sequence of children keys, each of which can derive a sequence of grandchildren keys, and so on, to an infinite depth. This tree structure is illustrated in <>.((("hierarchical deterministic wallets (HD wallets)","tree structure for"))) [[Type2_wallet]] .Type-2 hierarchical deterministic wallet: a tree of keys generated from a single seed @@ -206,7 +206,7 @@ image::images/msbt_0409.png["HD wallet"] [TIP] ==== -If you are implementing a bitcoin wallet, it should be built as an HD wallet following the BIP0032 and BIP0044 standards. +If you are implementing a bitcoin wallet, it should be built as an HD wallet following the BIP-32 and BIP-44 standards. ==== HD wallets offer two major advantages over random (nondeterministic) keys. First, the tree structure can be used to express additional organizational meaning, such as when a specific branch of subkeys is used to receive incoming payments and a different branch is used to receive change from outgoing payments. Branches of keys can also be used in a corporate setting, allocating different branches to departments, subsidiaries, specific functions, or accounting categories. @@ -273,7 +273,7 @@ Think of an extended key as the root of a branch in the tree structure of the HD An extended key consists of a private or public key and chain code. An extended key can create children, generating its own branch in the tree structure. Sharing an extended key gives access to the entire branch. ==== -((("Base58Check encoding","extended keys and")))Extended keys are encoded using Base58Check, to easily export and import between different BIP0032-compatible wallets. The Base58Check coding for extended keys uses a special version number that results in the prefix "xprv" and "xpub" when encoded in Base58 characters, to make them easily recognizable. Because the extended key is 512 or 513 bits, it is also much longer than other Base58Check-encoded strings we have seen previously. +((("Base58Check encoding","extended keys and")))Extended keys are encoded using Base58Check, to easily export and import between different BIP-32-compatible wallets. The Base58Check coding for extended keys uses a special version number that results in the prefix "xprv" and "xpub" when encoded in Base58 characters, to make them easily recognizable. Because the extended key is 512 or 513 bits, it is also much longer than other Base58Check-encoded strings we have seen previously. Here's an example of an extended private key, encoded in Base58Check: @@ -345,13 +345,13 @@ The "ancestry" of a key is read from right to left, until you reach the master k ===== Navigating the HD wallet tree structure -((("BIP0043")))((("hierarchical deterministic wallets (HD wallets)","navigating")))((("hierarchical deterministic wallets (HD wallets)","tree structure for")))The HD wallet tree structure offers tremendous flexibility. Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on. The tree can be as deep as you want, with an infinite number of generations. With all that flexibility, however, it becomes quite difficult to navigate this infinite tree. It is especially difficult to transfer HD wallets between implementations, because the possibilities for internal organization into branches and subbranches are endless. +((("BIP-43")))((("hierarchical deterministic wallets (HD wallets)","navigating")))((("hierarchical deterministic wallets (HD wallets)","tree structure for")))The HD wallet tree structure offers tremendous flexibility. Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on. The tree can be as deep as you want, with an infinite number of generations. With all that flexibility, however, it becomes quite difficult to navigate this infinite tree. It is especially difficult to transfer HD wallets between implementations, because the possibilities for internal organization into branches and subbranches are endless. -Two Bitcoin Improvement Proposals (BIPs) offer a solution to this complexity, by creating some proposed standards for the structure of HD wallet trees. BIP0043 proposes the use of the first hardened child index as a special identifier that signifies the "purpose" of the tree structure. Based on BIP0043, an HD wallet should use only one level-1 branch of the tree, with the index number identifying the structure and namespace of the rest of the tree by defining its purpose. For example, an HD wallet using only branch m/i'/ is intended to signify a specific purpose and that purpose is identified by index number "i". +Two Bitcoin Improvement Proposals (BIPs) offer a solution to this complexity, by creating some proposed standards for the structure of HD wallet trees. BIP-43 proposes the use of the first hardened child index as a special identifier that signifies the "purpose" of the tree structure. Based on BIP-43, an HD wallet should use only one level-1 branch of the tree, with the index number identifying the structure and namespace of the rest of the tree by defining its purpose. For example, an HD wallet using only branch m/i'/ is intended to signify a specific purpose and that purpose is identified by index number "i". -((("multiaccount structure")))Extending that specification, BIP0044 proposes a multiaccount structure as "purpose" number +44'+ under BIP0043. All HD wallets following the BIP0044 structure are identified by the fact that they only used one branch of the tree: m/44'/. +((("multiaccount structure")))Extending that specification, BIP-44 proposes a multiaccount structure as "purpose" number +44'+ under BIP-43. All HD wallets following the BIP-44 structure are identified by the fact that they only used one branch of the tree: m/44'/. -BIP0044 specifies the structure as consisting of five predefined tree levels: +BIP-44 specifies the structure as consisting of five predefined tree levels: +m / purpose' / coin_type' / account' / change / address_index+ @@ -362,7 +362,7 @@ BIP0044 specifies the structure as consisting of five predefined tree levels: ((("change level (multiaccount structure)")))On the fourth level, "change," an HD wallet has two subtrees, one for creating receiving addresses and one for creating change addresses. Note that whereas the previous levels used hardened derivation, this level uses normal derivation. This is to allow this level of the tree to export extended public keys for use in a nonsecured environment. Usable addresses are derived by the HD wallet as children of the fourth level, making the fifth level of the tree the "address_index." For example, the third receiving address for bitcoin payments in the primary account would be M/44'/0'/0'/0/2. <> shows a few more examples. [[table_4-9]] -.BIP0044 HD wallet structure examples +.BIP-44 HD wallet structure examples [options="header"] |======= |HD path | Key described @@ -375,7 +375,7 @@ BIP0044 specifies the structure as consisting of five predefined tree levels: ===== Experimenting with HD wallets using Bitcoin Explorer -((("hierarchical deterministic wallets (HD wallets)","Bitcoin Explorer and")))((("Bitcoin Explorer","HD wallets and")))Using the Bitcoin Explorer command-line tool introduced in <>, you can experiment with generating and extending BIP0032 deterministic keys, as well as displaying them in different formats((("Bitcoin Explorer","seed command")))((("seed command (bx)")))((("Bitcoin Explorer","hd-seed command")))((("hd-seed command (bx)")))((("Bitcoin Explorer","hd-public command")))((("hd-public command (bx)")))((("Bitcoin Explorer","hd-private command")))((("hd-private command (bx)")))((("Bitcoin Explorer","hd-to-address command")))((("hd-to-address command (bx)")))((("Bitcoin Explorer","hd-to-wif command")))((("hd-to-wif command (bx)"))): (((range="endofrange", startref="ix_ch04-asciidoc25b")))(((range="endofrange", startref="ix_ch04-asciidoc25a")))(((range="endofrange", startref="ix_ch04-asciidoc25")))(((range="endofrange", startref="ix_ch04-asciidoc24")))(((range="endofrange", startref="ix_ch04-asciidoc23"))) +((("hierarchical deterministic wallets (HD wallets)","Bitcoin Explorer and")))((("Bitcoin Explorer","HD wallets and")))Using the Bitcoin Explorer command-line tool introduced in <>, you can experiment with generating and extending BIP-32 deterministic keys, as well as displaying them in different formats((("Bitcoin Explorer","seed command")))((("seed command (bx)")))((("Bitcoin Explorer","hd-seed command")))((("hd-seed command (bx)")))((("Bitcoin Explorer","hd-public command")))((("hd-public command (bx)")))((("Bitcoin Explorer","hd-private command")))((("hd-private command (bx)")))((("Bitcoin Explorer","hd-to-address command")))((("hd-to-address command (bx)")))((("Bitcoin Explorer","hd-to-wif command")))((("hd-to-wif command (bx)"))): (((range="endofrange", startref="ix_ch04-asciidoc25b")))(((range="endofrange", startref="ix_ch04-asciidoc25a")))(((range="endofrange", startref="ix_ch04-asciidoc25")))(((range="endofrange", startref="ix_ch04-asciidoc24")))(((range="endofrange", startref="ix_ch04-asciidoc23"))) ==== [source, bash] diff --git a/ch06-orig.asciidoc b/ch06-orig.asciidoc index 68c97799..7252f467 100644 --- a/ch06-orig.asciidoc +++ b/ch06-orig.asciidoc @@ -238,7 +238,7 @@ On the contrary, if a pattern is tested against the bloom filter and any one of .Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!" image::images/msbt_0612.png[] -Bitcoin's implementation of bloom filters is described in Bitcoin Improvement Proposal 37 (BIP0037). See <> or visit http://bit.ly/1x6qCiO[GitHub]. +Bitcoin's implementation of bloom filters is described in Bitcoin Improvement Proposal 37 (BIP-37). See <> or visit http://bit.ly/1x6qCiO[GitHub]. === Bloom Filters and Inventory Updates diff --git a/ch08-orig.asciidoc b/ch08-orig.asciidoc index c75a3871..90ef7aaf 100644 --- a/ch08-orig.asciidoc +++ b/ch08-orig.asciidoc @@ -341,7 +341,7 @@ In a generation transaction, the first two fields are set to values that do not In the genesis block, for example, Satoshi Nakamoto added the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the coinbase data, using it as a proof of the date and to convey a message. Currently, miners use the coinbase data to include extra nonce values and strings identifying the mining pool, as we will see in the following sections. -The first few bytes of the coinbase used to be arbitrary, but that is no longer the case. As per Bitcoin Improvement Proposal 34 (BIP0034), version-2 blocks (blocks with the version field set to 2) must contain the block height index as a script "push" operation in the beginning of the coinbase field. +The first few bytes of the coinbase used to be arbitrary, but that is no longer the case. As per Bitcoin Improvement Proposal 34 (BIP-34), version-2 blocks (blocks with the version field set to 2) must contain the block height index as a script "push" operation in the beginning of the coinbase field. In block 277,316 we see that the coinbase (see <>), which is in the "Unlocking Script" or +scriptSig+ field of the transaction input, contains the hexadecimal value +03443b0403858402062f503253482f+. Let's decode this value. @@ -349,7 +349,7 @@ The first byte, +03+, instructs the script execution engine to push the next thr The next few hexadecimal digits (+03858402062+) are used to encode an extra _nonce_ (see <>), or random value, used to find a suitable proof of work solution. -The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string +/P2SH/+, which indicates that the mining node that mined this block supports the((("pay-to-script-hash (P2SH)","coinbase data and"))) pay-to-script-hash (P2SH) improvement defined in BIP0016. The introduction of the P2SH capability required a "vote" by miners to endorse either BIP0016 or BIP0017. Those endorsing the BIP0016 implementation were to include +/P2SH/+ in their coinbase data. Those endorsing the BIP0017 implementation of P2SH were to include the string +p2sh/CHV+ in their coinbase data. The BIP0016 was elected as the winner, and many miners continued including the string +/P2SH/+ in their coinbase to indicate support for this feature. +The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string +/P2SH/+, which indicates that the mining node that mined this block supports the((("pay-to-script-hash (P2SH)","coinbase data and"))) pay-to-script-hash (P2SH) improvement defined in BIP-16. The introduction of the P2SH capability required a "vote" by miners to endorse either BIP-16 or BIP-17. Those endorsing the BIP-16 implementation were to include +/P2SH/+ in their coinbase data. Those endorsing the BIP-17 implementation of P2SH were to include the string +p2sh/CHV+ in their coinbase data. The BIP-16 was elected as the winner, and many miners continued including the string +/P2SH/+ in their coinbase to indicate support for this feature. <> uses the libbitcoin library introduced in <> to extract the coinbase data from the genesis block, displaying Satoshi's message. Note that the libbitcoin library contains a static copy of the genesis block, so the example code can retrieve the genesis block directly from the library. diff --git a/ch10-orig.asciidoc b/ch10-orig.asciidoc index caf6d9a7..51376e4b 100644 --- a/ch10-orig.asciidoc +++ b/ch10-orig.asciidoc @@ -49,7 +49,7 @@ Over the past three years, as a direct result of bitcoin adoption, we have seen ==== Physical Bitcoin Storage -((("backups","cold-storage wallets")))((("bitcoin","storage, physical")))((("cold-storage wallets")))((("paper wallets")))((("user security","physical bitcoin storage")))Because most users are far more comfortable with physical security than information security, a very effective method for protecting bitcoins is to convert them into physical form. Bitcoin keys are nothing more than long numbers. This means that they can be stored in a physical form, such as printed on paper or etched on a metal coin. Securing the keys then becomes as simple as physically securing the printed copy of the bitcoin keys. A set of bitcoin keys that is printed on paper is called a "paper wallet," and there are many free tools that can be used to create them. I personally keep the vast majority of my bitcoins (99% or more) stored on paper wallets, encrypted with BIP0038, with multiple copies locked in safes. Keeping bitcoin offline is called _cold storage_ and it is one of the most effective security techniques. A cold storage system is one where the keys are generated on an offline system (one never connected to the Internet) and stored offline either on paper or on digital media, such as a USB memory stick. +((("backups","cold-storage wallets")))((("bitcoin","storage, physical")))((("cold-storage wallets")))((("paper wallets")))((("user security","physical bitcoin storage")))Because most users are far more comfortable with physical security than information security, a very effective method for protecting bitcoins is to convert them into physical form. Bitcoin keys are nothing more than long numbers. This means that they can be stored in a physical form, such as printed on paper or etched on a metal coin. Securing the keys then becomes as simple as physically securing the printed copy of the bitcoin keys. A set of bitcoin keys that is printed on paper is called a "paper wallet," and there are many free tools that can be used to create them. I personally keep the vast majority of my bitcoins (99% or more) stored on paper wallets, encrypted with BIP-38, with multiple copies locked in safes. Keeping bitcoin offline is called _cold storage_ and it is one of the most effective security techniques. A cold storage system is one where the keys are generated on an offline system (one never connected to the Internet) and stored offline either on paper or on digital media, such as a USB memory stick. ==== Hardware Wallets diff --git a/glossary.asciidoc b/glossary.asciidoc index 4da3d496..6abd2d39 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -7,7 +7,7 @@ address:: A bitcoin address looks like +1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV+. It consists of a string of letters and numbers starting with the digit 1 or 3. Just like you ask others to send an email to your email address, you would ask others to send you bitcoin to your bitcoin address.((("bitcoin address")))((("address", see="bitcoin address")))((("public key", see="bitcoin address"))) bip:: - Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP0021 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.((("bip"))) + Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP-21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.((("bip"))) bitcoin:: The name of the currency unit (the coin), the network, and the software.((("bitcoin"))) diff --git a/planned_toc.asciidoc b/planned_toc.asciidoc deleted file mode 100644 index fa9dd15f..00000000 --- a/planned_toc.asciidoc +++ /dev/null @@ -1,80 +0,0 @@ -= Planned Chapters - -= Chapter 4 - Wallets, Keys and Addresses -== Introduction -== Wallets & Keys -=== Public Key Cryptography -=== Elliptic Curves -=== Key Generation -==== Non-Deterministic (Random) -==== Deterministic (Seeded) -==== Seed Words (BIP0039) -==== Deterministic Chains (Electrum Key Chains) -==== Deterministic Trees (BIP0032) -=== Keys Formats and Addresses -==== Base58 and Base58Check Encoding -==== Compressed Keys -==== Encrypted Keys (BIP0038) -==== Addresses -==== Pay To Script Hash Addresses (P2SH) -==== Multi-Signature Addresses -==== Vanity Addresses - - -= Chapter 5 - Transactions -== Introduction -== ScriptPubKey and ScriptSig -== Transaction Script Language -== Stack-Based Script Evaluation -== Common Transaction Scripts -== Complex Transaction Scripts -== P2SH Scripts -== Multi-Signature Scripts -== Transaction Malleability - -= Chapter 6 - The Blockchain & Mining -== Introduction -== The Blockchain -== Genesis Block -== Proof-of-Work (Mining) and Consensus -=== Consensus Mechanism -=== Proof-of-Work Algorithm -=== Difficulty Target and Re-Targetting -=== Highest Difficulty Chain Selection -=== Competition and Coinbase -=== Mining Pools -==== Managed Pools -==== P2Pool -=== Mining Economics -=== Consensus Attacks -==== 51% Attack -==== Selfish Mining Attack -== Chain Forking -=== Normal Forks -=== Soft Forks -=== Hard Forks -=== Unusual Forks - - -= Chapter 7 - The Bitcoin Network -== Introduction -== Peer-to-Peer Network Architecture -== Nodes and Roles -== Network Discovery -== Network Protocol Messages -== Bitcoin Core Node -== Alternative Node Implementations - - -= Chapter 8 - Altcoins -== Alternative Currency Chains (Alt-Coins) -=== Alternative Consensus Algorithms -==== Proof-of-Work -===== Scrypt -===== Dagger/Slasher -===== "Useful" Work (Prime, Protein etc) -==== Proof-of-Stake -==== Proof-of-Resource and Proof-of-Publishing -== Alternative Chains Beyond Currency -=== Decentralized Naming (Namecoin) -=== Decentralized Contract Platform (Ethereum) diff --git a/selected BIPs/bip-0001.asciidoc b/selected BIPs/bip-0001.asciidoc deleted file mode 100644 index c1755f92..00000000 --- a/selected BIPs/bip-0001.asciidoc +++ /dev/null @@ -1,370 +0,0 @@ ------------------------------------ - BIP: 1 - Title: BIP Purpose and Guidelines - Status: Accepted - Type: Standards Track - Created: 2011-08-19 ------------------------------------ - -[[what-is-a-bip]] -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]] -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 validity rules, or any change or addition -that affects the interoperability of applications using Bitcoin. -* An Informational BIP describes a Bitcoin design issue, or provides -general guidelines or information to the Bitcoin community, but does not -propose a new feature. Informational BIPs do not necessarily represent a -Bitcoin community consensus or recommendation, so users and implementors -are free to ignore Informational BIPs or follow their advice. -* A Process BIP describes a process surrounding Bitcoin, or proposes a -change to (or an event in) a process. Process BIPs are like Standards -Track BIPs but apply to areas other than the Bitcoin protocol itself. -They may propose an implementation, but not to Bitcoin's codebase; they -often require community consensus; unlike Informational BIPs, they are -more than recommendations, and users are typically not free to ignore -them. Examples include procedures, guidelines, changes to the -decision-making process, and changes to the tools or environment used in -Bitcoin development. Any meta-BIP is also considered a Process BIP. - -[[bip-work-flow]] -BIP Work Flow -~~~~~~~~~~~~~ - -The BIP editors assign BIP numbers and change their status. Please send -all BIP-related email to the BIP editor, which is listed under -link:#BIP_Editors[BIP Editors] below. Also see -link:#BIP_Editor_Responsibilities__Workflow[BIP Editor Responsibilities -& Workflow]. - -The BIP process begins with a new idea for Bitcoin. It is highly -recommended that a single BIP contain a single key proposal or new idea. -Small enhancements or patches often don't need a BIP and can be injected -into the Bitcoin development work flow with a patch submission to the -Bitcoin issue tracker. The more focused the BIP, the more successful it -tends to be. The BIP editor reserves the right to reject BIP proposals -if they appear too unfocused or too broad. If in doubt, split your BIP -into several well-focused ones. - -Each BIP must have a champion -- someone who writes the BIP using the -style and format described below, shepherds the discussions in the -appropriate forums, and attempts to build community consensus around the -idea. The BIP champion (a.k.a. Author) should first attempt to ascertain -whether the idea is BIP-able. Posting to the -http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development[bitcoin-development@lists.sourceforge.net] -mailing list (and maybe the -https://bitcointalk.org/index.php?board=6.0[Development&Technical -Discussion] forum) is the best way to go about this. - -Vetting an idea publicly before going as far as writing a BIP is meant -to save the potential author time. Many ideas have been brought forward -for changing Bitcoin that have been rejected for various reasons. Asking -the Bitcoin community first if an idea is original helps prevent too -much time being spent on something that is guaranteed to be rejected -based on prior discussions (searching the internet does not always do -the trick). It also helps to make sure the idea is applicable to the -entire community and not just the author. Just because an idea sounds -good to the author does not mean it will work for most people in most -areas where Bitcoin is used. - -Once the champion has asked the Bitcoin community as to whether an idea -has any chance of acceptance, a draft BIP should be presented to -http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development[bitcoin-development@lists.sourceforge.net]. -This gives the author a chance to flesh out the draft BIP to make -properly formatted, of high quality, and to address initial concerns -about the proposal. - -Following a discussion, the proposal should be sent to the Bitcoin-dev -list and the BIP editor with the draft BIP. This draft must be written -in BIP style as described below, else it will be sent back without -further regard until proper formatting rules are followed. - -If the BIP editor approves, he will assign the BIP a number, label it as -Standards Track, Informational, or Process, give it status "Draft", and -add it to the git repository. The BIP editor will not unreasonably deny -a BIP. Reasons for denying BIP status include duplication of effort, -being technically unsound, not providing proper motivation or addressing -backwards compatibility, or not in keeping with the Bitcoin philosophy. - -The BIP author may update the Draft as necessary in the git repository. -Updates to drafts may also be submitted by the author as pull requests. - -Standards Track BIPs consist of two parts, a design document and a -reference implementation. The BIP should be reviewed and accepted before -a reference implementation is begun, unless a reference implementation -will aid people in studying the BIP. Standards Track BIPs must include -an implementation -- in the form of code, a patch, or a URL to same -- -before it can be considered Final. - -BIP authors are responsible for collecting community feedback on a BIP -before submitting it for review. However, wherever possible, long -open-ended discussions on public mailing lists should be avoided. -Strategies to keep the discussions efficient include: setting up a -separate SIG mailing list for the topic, having the BIP author accept -private comments in the early design phases, setting up a wiki page or -git repository, etc. BIP authors should use their discretion here. - -For a BIP to be accepted it must meet certain minimum criteria. It must -be a clear and complete description of the proposed enhancement. The -enhancement must represent a net improvement. The proposed -implementation, if applicable, must be solid and must not complicate the -protocol unduly. - -Once a BIP has been accepted, the reference implementation must be -completed. When the reference implementation is complete and accepted by -the community, the status will be changed to "Final". - -A BIP can also be assigned status "Deferred". The BIP author or editor -can assign the BIP this status when no progress is being made on the -BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft -status. - -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: - -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]] -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. - -* Specification -- The technical specification should describe the -syntax and semantics of any new feature. The specification should be -detailed enough to allow competing, interoperable implementations for -any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, -libbitcoin). - -* Motivation -- The motivation is critical for BIPs that want to change -the Bitcoin protocol. It should clearly explain why the existing -protocol specification is inadequate to address the problem that the BIP -solves. BIP submissions without sufficient motivation may be rejected -outright. - -* 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]] -BIP Formats and Templates -~~~~~~~~~~~~~~~~~~~~~~~~~ - -BIPs should be written in mediawiki or markdown format. Image files -should be included in a subdirectory for that BIP. - -[[bip-header-preamble]] -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 -yyyy-mm-dd format, e.g. 2001-08-14. - -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]] -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-editors]] -BIP Editors -~~~~~~~~~~~ - -The current BIP editor is Gregory Maxwell who can be contacted at -gmaxwell@gmail.com. - -[[bip-editor-responsibilities-workflow]] -BIP Editor Responsibilities & Workflow -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -A BIP editor must subscribe to the Bitcoin development mailing list. All -BIP-related correspondence should be sent (or CC'd) to -gmaxwell@gmail.com. - -For each new BIP that comes in an editor does the following: - -* 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). - -* Add the BIP to the https://github.com/bitcoin/bips[bitcoin/bips] -repository on GitHub. - -* List the BIP in README.mediawiki - -* 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]] -History -~~~~~~~ - -This document was derived heavily from Python's PEP-0001. In many places -text was simply copied and modified. Although the PEP-0001 text was -written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not -responsible for its use in the Bitcoin Improvement Process, and should -not be bothered with technical questions specific to Bitcoin or the BIP -process. Please direct all comments to the BIP editors or the Bitcoin -development mailing list. diff --git a/selected BIPs/bip-0001.mediawiki b/selected BIPs/bip-0001.mediawiki deleted file mode 100644 index c9857a85..00000000 --- a/selected BIPs/bip-0001.mediawiki +++ /dev/null @@ -1,175 +0,0 @@ -
-  BIP: 1
-  Title: BIP Purpose and Guidelines
-  Status: Accepted
-  Type: Standards Track
-  Created: 2011-08-19
-
- -==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 validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. -* An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice. -* A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP. - -==BIP Work Flow== - -The BIP editors assign BIP numbers and change their status. Please send all BIP-related email to the BIP editor, which is listed under [[#BIP_Editors|BIP Editors]] below. Also see [[#BIP_Editor_Responsibilities__Workflow|BIP Editor Responsibilities & Workflow]]. - -The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones. - -Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this. - -Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used. - -Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. - -Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed. - -If the BIP editor approves, he will assign the BIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy. - -The BIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests. - -Standards Track BIPs consist of two parts, a design document and a reference implementation. The BIP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the BIP. Standards Track BIPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final. - -BIP authors are responsible for collecting community feedback on a BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here. - -For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. - -Once a BIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final". - -A BIP can also be assigned status "Deferred". The BIP author or editor can assign the BIP this status when no progress is being made on the BIP. Once a BIP is deferred, the BIP editor can re-assign it to draft status. - -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: - - - -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. - -* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Bitcoin platforms (Satoshi, BitcoinJ, bitcoin-js, libbitcoin). - -* Motivation -- The motivation is critical for BIPs that want to change the Bitcoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the BIP solves. BIP submissions without sufficient motivation may be rejected outright. - -* 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 or markdown format. Image files should be included in a 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 yyyy-mm-dd format, e.g. 2001-08-14. - -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 Editors== - -The current BIP editor is Gregory Maxwell who can be contacted at [[mailto:gmaxwell@gmail.com|gmaxwell@gmail.com]]. - -==BIP Editor Responsibilities & Workflow== - -A BIP editor must subscribe to the Bitcoin development mailing list. All BIP-related correspondence should be sent (or CC'd) to gmaxwell@gmail.com. - -For each new BIP that comes in an editor does the following: - -* 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). - -* Add the BIP to the [https://github.com/bitcoin/bips bitcoin/bips] repository on GitHub. - -* List the BIP in [[README.mediawiki]] - -* 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 BIP editors or the Bitcoin development mailing list. diff --git a/selected BIPs/bip-0011.asciidoc b/selected BIPs/bip-0011.asciidoc deleted file mode 100644 index 1fe68ff5..00000000 --- a/selected BIPs/bip-0011.asciidoc +++ /dev/null @@ -1,116 +0,0 @@ --------------------------------------------------- - BIP: 11 - Title: M-of-N Standard Transactions - Author: Gavin Andresen - Status: Accepted - Type: Standards Track - Created: 2011-10-18 - Post-History: 2011-10-02 --------------------------------------------------- - -[[abstract]] -Abstract -~~~~~~~~ - -This BIP proposes M-of-N-signatures required transactions as a new -'standard' transaction type. - -[[motivation]] -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]] -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]] -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]] -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]] -Post History -~~~~~~~~~~~~ - -* https://bitcointalk.org/index.php?topic=46538[OP_EVAL proposal] - diff --git a/selected BIPs/bip-0011.mediawiki b/selected BIPs/bip-0011.mediawiki deleted file mode 100644 index 2499ac03..00000000 --- a/selected BIPs/bip-0011.mediawiki +++ /dev/null @@ -1,58 +0,0 @@ -
-  BIP: 11
-  Title: M-of-N Standard Transactions
-  Author: Gavin Andresen 
-  Status: Accepted
-  Type: Standards Track
-  Created: 2011-10-18
-  Post-History: 2011-10-02
-
- -==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/selected BIPs/bip-0013.asciidoc b/selected BIPs/bip-0013.asciidoc deleted file mode 100644 index ed1dcf08..00000000 --- a/selected BIPs/bip-0013.asciidoc +++ /dev/null @@ -1,104 +0,0 @@ --------------------------------------------------- - BIP: 13 - Title: Address Format for pay-to-script-hash - Author: Gavin Andresen - Status: Final - Type: Standards Track - Created: 2011-10-18 --------------------------------------------------- - -[[abstract]] -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]] -Motivation -~~~~~~~~~~ - -Enable "end-to-end" secure wallets and payments to fund escrow -transactions or other complex transactions. Enable third-party wallet -security services. - -[[specification]] -Specification -~~~~~~~~~~~~~ - -The new bitcoin address type is constructed in the same manner as -existing bitcoin addresses (see link:Base58Check encoding[Base58Check -encoding]): - -`   base58-encode: [one-byte version][20-byte hash][4-byte checksum]` - -Version byte is 5 for a main-network address, 196 for a testnet address. -The 20-byte hash is the hash of the script that will be used to redeem -the coins. And the 4-byte checksum is the first four bytes of the double -SHA256 hash of the version and hash. - -[[rationale]] -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. - -The leading version bytes are chosen so that, after base58 encoding, the -leading character is consistent: for the main network, byte 5 becomes -the character '3'. For the testnet, byte 196 is encoded into '2'. - -[[backwards-compatibility]] -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]] -Reference Implementation -~~~~~~~~~~~~~~~~~~~~~~~~ - -See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src - -[[see-also]] -See Also -~~~~~~~~ - -* link:bip-0012.mediawiki[BIP 12: OP_EVAL, the original P2SH design] -* link:bip-0016.mediawiki[BIP 16: Pay to Script Hash (aka "/P2SH/")] -* link:bip-0017.mediawiki[BIP 17: OP_CHECKHASHVERIFY, another P2SH -design] - diff --git a/selected BIPs/bip-0013.mediawiki b/selected BIPs/bip-0013.mediawiki deleted file mode 100644 index a537d16a..00000000 --- a/selected BIPs/bip-0013.mediawiki +++ /dev/null @@ -1,56 +0,0 @@ -
-  BIP: 13
-  Title: Address Format for pay-to-script-hash
-  Author: Gavin Andresen 
-  Status: Final
-  Type: Standards Track
-  Created: 2011-10-18
-
- -==Abstract== - -This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. - -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 5 for a main-network address, 196 for a testnet address. -The 20-byte hash is the hash of the script that will be used to redeem the coins. -And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. - -==Rationale== - -One criticism is that bitcoin addresses should be deprecated in favor of a more user-friendly mechanism for payments, and that this will just encourage continued use of a poorly designed mechanism. - -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. - -The leading version bytes are chosen so that, after base58 encoding, the leading character is consistent: for the main network, byte 5 becomes the character '3'. For the testnet, byte 196 is encoded into '2'. - -==Backwards Compatibility== - -This proposal is not backwards compatible, but it fails gracefully-- if an older implementation is given one of these new bitcoin addresses, it will report the address as invalid and will refuse to create a transaction. - -==Reference Implementation== - -See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src - -==See Also== - -* [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]] -* [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] -* [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]] diff --git a/selected BIPs/bip-0014.asciidoc b/selected BIPs/bip-0014.asciidoc deleted file mode 100644 index 0d96f7f6..00000000 --- a/selected BIPs/bip-0014.asciidoc +++ /dev/null @@ -1,173 +0,0 @@ ------------------------------------------------------------- - BIP: 14 - Title: BIP Protocol Version and User Agent - Author: Amir Taaki - Patrick Strateman - Status: Accepted - Type: Standards Track - Created: 2011-11-10 - Post-History: 2011-11-02 ------------------------------------------------------------- - -In this document, bitcoin will be used to refer to the protocol while -Satoshi will refer to the current client in order to prevent confusion. - -[[past-situation]] -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]] -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]] -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]] -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 precedes another. For this reason, -we lightly recommend dates in the format specified above, although this -is by no means a requirement. - -Optional -r1, -r2, ... can be appended to user agent version numbers. -This is another light recommendation, but not a requirement. -Implementations are free to specify version numbers in whatever format -needed insofar as it does not include (, ), : or / to interfere with the -user agent syntax. - -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. - -* / separates the code-stack -* :: - specifies the implementation version of the particular stack -* ( and ) delimits a comment which optionally separates data using ; - -[[timeline]] -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/selected BIPs/bip-0014.mediawiki b/selected BIPs/bip-0014.mediawiki deleted file mode 100644 index 111eb78b..00000000 --- a/selected BIPs/bip-0014.mediawiki +++ /dev/null @@ -1,89 +0,0 @@ -
-  BIP: 14
-  Title: BIP Protocol Version and User Agent
-  Author: Amir Taaki 
-          Patrick Strateman 
-  Status: Accepted
-  Type: Standards Track
-  Created: 2011-11-10
-  Post-History: 2011-11-02
-
- -In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. - -== 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 precedes another. For this reason, we lightly recommend dates in the format specified above, although this is by no means a requirement. - -Optional -r1, -r2, ... can be appended to user agent version numbers. This is another light recommendation, but not a requirement. Implementations are free to specify version numbers in whatever format needed insofar as it does not include (, ), : or / to interfere with the user agent syntax. - -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. - -* / separates the code-stack -* : specifies the implementation version of the particular stack -* ( and ) delimits a comment which optionally separates data using ; - -== Timeline == - -When this document was published, the bitcoin protocol and Satoshi client versions were currently at 0.5 and undergoing changes. In order to minimise disruption and allow the undergoing changes to be completed, the next protocol version at 0.6 became peeled from the client version (also at 0.6). As of that time (January 2012), protocol and implementation version numbers are distinct from each other. diff --git a/selected BIPs/bip-0016.asciidoc b/selected BIPs/bip-0016.asciidoc deleted file mode 100644 index 78721be3..00000000 --- a/selected BIPs/bip-0016.asciidoc +++ /dev/null @@ -1,223 +0,0 @@ --------------------------------------------------- - BIP: 16 - Title: Pay to Script Hash - Author: Gavin Andresen - Status: Final - Type: Standards Track - Created: 2012-01-03 --------------------------------------------------- - -[[abstract]] -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]] -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]] -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_ - also referred to as the -_redeemScript_ - is, itself, one of the other standard transaction -types. - -The rules for validating these outpoints when relaying transactions or -considering them for inclusion in a new block are as follows: - -1. Validation fails if there are any operations other than "push data" -operations in the scriptSig. -2. 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. -3. \{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 new rules should only be applied when validating transactions in -blocks with timestamps >= 1333238400 (Apr 1 2012) -footnote:[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff[Remove --bip16 and -paytoscripthashtime command-line arguments]]. There are -transaction earlier than 13333238400 in the block chain that fail these -new validation rules. -footnote:[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192[Transaction -6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]]. -Older transactions must be validated under the old rules. (see the -Backwards Compatibility section for details). - -For example, the scriptPubKey and corresponding scriptSig for a -one-signature-required transaction is: - -`   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: - -1. OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, -whether or not they are evaluated. -2. 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. -3. 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]] -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: - -1. 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. -2. Attacker also creates a standard transaction that spends the -pay-to-script transaction, and pays the victim who is running old -software. -3. 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]] -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). - -[[byte-limitation-on-serialized-script-size]] -520-byte limitation on serialized script size -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As a consequence of the requirement for backwards compatiblity the -serialized script is itself subject to the same rules as any other -PUSHDATA operation, including the rule that no data greater than 520 -bytes may be pushed to the stack. Thus is it not possible to spend a -P2SH output if the redemption script it refers to is >520 bytes in -length. For instance while the OP_CHECKMULTISIG opcode can itself accept -up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to -spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes -+ 15 pubkeys * 34 bytes/pubkey = 513 bytes. - -[[reference-implementation]] -Reference Implementation -~~~~~~~~~~~~~~~~~~~~~~~~ - -https://gist.github.com/gavinandresen/3966071 - -[[see-also]] -See Also -~~~~~~~~ - -* https://bitcointalk.org/index.php?topic=46538 -* The link:bip-0013.mediawiki[Address format for Pay to Script Hash BIP] -* M-of-N Multisignature Transactions link:bip-0011.mediawiki[BIP 11] -* link:bip-0016/qa.mediawiki[Quality Assurance test checklist] - -[[references]] -References -~~~~~~~~~~ diff --git a/selected BIPs/bip-0016.mediawiki b/selected BIPs/bip-0016.mediawiki deleted file mode 100644 index 0a539fc2..00000000 --- a/selected BIPs/bip-0016.mediawiki +++ /dev/null @@ -1,116 +0,0 @@ -
-  BIP: 16
-  Title: Pay to Script Hash
-  Author: Gavin Andresen 
-  Status: Final
-  Type: Standards Track
-  Created: 2012-01-03
-
- -==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'' - also referred to as the ''redeemScript'' - is, itself, one of the other standard transaction types. - -The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows: - -# 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 new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) [https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]. There are transaction earlier than 13333238400 in the block chain that fail these new validation rules. [http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). - -For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: - - 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). - -===520-byte limitation on serialized script size=== - -As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus is it not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. - - -==Reference Implementation== - -https://gist.github.com/gavinandresen/3966071 - -==See Also== - -* https://bitcointalk.org/index.php?topic=46538 -* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] -* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]] -* [[bip-0016/qa.mediawiki|Quality Assurance test checklist]] - -== References == - diff --git a/selected BIPs/bip-0021.asciidoc b/selected BIPs/bip-0021.asciidoc deleted file mode 100644 index 5f9a25f7..00000000 --- a/selected BIPs/bip-0021.asciidoc +++ /dev/null @@ -1,223 +0,0 @@ ---------------------------------------------------- - BIP: 21 - Title: URI Scheme - Author: Nils Schneider - Matt Corallo - Status: Accepted - Type: Standards Track - Created: 2012-01-29 ---------------------------------------------------- - -This BIP is a modification of an earlier link:bip-0020.mediawiki[BIP -0020] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils -Schneider. The alternative payment amounts in BIP 0020 have been -removed. - -[[abstract]] -Abstract -~~~~~~~~ - -This BIP proposes a URI scheme for making Bitcoin payments. - -[[motivation]] -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]] -Specification -~~~~~~~~~~~~~ - -[[general-rules-for-handling-important]] -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]] -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. - -[[general-format]] -General Format -^^^^^^^^^^^^^^ - -Bitcoin URIs follow the general format for URIs as set forth in RFC -3986. The path component consists of a bitcoin address, and the query -component provides additional payment options. - -Elements of the query component may contain characters outside the valid -range. These must first be encoded according to UTF-8, and then each -octet of the corresponding UTF-8 sequence must be percent-encoded as -described in RFC 3986. - -[[abnf-grammar]] -ABNF grammar -^^^^^^^^^^^^ - -(See also link:#Simpler_syntax[a simpler representation of syntax]) - -`bitcoinurn     = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]` + -`bitcoinaddress = *base58` + -`bitcoinparams  = bitcoinparam [ "&" bitcoinparams ]` + -`bitcoinparam   = [ amountparam / labelparam / messageparam / otherparam / reqparam ]` + -`amountparam    = "amount=" *digit [ "." *digit ]` + -`labelparam     = "label=" *qchar` + -`messageparam   = "message=" *qchar` + -`otherparam     = qchar *qchar [ "=" *qchar ]` + -`reqparam       = "req-" qchar *qchar [ "=" *qchar ]` - -Here, "qchar" corresponds to valid characters of an RFC 3986 URI query -component, excluding the "=" and "&" characters, which this BIP takes as -separators. - -The scheme component ("bitcoin:") is case-insensitive, and -implementations must accept any combination of uppercase and lowercase -letters. The rest of the URI is case-sensitive, including the query -parameter keys. - -[[query-keys]] -Query Keys -^^^^^^^^^^ - -* label: Label for that address (e.g. name of receiver) -* address: bitcoin address -* message: message that describes the transaction to the user -(link:#Examples[see examples below]) -* size: amount of base bitcoin units (link:#Transfer_amount/size[see -below]) -* (others): optional, for future extensions - -[[transfer-amountsize]] -Transfer amount/size -++++++++++++++++++++ - -If an amount is provided, it MUST be specified in decimal BTC. All -amounts MUST contain no commas and use a period (.) as the separating -character to separate whole numbers and decimal fractions. I.e. -amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is -invalid. - -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]] -Rationale -~~~~~~~~~ - -[[payment-identifiers-not-person-identifiers]] -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]] -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]] -Forward compatibility -~~~~~~~~~~~~~~~~~~~~~ - -Variables which are prefixed with a req- are considered required. If a -client does not implement any variables which are prefixed with req-, it -MUST consider the entire URI invalid. Any other variables which are not -implemented, but which are not prefixed with a req-, can be safely -ignored. - -[[backward-compatibility]] -Backward compatibility -~~~~~~~~~~~~~~~~~~~~~~ - -As this BIP is written, several clients already implement a bitcoin: URI -scheme similar to this one, however usually without the additional -"req-" prefix requirement. Thus, it is recommended that additional -variables prefixed with req- not be used in a mission-critical way until -a grace period of 6 months from the finalization of this BIP has passed -in order to allow client developers to release new versions, and users -of old clients to upgrade. - -[[appendix]] -Appendix -~~~~~~~~ - -[[simpler-syntax]] -Simpler syntax -^^^^^^^^^^^^^^ - -This section is non-normative and does not cover all possible syntax. -Please see the BNF grammar above for the normative syntax. - -[foo] means optional, are placeholders - -`bitcoin:
[?amount=][?label=