├── bip-0073 ├── a.png └── b.png ├── bip-0001 └── process.png ├── bip-0032 └── derivation.png ├── bip-0042 └── inflation.png ├── bip-0070 ├── Protocol_Sequence.png ├── extensions.mediawiki └── paymentrequest.proto ├── bip-0047 ├── reusable_payment_codes-01.png ├── reusable_payment_codes-02.png ├── reusable_payment_codes-03.png ├── reusable_payment_codes-04.png ├── reusable_payment_codes-05.png └── reusable_payment_codes-06.png ├── bip-0071.mediawiki ├── bip-0035.mediawiki ├── bip-0034.mediawiki ├── bip-0043.mediawiki ├── bip-0072.mediawiki ├── bip-0031.mediawiki ├── bip-0111.mediawiki ├── bip-0013.mediawiki ├── bip-0039 └── bip-0039-wordlists.md ├── bip-0019.mediawiki ├── bip-0030.mediawiki ├── bip-0105.mediawiki ├── bip-0073.mediawiki ├── bip-0011.mediawiki ├── bip-0042.mediawiki ├── bip-0060.mediawiki ├── bip-0061.mediawiki ├── bip-0064.mediawiki ├── bip-0106.mediawiki ├── bip-0113.mediawiki ├── bip-0012.mediawiki ├── bip-0039.mediawiki ├── bip-0050.mediawiki ├── bip-0121.mediawiki ├── bip-0014.mediawiki ├── bip-0033.mediawiki ├── bip-0017.mediawiki ├── bip-0021.mediawiki ├── bip-0066.mediawiki ├── bip-0044.mediawiki ├── README.mediawiki ├── bip-0067.mediawiki ├── bip-0016.mediawiki ├── bip-0018.mediawiki ├── bip-0010.mediawiki ├── bip-0016 └── qa.mediawiki ├── bip-0020.mediawiki └── bip-0120.mediawiki /bip-0073/a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0073/a.png -------------------------------------------------------------------------------- /bip-0073/b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0073/b.png -------------------------------------------------------------------------------- /bip-0001/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0001/process.png -------------------------------------------------------------------------------- /bip-0032/derivation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0032/derivation.png -------------------------------------------------------------------------------- /bip-0042/inflation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0042/inflation.png -------------------------------------------------------------------------------- /bip-0070/Protocol_Sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0070/Protocol_Sequence.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-01.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-02.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-03.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-04.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-05.png -------------------------------------------------------------------------------- /bip-0047/reusable_payment_codes-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/petertodd/bips/HEAD/bip-0047/reusable_payment_codes-06.png -------------------------------------------------------------------------------- /bip-0070/extensions.mediawiki: -------------------------------------------------------------------------------- 1 | ==BIP70 Extensions== 2 | 3 | Add your extension below using tags starting at 1000 and submit a pull-req. 4 | 5 | {| 6 | | Field Number || Extension Name || Field Name || Description 7 | |- 8 | | 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned) 9 | |} 10 | -------------------------------------------------------------------------------- /bip-0071.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 71
 3 |   Title: Payment Protocol MIME types
 4 |   Author: Gavin Andresen 
 5 |   Status: Final
 6 |   Type: Standards Track
 7 |   Created: 2013-07-29
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment 13 | request messages. 14 | 15 | ==Motivation== 16 | 17 | Wallet or server software that sends payment protocol messages over 18 | email or http should follow Internet standards for properly 19 | encapsulating the messages. 20 | 21 | ==Specification== 22 | 23 | The Media Type (Content-Type in HTML/email headers) for bitcoin 24 | protocol messages shall be: 25 | 26 | {| 27 | | Message || Type/Subtype 28 | |- 29 | | PaymentRequest || application/bitcoin-paymentrequest 30 | |- 31 | | Payment || application/bitcoin-payment 32 | |- 33 | | PaymentACK || application/bitcoin-paymentack 34 | |} 35 | 36 | Payment protocol messages are encoded in binary. 37 | 38 | ==Example== 39 | 40 | A web server generating a PaymentRequest message to initiate the 41 | payment protocol would precede the binary message data with the 42 | following headers: 43 | 
44 | Content-Type: application/bitcoin-paymentrequest
45 | Content-Transfer-Encoding: binary
46 |
47 | -------------------------------------------------------------------------------- /bip-0035.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 35
 3 |   Title: mempool message
 4 |   Author: Jeff Garzik 
 5 |   Status: Accepted
 6 |   Type: Standards Track
 7 |   Created: 2012-08-16
 8 |
9 | 10 | ==Abstract== 11 | 12 | Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. 13 | 14 | ==Motivation== 15 | 16 | Several use cases make it desireable to expose a network node's transaction memory pool: 17 | # SPV clients, wishing to obtain zero-confirmation transactions sent or received. 18 | # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. 19 | # Remote network diagnostics. 20 | 21 | ==Specification== 22 | 23 | # The mempool message is defined as an empty message where pchCommand == "mempool" 24 | # Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any. 25 | # The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool. 26 | # Feature discovery is enabled by checking two "version" message attributes: 27 | ## Protocol version >= 60002 28 | ## NODE_NETWORK bit set in nServices 29 | 30 | Note that existing implementations drop "inv" messages with a vector size > 50000. 31 | 32 | ==Backward compatibility== 33 | 34 | Older clients remain 100% compatible and interoperable after this change. 35 | 36 | ==Implementation== 37 | 38 | https://github.com/bitcoin/bitcoin/pull/1641 39 | -------------------------------------------------------------------------------- /bip-0034.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 34
 3 |   Title: Block v2, Height in Coinbase
 4 |   Author: Gavin Andresen 
 5 |   Status: Accepted
 6 |   Type: Standards Track
 7 |   Created: 2012-07-06
 8 |
9 | 10 | ==Abstract== 11 | 12 | Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2. 13 | 14 | ==Motivation== 15 | 16 | # Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors. 17 | # Enforce block and transaction uniqueness, and assist unconnected block validation. 18 | 19 | ==Specification== 20 | 21 | # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). 22 | # Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 300 or so years), following bytes are little-endian representation of the number. Height is the height of the mined block in the block chain, where the genesis block is height zero (0). 23 | # 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100) 24 | # 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100) 25 | 26 | ==Backward compatibility== 27 | 28 | All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade. 29 | 30 | ==Implementation== 31 | 32 | https://github.com/bitcoin/bitcoin/pull/1526 33 | 34 | ==Result== 35 | 36 | Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block. 37 | -------------------------------------------------------------------------------- /bip-0070/paymentrequest.proto: -------------------------------------------------------------------------------- 1 | // 2 | // Simple Bitcoin Payment Protocol messages 3 | // 4 | // Use fields 1000+ for extensions; 5 | // to avoid conflicts, register extensions via pull-req at 6 | // https://github.com/bitcoin/bips/bip-0070/extensions.mediawiki 7 | // 8 | 9 | package payments; 10 | option java_package = "org.bitcoin.protocols.payments"; 11 | option java_outer_classname = "Protos"; 12 | 13 | // Generalized form of "send payment to this/these bitcoin addresses" 14 | message Output { 15 | optional uint64 amount = 1 [default = 0]; // amount is integer-number-of-satoshis 16 | required bytes script = 2; // usually one of the standard Script forms 17 | } 18 | message PaymentDetails { 19 | optional string network = 1 [default = "main"]; // "main" or "test" 20 | repeated Output outputs = 2; // Where payment should be sent 21 | required uint64 time = 3; // Timestamp; when payment request created 22 | optional uint64 expires = 4; // Timestamp; when this request should be considered invalid 23 | optional string memo = 5; // Human-readable description of request for the customer 24 | optional string payment_url = 6; // URL to send Payment and get PaymentACK 25 | optional bytes merchant_data = 7; // Arbitrary data to include in the Payment message 26 | } 27 | message PaymentRequest { 28 | optional uint32 payment_details_version = 1 [default = 1]; 29 | optional string pki_type = 2 [default = "none"]; // none / x509+sha256 / x509+sha1 30 | optional bytes pki_data = 3; // depends on pki_type 31 | required bytes serialized_payment_details = 4; // PaymentDetails 32 | optional bytes signature = 5; // pki-dependent signature 33 | } 34 | message X509Certificates { 35 | repeated bytes certificate = 1; // DER-encoded X.509 certificate chain 36 | } 37 | message Payment { 38 | optional bytes merchant_data = 1; // From PaymentDetails.merchant_data 39 | repeated bytes transactions = 2; // Signed transactions that satisfy PaymentDetails.outputs 40 | repeated Output refund_to = 3; // Where to send refunds, if a refund is necessary 41 | optional string memo = 4; // Human-readable message for the merchant 42 | } 43 | message PaymentACK { 44 | required Payment payment = 1; // Payment message that triggered this ACK 45 | optional string memo = 2; // human-readable message for customer 46 | } 47 | -------------------------------------------------------------------------------- /bip-0043.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP:     BIP-0043
 3 |   Title:   Purpose Field for Deterministic Wallets
 4 |   Authors: Marek Palatinus 
 5 |            Pavol Rusnak 
 6 |   Status:  Draft
 7 |   Type:    Standards Track
 8 |   Created: 2014-04-24
 9 |
10 | 11 | ==Abstract== 12 | 13 | This BIP introduces a "Purpose Field" for use in deterministic wallets 14 | based on algorithm described in BIP-0032 (BIP32 from now on). 15 | 16 | ==Motivation== 17 | 18 | Although Hierarchical Deterministic Wallet structure as described by BIP32 19 | is an important step in user experience and security of the cryptocoin wallets, 20 | the BIP32 specification offers implementors too many degrees of freedom. 21 | Multiple implementations may claim they are BIP32 compatible, but in fact 22 | they can produce wallets with different logical structures making them 23 | non-interoperable. This situation unfortunately renders "BIP32 compatible" 24 | statement rather useless. 25 | 26 | 27 | ==Purpose== 28 | 29 | We propose the first level of BIP32 tree structure to be used as "purpose". 30 | This purpose determines the further structure beneath this node. 31 | 32 | 
33 | m / purpose' / *
34 |
35 | 36 | Apostrophe indicates that BIP32 hardened derivation is used. 37 | 38 | We encourage different schemes to apply for assigning a separate BIP number 39 | and use the same number for purpose field, so addresses won't be generated 40 | from overlapping BIP32 spaces. 41 | 42 | Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose. 43 | 44 | Note that m / 0' / * is already taken by BIP32 (default account), which 45 | preceded this BIP. 46 | 47 | Not all wallets may want to support the full range of features and possibilities 48 | described in these BIPs. Instead of choosing arbitrary subset of defined features 49 | and calling themselves BIPxx compatible, we suggest that software which needs 50 | only a limited structure should describe such structure in another BIP and use 51 | different "purpose" value. 52 | 53 | 54 | ==Node serialization== 55 | 56 | Because this scheme can be used to generate nodes for more cryptocurrencies 57 | at once, or even something totally unrelated to cryptocurrencies, there's no 58 | point in using a special version magic described in section "Serialization 59 | format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4 60 | for private nodes (leading to prefixes "xpub" and "xprv" respectively). 61 | 62 | ==Reference== 63 | 64 | * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] 65 | -------------------------------------------------------------------------------- /bip-0072.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 72
 3 |   Title: bitcoin: uri extensions for Payment Protocol
 4 |   Author: Gavin Andresen 
 5 |   Status: Final
 6 |   Type: Standards Track
 7 |   Created: 2013-07-29
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to 13 | support the payment protocol (BIP 70). 14 | 15 | ==Motivation== 16 | 17 | Allow users to click on a link in a web page or email to initiate the 18 | payment protocol, while being backwards-compatible with existing 19 | bitcoin wallets. 20 | 21 | ==Specification== 22 | 23 | The bitcoin: URI scheme is extended with an additional, optional 24 | "r" parameter, whose value is a URL from which a PaymentRequest 25 | message should be fetched (characters not allowed within the scope 26 | of a query parameter must be percent-encoded as described in RFC 3986 27 | and bip-0021). 28 | 29 | If the "r" parameter is provided and backwards compatibility 30 | is not required, then the bitcoin address portion of the URI may be 31 | omitted (the URI will be of the form: bitcoin:?r=... ). 32 | 33 | When Bitcoin wallet software that supports this BIP receives a 34 | bitcoin: URI with a request parameter, it should ignore the bitcoin 35 | address/amount/label/message in the URI and instead fetch a 36 | PaymentRequest message and then follow the payment protocol, as 37 | described in BIP 70. 38 | 39 | Bitcoin wallets must support fetching PaymentRequests via http and 40 | https protocols; they may support other protocols. Wallets must 41 | include an "Accept" HTTP header in HTTP(s) requests (as defined 42 | in RFC 2616): 43 | 44 | 
Accept: application/bitcoin-paymentrequest
45 | 46 | If a PaymentRequest cannot be obtained (perhaps the server is 47 | unavailable), then the customer should be informed that the merchant's 48 | payment processing system is unavailable. In the case of an HTTP 49 | request, status codes which are neither success nor error (such as 50 | redirect) should be handled as outlined in RFC 2616. 51 | 52 | ==Compatibility== 53 | 54 | Wallet software that does not support this BIP will simply ignore the 55 | r parameter and will initiate a payment to bitcoin address. 56 | 57 | ==Examples== 58 | A backwards-compatible request: 59 | 
60 | bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
61 |
62 | Non-backwards-compatible equivalent: 63 | 
64 | bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
65 |
66 | 67 | ==References== 68 | 69 | [[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 70 | -------------------------------------------------------------------------------- /bip-0031.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 31
 3 |   Title: Pong message
 4 |   Author: Mike Hearn 
 5 |   Status: Accepted
 6 |   Type: Standards Track
 7 |   Created: 2012-04-11
 8 |
9 | 10 | ==Abstract== 11 | 12 | This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections. 13 | 14 | ==Motivation== 15 | 16 | Today there are a few network related problems that can degrade the Bitcoin user experience: 17 | 18 | 1) Some Bitcoin clients run on platforms that can go to sleep and essentially stop running at any time without warning. Notably, this is very common on both mobiles and laptops (shut the lid). When the system comes back, TCP connections that existed before the sleep still exist but may no longer function correctly, eg, because the IP address has changed, or because the remote peer went away or the connection was timed out by some other system. Currently it can often take a while to notice this has happened. 19 | 20 | 2) The reference Satoshi client is largely single threaded and when placed under heavy load (e.g., because it is downloading the block chain) becomes very slow to respond to network messages. There's no easy way to detect this has occurred, especially if you are just passively waiting for broadcasts from that peer. A way to detect overloaded remote peers and avoid them would both help balance load and provide a better, more responsive system. 21 | 22 | 3) When downloading large data structures like the block chain it is efficient to choose a peer that is near to you network-wise, in order to reduce load on often congested trans-national links and ensure lower latency. Currently it is difficult to measure the latency to a remote peer so clients don't bother, and instead just select a random peer to download from. 23 | 24 | All of these can be solved by a backwards compatible protocol modification. 25 | 26 | ==Specification== 27 | 28 | When the protocol version as negotiated in the "ver" message is greater than 60000, the "ping" message must contain a uint64 field called "nonce". A peer sending "ping" should set the nonce to a random value, and it is then echoed back by the recipient in a new "pong" message that also contains a single uint64 field. 29 | 30 | In this way, the client can send a ping and measure the time taken to receive the corresponding pong. If a client sends two pings before hearing back the first pong, the responses can be distinguished using the nonce. If the client chooses to never overlap pings in this way it should simply set the nonce value to zero. 31 | 32 | ==Backward compatibility== 33 | 34 | Clients must opt-in to the new feature by advertising a protocol version > 60000. Clients with older protocol versions are not expected to provide a nonce in the ping message and will not be sent a pong. 35 | 36 | ==Implementation== 37 | 38 | https://github.com/bitcoin/bitcoin/pull/932/files 39 | -------------------------------------------------------------------------------- /bip-0111.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 111
 3 |   Title: NODE_BLOOM service bit
 4 |   Author: Matt Corallo , Peter Todd 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2015-08-20
 8 |
9 | 10 | == Abstract == 11 | 12 | This BIP extends BIP 37, Connection Bloom filtering, by defining a 13 | service bit to allow peers to advertise that they support bloom filters 14 | explicitly. It also bumps the protocol version to allow peers to 15 | identify old nodes which allow bloom filtering of the connection despite 16 | lacking the new service bit. 17 | 18 | 19 | == Motivation == 20 | 21 | BIP 37 did not specify a service bit for the bloom filter service, thus 22 | implicitly assuming that all nodes that serve peers data support it. 23 | However, the connection filtering algorithm proposed in BIP 37, and 24 | implemented in several clients today, has been shown to provide little 25 | to no privacyhttp://eprint.iacr.org/2014/763, as well as being a large DoS risk on some nodes[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.. 26 | Thus, allowing node operators to disable connection bloom filtering is a 27 | much-needed feature. 28 | 29 | 30 | == Specification == 31 | 32 | The following protocol bit is added: 33 | 34 | 
35 |     NODE_BLOOM = (1 << 2)
36 |
37 | 38 | Nodes which support bloom filters should set that protocol bit. 39 | Otherwise it should remain unset. In addition the protocol version is 40 | increased from 70002 to 70011 in the reference implementation. It is 41 | often the case that nodes which have a protocol version smaller than 42 | 70011, but larger than 70000 support bloom filtered connections without 43 | the NODE_BLOOM bit set, however clients which require bloom filtered 44 | connections should avoid making this assumption. 45 | 46 | NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise 47 | NODE_BLOOM but not NODE_NETWORK (though there is little reason to do 48 | so now, some proposals may make this more useful in the future) 49 | 50 | If a node does not support bloom filters but receives a "filterload", 51 | "filteradd", or "filterclear" message from a peer the node should 52 | disconnect that peer immediately. For backwards compatibility, in 53 | initial implementations, nodes may choose to only disconnect nodes which 54 | have the new protocol version set and attempt to send a filter command. 55 | 56 | While outside the scope of this BIP it is suggested that DNS seeds and 57 | other peer discovery mechanisms support the ability to specify the 58 | services required; current implementations simply check only that 59 | NODE_NETWORK is set. 60 | 61 | 62 | == Design rational == 63 | 64 | A service bit was chosen as applying a bloom filter is a service. 65 | 66 | The increase in protocol version is for backwards compatibility. In 67 | initial implementations, old nodes which are not yet aware of NODE_BLOOM 68 | and use a protocol version < 70011 may still send filter messages to a 69 | node without NODE_BLOOM. This feature may be removed after there are 70 | sufficient NODE_BLOOM nodes available and SPV clients have upgraded, 71 | allowing node operators to fully close the bloom-related DoS vectors. 72 | 73 | 74 | == Reference Implementation == 75 | 76 | https://github.com/bitcoin/bitcoin/pull/6579 77 | 78 | 79 | == Copyright == 80 | 81 | This document is placed in the public domain. 82 | 83 | 84 | == References == 85 | 86 | -------------------------------------------------------------------------------- /bip-0013.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 13
 3 |   Title: Address Format for pay-to-script-hash
 4 |   Author: Gavin Andresen 
 5 |   Status: Final
 6 |   Type: Standards Track
 7 |   Created: 2011-10-18
 8 |
9 | 10 | ==Abstract== 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | ==Motivation== 17 | 18 | Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. 19 | 20 | ==Specification== 21 | 22 | The new bitcoin address type is constructed in the same manner as existing bitcoin addresses (see [[Base58Check encoding]]): 23 | 24 | base58-encode: [one-byte version][20-byte hash][4-byte checksum] 25 | 26 | Version byte is 5 for a main-network address, 196 for a testnet address. 27 | The 20-byte hash is the hash of the script that will be used to redeem the coins. 28 | And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. 29 | 30 | ==Rationale== 31 | 32 | 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. 33 | 34 | 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? 35 | 36 | 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. 37 | 38 | 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. 39 | 40 | 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. 41 | 42 | 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'. 43 | 44 | ==Backwards Compatibility== 45 | 46 | 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. 47 | 48 | ==Reference Implementation== 49 | 50 | See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src 51 | 52 | ==See Also== 53 | 54 | * [[bip-0012.mediawiki|BIP 12: OP_EVAL, the original P2SH design]] 55 | * [[bip-0016.mediawiki|BIP 16: Pay to Script Hash (aka "/P2SH/")]] 56 | * [[bip-0017.mediawiki|BIP 17: OP_CHECKHASHVERIFY, another P2SH design]] 57 | -------------------------------------------------------------------------------- /bip-0039/bip-0039-wordlists.md: -------------------------------------------------------------------------------- 1 | #Wordlists 2 | 3 | * [English](english.txt) 4 | * [Japanese](japanese.txt) 5 | * [Spanish](spanish.txt) 6 | * [Chinese (Simplified)](chinese_simplified.txt) 7 | * [Chinese (Traditional)](chinese_traditional.txt) 8 | * [French](french.txt) 9 | 10 | ##Wordlists (Special Considerations) 11 | 12 | ###Japanese 13 | 14 | 1. **Developers implementing phrase generation or checksum verification must separate words using ideographic spaces / accommodate users inputting ideographic spaces.** 15 | (UTF-8 bytes: **0xE38080**; C/C+/Java: **"\u3000"**; Python: **u"\u3000"**) 16 | However, code that only accepts Japanese phrases but does not generate or verify them should be fine as is. 17 | This is because when generating the seed, normalization as per the spec will 18 | automatically change the ideographic spaces into normal ASCII spaces, so as long as your code never shows the user an ASCII space 19 | separated phrase or tries to split the phrase input by the user, dealing with ASCII or Ideographic space is the same. 20 | 21 | 2. Word-wrapping doesn't work well, so making sure that words only word-wrap at one of the 22 | ideographic spaces may be a necessary step. As a long word split in two could be mistaken easily 23 | for two smaller words (This would be a problem with any of the 3 character sets in Japanese) 24 | 25 | ###Spanish 26 | 27 | 1. Words can be uniquely determined typing the first 4 characters (sometimes less). 28 | 29 | 2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents. 30 | 31 | 3. There are no words in common between the Spanish wordlist and any other language wordlist, therefore it is possible to detect the language with just one word. 32 | 33 | ###Chinese 34 | 35 | 1. Chinese text typically does not use any spaces as word separators. For the sake of 36 | uniformity, we propose to use normal ASCII spaces (0x20) to separate words as per standard. 37 | 38 | ###French 39 | 40 | Credits: @Kirvx @NicolasDorier @ecdsa @EricLarch 41 | ([The pull request](https://github.com/bitcoin/bips/issues/152)) 42 | 43 | 1. High priority on simple and common french words. 44 | 2. Only words with 5-8 letters. 45 | 3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together). 46 | 4. Only infinitive verbs, adjectives and nouns. 47 | 5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette"). 48 | 6. No numeral adjectives. 49 | 7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux"). 50 | 8. No female adjectives (except words with same spelling for male and female adjectives like "magique"). 51 | 9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle". 52 | 10. No very similar words with 1 letter of difference. 53 | 11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir"). 54 | 12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ". 55 | 13. No words ending by "é;ée;è;et;ai;ait". 56 | 14. No demonyms. 57 | 15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z). 58 | 16. No embarrassing words (in a very, very large scope) or belonging to a particular religion. 59 | 17. No identical words with the Spanish wordlist (as Y75QMO wants). 60 | -------------------------------------------------------------------------------- /bip-0019.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 19
 3 |   Title: M-of-N Standard Transactions (Low SigOp)
 4 |   Author: Luke Dashjr 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2012-01-30
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. 13 | 14 | ==Motivation== 15 | 16 | Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. 17 | 18 | A couple of motivating use cases: 19 | 20 | * 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. 21 | 22 | * 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. 23 | 24 | ==Specification== 25 | 26 | Two new standard transaction types (scriptPubKey) that are relayed by clients and included in mined blocks. 27 | 28 | N-of-N (all signatures required): 29 | 30 | ( {pubkey} OP_CHECKSIGVERIFY )*n 31 | 32 | N-of-M (some signatures required): 33 | 34 | {pubkey} OP_CHECKSIG ( OP_SWAP {pubkey} OP_CHECKSIG OP_ADD )*(n-1) n OP_EQUAL 35 | 36 | But only for n less than or equal to 3. 37 | 38 | These transactions are redeemed using a standard scriptSig: 39 | ...signatures... 40 | 41 | 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. 42 | 43 | ===Templates=== 44 | scriptPubKey: 45 | 46 | {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY 47 | 48 | {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY {pubkey} OP_CHECKSIGVERIFY 49 | 50 | {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL 51 | 52 | {pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL 53 | 54 | scriptSig: 55 | 56 | ...signatures... up to 500 bytes 57 | 58 | ==Rationale== 59 | 60 | OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. 61 | This is already specified in [[bip-0011.mediawiki|BIP 0011]]. 62 | However, each OP_CHECKMULTISIG counts toward the block limit as 20 sigops, which only allows 1000 total multisig transactions in a block. 63 | Using OP_CHECKSIG only counts as 1 per signature, so can scale better. 64 | 65 | ==Implementation== 66 | 67 | All used operations are already supported by old clients and miners as a non-standard transaction type. 68 | -------------------------------------------------------------------------------- /bip-0030.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 30
 3 |   Title: Duplicate transactions
 4 |   Author: Pieter Wuille 
 5 |   Status: Final
 6 |   Type: Standards Track
 7 |   Created: 2012-02-22
 8 |
9 | 10 | ==Abstract== 11 | This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementations has with them. 12 | 13 | ==Motivation== 14 | So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network. 15 | 16 | ==Specification== 17 | To counter this problem, the following network rule is introduced: 18 | *Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain. 19 | 20 | This rule initially applied to all blocks whose timestamp is after March 15, 2012, 00:00 UTC (testnet: February 20, 2012 00:00 UTC). It was later extended by Commit [https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 Apply BIP30 checks to all blocks except the two historic violations.] to apply to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in. 21 | 22 | ==Rationale== 23 | Whatever solution is used, the following law must be obeyed to guarantee sane behaviour: the set of usable 24 | transactions outputs must not be modified by adding blocks to the chain and removing them again. This happens during 25 | a reorganisation, and the current Bitcoin reference implementation does not obey this law in case the temporarily 26 | added blocks contain a duplicate transaction. 27 | 28 | There are several potential solutions to this problem: 29 | #Guarantee that all coinbases are unique, making duplicate transactions very hard to create. 30 | #Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added. 31 | #Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from the chain can then safely reset the removed transaction's outputs to nothing. 32 | 33 | The first option is probably the most complete one, as it also guarantees transaction identifiers are unique. However, implementing it requires several changes that need to be accepted throughout the network. Furthermore, it does not prevent duplicate transactions based on earlier duplicate coinbases. The second option is impossible to implement in a forward-compatible way, as it potentially renders currently-invalid blocks valid. In this document we choose for the third option, because it only requires a trivial change. 34 | 35 | Fully-spent transactions are allowed to be duplicated in order not to hinder pruning at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made. 36 | 37 | ==Backward compatibility== 38 | The addition of this rule only makes some previously-valid blocks invalid. This implies that if the rule is implemented by a supermajority of miners, it is not possible to fork the block chain in a permanent way between nodes with and without the new rule. 39 | 40 | ==Implementation== 41 | A patch for the reference client can be found on https://github.com/sipa/bitcoin/tree/nooverwritetx 42 | 43 | This BIP was implemented in Commit [https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531 Do not allow overwriting unspent transactions (BIP 30)] 44 | There have been additional commits to refine the implementation of this BIP. 45 | 46 | ==Acknowledgements== 47 | Thanks to Russell O'Connor for finding and demonstrating this problem, and helping test the patch. 48 | -------------------------------------------------------------------------------- /bip-0105.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 105
  3 |   Title: Consensus based block size retargeting algorithm
  4 |   Author: BtcDrak 
  5 |   Status: Draft
  6 |   Type: Standards Track
  7 |   Created: 2015-08-21
  8 |
9 | 10 | ==Abstract== 11 | 12 | A method of altering the maximum allowed block size of the Bitcoin protocol 13 | using a consensus based approach. 14 | 15 | ==Motivation== 16 | 17 | There is a belief that Bitcoin cannot easily respond to raising the 18 | blocksize limit if popularity was to suddenly increase due to a mass adoption 19 | curve, because co-ordinating a hard fork takes considerable time, and being 20 | unable to respond in a timely manner would irreparably harm the credibility of 21 | bitcoin. 22 | 23 | Additionally, predetermined block size increases are problematic because they 24 | attempt to predict the future, and if too large could have unintended 25 | consequences like damaging the possibility for a fee market to develop 26 | as block subsidy decreases substantially over the next 9 years; introducing 27 | or exacerbating mining attack vectors; or somehow affect the network in unknown 28 | or unpredicted ways. Since fixed changes are hard to deploy, the damage could be 29 | extensive. 30 | 31 | Dynamic block size adjustments also suffer from the potential to be gamed by the 32 | larger hash power. 33 | 34 | Free voting as suggested by BIP100 allows miners to sell their votes out of band 35 | at no risk, and enable the sponsor the ability to manipulate the blocksize. 36 | It also provides a cost free method or the larger pools to vote in ways to 37 | manipulate the blocksize such to disadvantage or attack smaller pools. 38 | 39 | 40 | ==Rationale== 41 | 42 | By introducing a cost to increase the block size ensures the mining community 43 | will collude to increase it only when there is a clear necessity, and reduce it 44 | when it is unnecessary. Larger miners cannot force their wishes so easily 45 | because not only will they have to pay extra a difficulty target, then can be 46 | downvoted at no cost by the objecting hash power. 47 | 48 | Using difficulty as a penalty is better than a fixed cost in bitcoins because it 49 | is less predictable. 50 | 51 | In order to prevent miners having complete control over blocksize, an upper 52 | limit is required at protocol level. This feature ensures full nodes retain 53 | control over consensus, remembering full nodes are the mechanism to keep miners 54 | honest. 55 | 56 | 57 | ==Specification== 58 | 59 | The initial block size limit shall be 1MB. 60 | 61 | Each time a miner creates a block, they may vote to increase or decrease the 62 | blocksize by a maximum of 10% of the current block size limit. These votes will 63 | be used to recalculate the new block size limit every 2016 blocks. 64 | 65 | Votes are cast using the block's coinbase field. 66 | 67 | The first 4 bytes of the coinbase field shall be repurposed for voting as an 68 | unsigned long integer which will be the block size in bytes. 69 | 70 | If a miner votes for an increase, the block hash must meet a difficulty target 71 | which is proportionally larger than the standard difficulty target based on the 72 | percentage increase they voted for. 73 | 74 | Votes proposing decreasing the block size limit do not need to meet a higher 75 | difficulty target. 76 | 77 | Miners can vote for no change by voting for the current block size. 78 | 79 | For blocks to be valid the blockhash must meet the required difficulty target 80 | for the vote otherwise the block is invalid and will be rejected. 81 | 82 | Every 2016 blocks, the block size limit will be recalculated by the median of 83 | all votes in the last 2016 blocks. This will redefine the block size limit for 84 | the next 2016 blocks. 85 | 86 | Blocks that are larger than the calculated base block size limit are invalid and 87 | will be rejected. 88 | 89 | The base block size limit may not reduce below 1MB or increase above 8MB. 90 | 91 | 92 | ==Acknowledgements== 93 | 94 | This proposal is based on ideas and concepts derived from the writings of 95 | Meni Rosenfeld and Gregory Maxwell. 96 | 97 | 98 | ==Copyright== 99 | 100 | This work is placed in the public domain. 101 | -------------------------------------------------------------------------------- /bip-0073.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 73
 3 |   Title: Use "Accept" header for response type negotiation with Payment Request URLs
 4 |   Author: Stephen Pair 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2013-08-27
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]]) 13 | that addresses the need for short URLs when scanning from QR codes. It 14 | generalizes the specification for the behavior of a payment request URL in a 15 | way that allows the client and server to negotiate the content of the 16 | response using the HTTP Accept: header field. Specifically, the client 17 | can indicate to the server whether it prefers to receive a bitcoin URI or 18 | a payment request. 19 | 20 | Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support. 21 | 22 | ==Motivation== 23 | 24 | The payment protocol augments the bitcoin: uri scheme with an additional 25 | "payment" parameter that specifies a URL where a payment request can be 26 | downloaded. This creates long URIs that, when rendered as a QR code, have 27 | a high information density. Dense QR codes can be difficult to scan resulting 28 | in a more frustrating user experience. The goal is to create a standard that 29 | would allow QR scanning wallets to use less dense QR codes. It also makes 30 | general purpose QR code scanners more usable with bitcoin accepting 31 | websites. 32 | 33 | ==Specification== 34 | 35 | QR scanning wallets will consider a non bitcoin URI scanned from a QR code to 36 | be an end point where either a bitcoin URI or a payment request can be obtained. 37 | 38 | A wallet client uses the Accept: HTTP header to specify whether it can accept 39 | a payment request, a URI, or both. A media type of text/uri-list specifies that 40 | the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest 41 | specifies that the client can process a payment request. In the absence of an 42 | Accept: header, the server is expected to respond with text/html suitable for 43 | rendering in a browser. An HTML response will ensure that QR codes scanned 44 | by non Bitcoin wallet QR scanners are useful (they could render an HTML page 45 | with a payment link that when clicked would open a wallet on the device). 46 | 47 | It is not required that the client and server support the full semantics of an 48 | HTTP Accept header. If application/bitcoin-paymentrequest is specified in the 49 | header, the server should send a payment request regardless of anything else 50 | specified in the Accept header. If text/uri-list is specified (but not 51 | application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If 52 | neither is specified, the server can return an HTML page. When a uri-list is returned 53 | only the first item in the list is used (and expected to be a bitcoin URI), any additional 54 | URIs should be ignored. 55 | 56 | ==Compatibility== 57 | 58 | Only QR scanning wallets that implement this BIP will be able to process QR 59 | codes containing payment request URLs. There are two possible workarounds for QR 60 | scanning wallets that do not implement this BIP: 1) the server gives the user an 61 | option to change the QR code to a bitcoin: URI or 2) the user scans the code with 62 | a generic QR code scanner. 63 | 64 | In the second scenario, if the server responds with a webpage containing a link 65 | to a bitcoin URI, the user can complete the payment by clicking that link provided 66 | the user has a wallet installed on their device and it supports bitcoin URIs. If the 67 | wallet/device does not have support for bitcoin URIs, the user can fall back on 68 | address copy/paste. 69 | 70 | This BIP should be fully compatible with BIP 70 assuming it is required that wallets 71 | implementing BIP 70 make use of the Accept: HTTP header when retrieving a 72 | payment request. 73 | 74 | ==Examples== 75 | The first image below is of a bitcoin URI with an amount and payment request 76 | specified (note, this is a fairly minimal URI as it does not contain a 77 | label and the request URL is of moderate size). The second image is a QR 78 | code with only the payment request url specified. 79 | 80 | 81 | -------------------------------------------------------------------------------- /bip-0011.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 11
 3 |   Title: M-of-N Standard Transactions
 4 |   Author: Gavin Andresen 
 5 |   Status: Accepted
 6 |   Type: Standards Track
 7 |   Created: 2011-10-18
 8 |   Post-History: 2011-10-02
 9 |
10 | 11 | ==Abstract== 12 | 13 | This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. 14 | 15 | ==Motivation== 16 | 17 | Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. 18 | 19 | A couple of motivating use cases: 20 | 21 | * 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. 22 | 23 | * 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. 24 | 25 | ==Specification== 26 | 27 | A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks: 28 | 29 | m {pubkey}...{pubkey} n OP_CHECKMULTISIG 30 | 31 | But only for n less than or equal to 3. 32 | 33 | OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig: 34 | OP_0 ...signatures... 35 | 36 | (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). 37 | 38 | 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. 39 | 40 | ==Rationale== 41 | 42 | OP_CHECKMULTISIG is already an enabled opcode, and is the most straightforward way to support several important use cases. 43 | 44 | 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. 45 | 46 | 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. 47 | 48 | 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. 49 | 50 | ==Implementation== 51 | 52 | OP_CHECKMULTISIG is already supported by old clients and miners as a non-standard transaction type. 53 | 54 | https://github.com/gavinandresen/bitcoin-git/tree/op_eval 55 | 56 | == Post History == 57 | 58 | * [https://bitcointalk.org/index.php?topic=46538 OP_EVAL proposal] 59 | -------------------------------------------------------------------------------- /bip-0042.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 42
 3 |   Title: A finite monetary supply for Bitcoin
 4 |   Author: Pieter Wuille 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2014-04-01
 8 |
9 | 10 | ==Abstract== 11 | 12 | Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. 13 | 14 | This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. 15 | 16 | To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite. 17 | 18 | ==Details== 19 | 20 | As is well known, Satoshi was a master programmer whose knowledge of C++ was surpassed only by his knowledge of Japanese culture. The code below: 21 | 22 | int64_t nSubsidy = 50 * COIN; 23 | // Subsidy is cut in half every 210,000 blocks 24 | // which will occur approximately every 4 years. 25 | nSubsidy >>= (nHeight / 210000); 26 | 27 | is carefully written to rely on undefined behaviour in the C++ specification - perhaps so it can be hardware accelerated in future. 28 | 29 | The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units. Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings on all currently supported platforms. 30 | 31 | Despite the nice showoff of underhanded programming skills - we want Bitcoin to be well-specified. Otherwise, we're clearly in for a bumpy ride: 32 | 33 | 34 | 35 | Note that several other programming languages do not exhibit this behaviour, making new implementations likely to be slower and generally more bogus than Bitcoin Core. For example, Python unexpectedly returns 0 when shifting an integer beyond its size. 36 | 37 | ==Other solutions== 38 | 39 | ===Floating-point approximation=== 40 | 41 | An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. 42 | 43 | ===Truncation=== 44 | 45 | An alternative solution would be to represent the total number of bitcoins as a string: 46 | 47 | "21000000000000000000000" 48 | 49 | and then use string manipulation to remove the rightmost zero every 4 years, give or take a leap-year: 50 | 51 | strSubsidy = strSubsidy.substr(0, strSubsidy.size() - 2); 52 | 53 | This style relies less heavily on clever C++ and is more familiar to the Core Dev Team who are primarily PHP programmers. 54 | 55 | ==Proposal== 56 | 57 | Instead, how about we stop thinking about long term issues when we'll all be dead (barring near lightspeed travel, cryogenic revival, or other technology— like cryptocurrency— which only exists in science fiction). 58 | 59 | A softfork (see BIP16, BIP34, BIP62) will take place on april 1st 2214, permanently setting the subsidy to zero. The result of this will be that the total currency supply will be limited to 42 halfmillion (including the genesis coinbase output, which is not actually spendable). 60 | 61 | ==Implementation== 62 | 63 | An implementation for the reference client can be found on https://github.com/bitcoin/bitcoin/pull/3842 . 64 | 65 | ==Compatibility== 66 | 67 | Given the moderate time frame over which this change is to be implemented, we expect all miners to choose to screw themselves and deploy this change before 2214. 68 | 69 | If they don't, and a minority remains on the old code base, a fork may occur. Essentially, they'll be mining fool's gold after that time. 70 | 71 | ==Acknowledgements== 72 | 73 | Thanks to Gregory Maxwell for proposing this solution, and to Mike Hearn for insights into web development. Also thanks to "ditto-b" on github to implement a prototype ahead of time. 74 | 75 | ==Copyright== 76 | 77 | This document is placed in the public domain. 78 | -------------------------------------------------------------------------------- /bip-0060.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 60
 3 |   Title: Fixed Length "version" Message (Relay-Transactions Field)
 4 |   Author: Amir Taaki 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2013-06-16
 8 |
9 | 10 | ==Abstract== 11 | 12 | [[BIP 0037]] introduced a new flag to version messages which says whether to relay new transaction messages to that node. 13 | 14 | The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented. 15 | 16 | The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream. 17 | 18 | ==Motivation== 19 | 20 | One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one. 21 | 22 | As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherance to standard messages with field length compliance with every protocol version. 23 | 24 | Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader. 25 | 26 | ==Specification== 27 | === version === 28 | 29 | When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version. 30 | 31 | Payload: 32 | 33 | {|class="wikitable" 34 | ! Field Size !! Description !! Data type !! Comments 35 | |- 36 | | 4 || version || int32_t || Identifies protocol version being used by the node 37 | |- 38 | | 8 || services || uint64_t || bitfield of features to be enabled for this connection 39 | |- 40 | | 8 || timestamp || int64_t || standard UNIX timestamp in seconds 41 | |- 42 | | 26 || addr_recv || net_addr || The network address of the node receiving this message 43 | |- 44 | |colspan="4"| version >= 106 45 | |- 46 | | 26 || addr_from || net_addr || The network address of the node emitting this message 47 | |- 48 | | 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self. 49 | |- 50 | | ? || user_agent || var_str || [[bip-0014.mediawiki|User Agent]] (0x00 if string is 0 bytes long) 51 | |- 52 | | 4 || start_height || int32_t || The last block received by the emitting node 53 | |- 54 | | 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[bip-0037.mediawiki|BIP 0037]], since version >= 70001 55 | |} 56 | 57 | A "verack" packet shall be sent if the version packet was accepted. 58 | 59 | The following services are currently assigned: 60 | 61 | {|class="wikitable" 62 | ! Value !! Name !! Description 63 | |- 64 | | 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers. 65 | |} 66 | 67 | === Code Updates === 68 | 69 | fRelayTx is added to the PushMessage() call inside PushVersion() (net.cpp) 70 | 71 | 
72 | void CNode::PushVersion()
73 | {
74 |     /// when NTP implemented, change to just nTime = GetAdjustedTime()
75 |     int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
76 |     CAddress addrYou = (addr.IsRoutable() && !IsProxy(addr) ? addr : CAddress(CService("0.0.0.0",0)));
77 |     CAddress addrMe = GetLocalAddress(&addr);
78 |     RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
79 |     printf("send version message: version %d, blocks=%d, us=%s, them=%s, peer=%s\n", PROTOCOL_VERSION, nBestHeight, addrMe.ToString().c_str(), addrYou.ToString().c_str(), addr.ToString().c_str());
80 |     PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe,
81 |                 nLocalHostNonce, FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, std::vector()),
82 |                 nBestHeight, true);
83 | }
84 |
85 | 86 | Additionally the protocol version is increased from 70001 to 70002. 87 | 88 | ==Copyright== 89 | 90 | This document is placed in the public domain. 91 | -------------------------------------------------------------------------------- /bip-0061.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 61
  3 |   Title: Reject P2P message
  4 |   Author: Gavin Andresen 
  5 |   Status: Final
  6 |   Type: Standards Track
  7 |   Created: 2014-06-18
  8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP describes a new message type for the Bitcoin peer-to-peer network. 13 | 14 | ==Motivation== 15 | 16 | Giving peers feedback about why their blocks or transactions are rejected, or 17 | why they are being banned for not following the protocol helps 18 | interoperability between different implementations. 19 | 20 | It also gives SPV (simplified payment verification) clients a hint that something 21 | may be wrong when their transactions are rejected due to insufficient priority 22 | or fees. 23 | 24 | ==Specification== 25 | 26 | Data types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification 27 | 28 | ===reject=== 29 | 30 | One new message type "reject" is introduced. It is sent directly to a peer in response to a "version", "tx" or "block" message. 31 | 32 | For example, the message flow between two peers for a relayed transaction that is rejected for some reason would be: 33 | 34 | --> inv 35 | <-- getdata 36 | --> tx 37 | <-- reject 38 | 39 | All implementations of the P2P protocol version 70,002 and later should support the reject message. 40 | 41 | ====common payload==== 42 | 43 | 44 | Every reject message begins with the following fields. Some messages append extra, message-specific data. 45 | 46 | {| 47 | | Field Size || Name || Data type || Comments 48 | |- 49 | | variable || response-to-msg || var_str || Message that triggered the reject 50 | |- 51 | | 1 || reject-code || uint8_t || 0x01 through 0x4f (see below) 52 | |- 53 | | variable || reason || var_string || Human-readable message for debugging 54 | |} 55 | 56 | The human-readable string is intended only for debugging purposes; in particular, different implementations may 57 | use different strings. The string should not be shown to users or used for anthing besides diagnosing 58 | interoperability problems. 59 | 60 | The following reject code categories are used; in the descriptions below, "server" is the peer generating 61 | the reject message, "client" is the peer that will receive the message. 62 | 63 | {| 64 | | Range || Category 65 | |- 66 | | 0x01-0x0f || Protocol syntax errors 67 | |- 68 | | 0x10-0x1f || Protocol semantic errors 69 | |- 70 | | 0x40-0x4f || Server policy rule 71 | |} 72 | 73 | ==== rejection codes common to all message types ==== 74 | 75 | {| 76 | | Code || Description 77 | |- 78 | | 0x01 || Message could not be decoded 79 | |} 80 | 81 | ==== reject version codes ==== 82 | 83 | Codes generated during the intial connection process in response to a "version" message: 84 | 85 | {| 86 | | Code || Description 87 | |- 88 | | 0x11 || Client is an obsolete, unsupported version 89 | |- 90 | | 0x12 || Duplicate version message received 91 | |} 92 | 93 | ==== reject tx payload, codes ==== 94 | 95 | Transaction rejection messages extend the basic message with the transaction id hash: 96 | 97 | {| 98 | | Field Size || Name || Data type || Comments 99 | |- 100 | | 32 || hash || char[32] || transaction that is rejected 101 | |} 102 | 103 | The following codes are used: 104 | 105 | {| 106 | | Code || Description 107 | |- 108 | | 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.) 109 | |- 110 | | 0x12 || An input is already spent 111 | |- 112 | | 0x40 || Not mined/relayed because it is "non-standard" (type or version unknown by the server) 113 | |- 114 | | 0x41 || One or more output amounts are below the 'dust' threshold 115 | |- 116 | | 0x42 || Transaction does not have enough fee/priority to be relayed or mined 117 | |} 118 | 119 | ==== payload, reject block ==== 120 | 121 | Block rejection messages extend the basic message with the block header hash: 122 | 123 | {| 124 | | Field Size || Name || Data type || Comments 125 | |- 126 | | 32 || hash || char[32] || block (hash of block header) that is rejected 127 | |} 128 | 129 | Rejection codes: 130 | 131 | {| 132 | | code || description 133 | |- 134 | | 0x10 || Block is invalid for some reason (invalid proof-of-work, invalid signature, etc) 135 | |- 136 | | 0x11 || Block's version is no longer supported 137 | |- 138 | | 0x43 || Inconsistent with a compiled-in checkpoint 139 | |} 140 | 141 | Note: blocks that are not part of the server's idea of the current best chain, but are otherwise valid, should not trigger reject messages. 142 | 143 | == Compatibility == 144 | 145 | The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it. 146 | 147 | == Implementation notes == 148 | 149 | Implementors must consider what happens if an attacker either sends them 150 | reject messages for valid transactions/blocks or sends them random 151 | reject messages, and should beware of possible denial-of-service attacks. 152 | For example, notifying the user of every reject message received 153 | would make it trivial for an attacker to mount an annoy-the-user attack. 154 | Even merely writing every reject message to a debugging log could make 155 | an implementation vulnerable to a fill-up-the-users-disk attack. 156 | -------------------------------------------------------------------------------- /bip-0064.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 64
  3 |   Title: getutxo message
  4 |   Author: Mike Hearn 
  5 |   Status: Draft
  6 |   Type: Standards Track
  7 |   Created: 2014-06-10
  8 |
9 | 10 | ==Abstract== 11 | 12 | This document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints. 13 | 14 | ==Motivation== 15 | 16 | All full Bitcoin nodes maintain a database called the unspent transaction output set. This set is 17 | how double spending is checked for: to be valid a transaction must identify unspent outputs in this 18 | set using an identifier called an "outpoint", which is merely the hash of the output's containing 19 | transaction plus an index. 20 | 21 | The ability to query this can sometimes be useful for a lightweight/SPV client which does not have 22 | the full UTXO set at hand. For example, it can be useful in applications implementing assurance 23 | contracts to do a quick check when a new pledge becomes visible to test whether that pledge was 24 | already revoked via a double spend. Although this message is not strictly necessary because e.g. 25 | such an app could be implemented by fully downloading and storing the block chain, it is useful for 26 | obtaining acceptable performance and resolving various UI cases. 27 | 28 | Another example of when this data can be useful is for performing floating fee calculations in an 29 | SPV wallet. This use case requires some other changes to the Bitcoin protocol however, so we will 30 | not dwell on it here. 31 | 32 | ==Specification== 33 | 34 | Two new messages are defined. The "getutxos" message has the following structure: 35 | 36 | {|class="wikitable" 37 | ! Field Size !! Description !! Data type !! Comments 38 | |- 39 | | 1 || check mempool || bool || Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend. 40 | |- 41 | | ? || outpoints || vector || The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message. 42 | |} 43 | 44 | The response message "utxos" has the following structure: 45 | 46 | {|class="wikitable" 47 | ! Field Size !! Description !! Data type !! Comments 48 | |- 49 | | 4 || chain height || uint32 || The height of the chain at the moment the result was calculated. 50 | |- 51 | | 32 || chain tip hash || uint256 || Block hash of the top of the chain at the moment the result was calculated. 52 | |- 53 | | ? || hit bitmap || byte[] || An array of bytes encoding one bit for each outpoint queried. Each bit indicates whether the queried outpoint was found in the UTXO set or not. 54 | |- 55 | | ? || result utxos || result[] || A list of result objects (defined below), one for each outpoint that is unspent (i.e. has a bit set in the bitmap). 56 | |} 57 | 58 | The result object is defined as: 59 | 60 | {|class="wikitable" 61 | ! Field Size !! Description !! Data type !! Comments 62 | |- 63 | | 4 || tx version || uint32 || The version number of the transaction the UTXO was found in. 64 | |- 65 | | 4 || height || uint32 || The height of the block containing the defining transaction, or 0x7FFFFFFF if the tx is in the mempool. 66 | |- 67 | | ? || output || CTxOut || The output itself, serialized in the same way as in a tx message. 68 | |} 69 | 70 | ==Backward compatibility== 71 | 72 | Nodes indicate support by advertising a protocol version above 70003 and by setting a new 73 | NODE_GETUTXO flag in their nServices field, which has a value of 2 (the second bit of the field). 74 | 75 | ==Authentication== 76 | 77 | The UTXO set is not currently authenticated by anything. There are proposals to resolve this by 78 | introducing a new consensus rule that commits to a root hash of the UTXO set in blocks, however this 79 | feature is not presently available in the Bitcoin protocol. Once it is, the utxos message could be 80 | upgraded to include Merkle branches showing inclusion of the UTXOs in the committed sets. 81 | 82 | If the requesting client is looking up outputs for a signed transaction that they have locally, the 83 | client can partly verify the returned output by running the input scripts with it. Currently this 84 | verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also 85 | allow the value to be checked in this way. It does not show that the output is really unspent or was 86 | ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey 87 | should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE. 88 | 89 | If the requesting client has a mapping of chain heights to block hashes in the best chain e.g. 90 | obtained via getheaders, then they can obtain a proof that the output did at one point exist by 91 | requesting the block and searching for the output within it. When combined with Bloom filtering this 92 | can be reasonably efficient. 93 | 94 | Note that even when the outputs are being checked against something this protocol has the same 95 | security model as Bloom filtering: a remote node can lie through omission by claiming the requested 96 | UTXO does not exist / was already spent (they are the same, from the perspective of a full node). 97 | Querying multiple nodes and combining their answers can be a partial solution to this, although as 98 | nothing authenticates the Bitcoin P2P network a man in the middle could still yield incorrect 99 | results. 100 | 101 | ==Implementation== 102 | 103 | https://github.com/bitcoin/bitcoin/pull/4351/files -------------------------------------------------------------------------------- /bip-0106.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 106
 3 |   Title: Dynamically Controlled Bitcoin Block Size Max Cap
 4 |   Author: Upal Chakraborty 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 2015-08-24
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... 13 | 14 | i. Depending only on previous block size calculation. 15 | 16 | ii. Depending on previous block size calculation and previous Tx fee collected by miners. 17 | 18 | ==Motivation== 19 | 20 | With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... 21 | 22 | https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= 23 | 24 | ==Specification== 25 | 26 | ===Proposal 1 : Depending only on previous block size calculation=== 27 | 28 | If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize 29 | Double MaxBlockSize 30 | Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize 31 | Half MaxBlockSize 32 | Else 33 | Keep the same MaxBlockSize 34 | 35 | ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== 36 | 37 | TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period 38 | TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) 39 | 40 | TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period 41 | TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) 42 | 43 | If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) ) 44 | MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty 45 | Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) ) 46 | MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty 47 | Else 48 | Keep the same MaxBlockSize 49 | 50 | ==Rationale== 51 | 52 | These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. 53 | 54 | ===Proposal 1 : Depending only on previous block size calculation=== 55 | 56 | This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. 57 | 58 | ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== 59 | 60 | This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating a Tx fee pressure on the market. On the other hand, though the block size max cap is dynamically controlled, it is very difficult to game by any party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. 61 | 62 | ==Compatibility== 63 | 64 | This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks. 65 | 66 | ==Other solutions considered== 67 | 68 | [http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik 69 | 70 | [https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld 71 | 72 | [https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase maximum block size] - by Gavin Andresen 73 | 74 | [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following technological growth] - by Pieter Wuille 75 | 76 | [https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus Dryja 77 | 78 | ==Deployment== 79 | 80 | If consensus is achieved, deployment can be made at a future block number at which difficulty will change. 81 | -------------------------------------------------------------------------------- /bip-0113.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 113
  3 |   Title: Median time-past as endpoint for lock-time calculations
  4 |   Author: Thomas Kerin 
  5 |           Mark Friedenbach 	
  6 |   Status: Draft
  7 |   Type: Standards Track
  8 |   Created: 2015-08-10
  9 |
10 | 11 | 12 | ==Abstract== 13 | 14 | This BIP is a proposal to redefine the semantics used in determining a 15 | time-locked transaction's eligibility for inclusion in a block. The 16 | median of the last 11 blocks is used instead of the block's timestamp, 17 | ensuring that it increases monotonically with each block. 18 | 19 | 20 | ==Motivation== 21 | 22 | At present, transactions are excluded from inclusion in a block if the 23 | present time or block height is less than or equal to that specified 24 | in the locktime. Since the consensus rules do not mandate strict 25 | ordering of block timestamps, this has the unfortunate outcome of 26 | creating a perverse incentive for miners to lie about the time of 27 | their blocks in order to collect more fees by including transactions 28 | that by wall clock determination have not yet matured. 29 | 30 | This BIP proposes comparing the locktime against the median of the 31 | past 11 block's timestamps, rather than the timestamp of the block 32 | including the transaction. Existing consensus rules guarantee this 33 | value to monotonically advance, thereby removing the capability for 34 | miners to claim more transaction fees by lying about the timestamps of 35 | their block. 36 | 37 | This proposal seeks to ensure reliable behaviour in locktime calculations as 38 | required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68, and BIP112 (CHECKSEQUENCEVERIFY). 39 | 40 | 41 | ==Specification== 42 | 43 | The values for transaction locktime remain unchanged. The difference is only in 44 | the calculation determining whether a transaction can be included. Instead of 45 | an unreliable timestamp, the following function is used to determine the current 46 | block time for the purpose of checking lock-time constraints: 47 | 48 | enum { nMedianTimeSpan=11 }; 49 | 50 | int64_t GetMedianTimePast(const CBlockIndex* pindex) 51 | { 52 | int64_t pmedian[nMedianTimeSpan]; 53 | int64_t* pbegin = &pmedian[nMedianTimeSpan]; 54 | int64_t* pend = &pmedian[nMedianTimeSpan]; 55 | for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev) 56 | *(--pbegin) = pindex->GetBlockTime(); 57 | std::sort(pbegin, pend); 58 | return pbegin[(pend - pbegin)/2]; 59 | } 60 | 61 | Lock-time constraints are checked by the consensus method IsFinalTx(), 62 | or LockTime() under BIP68. These methods take the block time as one 63 | parameter. This BIP proposes that after activation calls to 64 | IsFinalTx() or LockTime() within consensus code use the return value 65 | of `GetMedianTimePast(pindexPrev)` instead. 66 | 67 | A reference implementation of this proposal is provided in the 68 | following git repository: 69 | 70 | https://github.com/maaku/bitcoin/tree/medianpasttimelock 71 | 72 | 73 | ==Deployment== 74 | 75 | We reuse the double-threshold switchover mechanism from BIPs 34 and 76 | 66, with the same thresholds, but for nVersion = 8. The new rules are 77 | in effect for every block (at height H) with nVersion = 8 and at least 78 | 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also 79 | have nVersion = 8. Furthermore, when 950 out of the 1000 blocks 80 | preceding a block do have nVersion = 8, nVersion = 3 blocks become 81 | invalid, and all further blocks enforce the new rules. 82 | 83 | When assessing the block version as mask of ~0x20000007 must be applied 84 | to work around the complications caused by 85 | [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use] 86 | of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal]. 87 | 88 | By applying ~0x20000007 with nVersion = 8, the thresholds should be tested 89 | comparing block nVersion >= 4 as this will save a bit for future use. 90 | 91 | It is recommended that this soft-fork deployment trigger include other related 92 | proposals for improving Bitcoin's lock-time capabilities, including: 93 | 94 | [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: 95 | CHECKLOCKTIMEVERIFY, 96 | 97 | [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 98 | Consensus-enforced transaction replacement signalled via sequence numbers, 99 | 100 | and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: 101 | CHECKSEQUENCEVERIFY. 102 | 103 | 104 | ==Acknowledgements== 105 | 106 | Mark Friedenbach for designing and authoring the reference 107 | implementation of this BIP. 108 | 109 | Thanks go to Gregory Maxwell who came up with the original idea, 110 | in #bitcoin-wizards on 2013-07-16. 111 | 112 | Thomas Kerin authored this BIP document. 113 | 114 | 115 | ==Compatibility== 116 | 117 | Transactions generated using time-based lock-time will take 118 | approximately an hour longer to confirm than would be expected under 119 | the old rules. This is not known to introduce any compatibility 120 | concerns with existing protocols. 121 | 122 | 123 | ==References== 124 | [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] 125 | 126 | [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers] 127 | 128 | [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY] 129 | 130 | [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations] 131 | 132 | [https://gist.github.com/sipa/bf69659f43e763540550 Version bits] 133 | 134 | 135 | ==Copyright== 136 | 137 | This document is placed in the public domain. 138 | -------------------------------------------------------------------------------- /bip-0012.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 12
 3 |   Title: OP_EVAL
 4 |   Author: Gavin Andresen 
 5 |   Status: Withdrawn
 6 |   Type: Standards Track
 7 |   Created: 2011-10-18
 8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. 13 | 14 | ==Motivation== 15 | 16 | Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. 17 | 18 | ==Specification== 19 | 20 | OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: 21 | 22 | * When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. 23 | * If there is no item on the top of the stack or the item is not a valid script then transaction validation fails. 24 | * If there are any OP_CODESEPARATORs in the deserialized script then transaction validation fails. 25 | * If there are any OP_EVALs in the deserialized script they are also executed, but recursion is limited to a depth of 2. 26 | * Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail. 27 | 28 | A new standard transaction type (scriptPubKey) that is relayed by clients and included in mined blocks is also defined: 29 | 30 | DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL 31 | 32 | Which is redeemed by a standard scriptSig: 33 | ...signatures... {serialized script} 34 | 35 | Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the ''serialized script'' is, itself, one of the standard transaction types. 36 | 37 | ==Rationale== 38 | 39 | OP_EVAL allows the receiver of bitcoins to specify how they can be spent when they are spent, instead of requiring the sender of the bitcoins to know the details of how the bitcoins may be redeemed. The sender only needs to know the hash of the ''serialized script'', and one new type of bitcoin address can be used to fund arbitrarily complex transactions. 40 | 41 | If ''serialized script'' is a large or complicated multi-signature script, then the burden of paying for it (in increased transaction fees due to more signature operations or transaction size) is shifted from the sender to the receiver. 42 | 43 | The main objection to OP_EVAL is that it adds complexity, and complexity is the enemy of security. Also, evaluating data as code has a long record of being a source of security vulnerabilties. 44 | 45 | That same argument can be applied to the existing Bitcoin 'scripting' system; scriptPubKeys are transmit as data across the network and are then interpreted by every bitcoin implementation. OP_EVAL just moves the data that will be interpreted. It is debatable whether or not the entire idea of putting a little interpreted expression evaluation language at the core of Bitcoin was brilliant or stupid, but the existence of OP_EVAL does not make the expression language less secure. 46 | 47 | There is a 1-confirmation attack on old clients that interepret OP_EVAL as a no-op, but it is expensive and difficult in practice. The attack is: 48 | 49 | # Attacker creates an OP_EVAL transaction that is valid as seen by old clients, but invalid for new clients. 50 | # Attacker also creates a standard transaction that spends the OP_EVAL transaction, and pays the victim. 51 | # Attacker manages to mine a block that contains both transactions. If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block. 52 | 53 | The attack is expensive because it requires the attacker create a block that they know will be invalidated. It is difficult because bitcoin businesses should not accept 1-confirmation transactions for higher-value transactions. 54 | 55 | ==Backwards Compatibility== 56 | 57 | Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. They will check only that the ''serialized script'' hashes to the correct value; the OP_EVAL will be interpreted as a no-op, and as long as the hash is correct the transaction will be considered valid (no signature checking will be done by old clients and miners). 58 | 59 | Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are put into a block by either an old miner that includes non-standard transactions in its blocks or by a new miner. 60 | 61 | Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases: 62 | 63 | # An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners. 64 | # An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners. 65 | 66 | For case (1), new clients and miners will be coded to interpret OP_EVAL as a no-op until February 1, 2012. Before then, miners will be asked to put the string "OP_EVAL" in blocks that they produce so that hashing power that supports the new opcode can be gauged. If less than 50% of miners accept the change as of January 15, 2012 the rollout will be postponed until more than 50% of hashing power supports OP_EVAL (the rollout will be rejected if it becomes clear that a majority of hashing power will not be achieved). 67 | 68 | For case (2), new clients and miners will be written to make sure that transactions involving OP_EVAL are valid if OP_EVAL is interpreted as a no-op. 69 | Example of a transaction that must fail for both old and new miners/clients: 70 | scriptSig: {serialized OP_11} 71 | scriptPubKey: OP_EVAL OP_11 OP_EQUAL 72 | 73 | ==Reference Implementation== 74 | 75 | https://github.com/gavinandresen/bitcoin-git/tree/op_eval 76 | 77 | ==See Also== 78 | 79 | https://bitcointalk.org/index.php?topic=46538 80 | 81 | "Bitcoin Address 01" BIP 82 | 83 | M-of-N Multisignature Transactions BIP 11 84 | -------------------------------------------------------------------------------- /bip-0039.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP:     BIP-0039
  3 |   Title:   Mnemonic code for generating deterministic keys
  4 |   Authors: Marek Palatinus 
  5 |            Pavol Rusnak 
  6 |            Aaron Voisine 
  7 |            Sean Bowe 
  8 |   Status:  Draft
  9 |   Type:    Standards Track
 10 |   Created: 2013-09-10
 11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes the implementation of a mnemonic code or mnemonic sentence -- 16 | a group of easy to remember words -- for the generation of deterministic wallets. 17 | 18 | It consists of two parts: generating the mnemonic, and converting it into a 19 | binary seed. This seed can be later used to generate deterministic wallets using 20 | BIP-0032 or similar methods. 21 | 22 | ==Motivation== 23 | 24 | A mnemonic code or sentence is superior for human interaction compared to the 25 | handling of raw binary or hexidecimal representations of a wallet seed. The 26 | sentence could be written on paper or spoken over the telephone. 27 | 28 | This guide is meant to be a way to transport computer-generated randomness with 29 | a human readable transcription. It's not a way to process user-created 30 | sentences (also known as brainwallets) into a wallet seed. 31 | 32 | ==Generating the mnemonic== 33 | 34 | The mnemonic must encode entropy in a multiple of 32 bits. With more entropy 35 | security is improved but the sentence length increases. We refer to the 36 | initial entropy length as ENT. The recommended size of ENT is 128-256 bits. 37 | 38 | First, an initial entropy of ENT bits is generated. A checksum is generated by 39 | taking the first 
ENT / 32
bits of its SHA256 hash. This checksum is 40 | appended to the end of the initial entropy. Next, these concatenated bits 41 | are split into groups of 11 bits, each encoding a number from 0-2047, serving 42 | as an index into a wordlist. Finally, we convert these numbers into words and 43 | use the joined words as a mnemonic sentence. 44 | 45 | The following table describes the relation between the initial entropy 46 | length (ENT), the checksum length (CS) and the length of the generated mnemonic 47 | sentence (MS) in words. 48 | 49 | 
 50 | CS = ENT / 32
 51 | MS = (ENT + CS) / 11
 52 | 
 53 | |  ENT  | CS | ENT+CS |  MS  |
 54 | +-------+----+--------+------+
 55 | |  128  |  4 |   132  |  12  |
 56 | |  160  |  5 |   165  |  15  |
 57 | |  192  |  6 |   198  |  18  |
 58 | |  224  |  7 |   231  |  21  |
 59 | |  256  |  8 |   264  |  24  |
 60 |
61 | 62 | ==Wordlist== 63 | 64 | An ideal wordlist has the following characteristics: 65 | 66 | a) smart selection of words 67 | - the wordlist is created in such way that it's enough to type the first four 68 | letters to unambiguously identify the word 69 | 70 | b) similar words avoided 71 | - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly" 72 | not only make remembering the sentence difficult, but are also more error 73 | prone and more difficult to guess 74 | 75 | c) sorted wordlists 76 | - the wordlist is sorted which allows for more efficient lookup of the code words 77 | (i.e. implementations can use binary search instead of linear search) 78 | - this also allows trie (a prefix tree) to be used, e.g. for better compression 79 | 80 | The wordlist can contain native characters, but they must be encoded in UTF-8 81 | using Normalization Form Compatibility Decomposition (NFKD). 82 | 83 | ==From mnemonic to seed== 84 | 85 | A user may decide to protect their mnemonic with a passphrase. If a passphrase is not 86 | present, an empty string "" is used instead. 87 | 88 | To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic 89 | sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again 90 | in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as 91 | the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes). 92 | 93 | This seed can be later used to generate deterministic wallets using BIP-0032 or 94 | similar methods. 95 | 96 | The conversion of the mnemonic sentence to a binary seed is completely independent 97 | from generating the sentence. This results in rather simple code; there are no 98 | constraints on sentence structure and clients are free to implement their own 99 | wordlists or even whole sentence generators, allowing for flexibility in wordlists 100 | for typo detection or other purposes. 101 | 102 | Although using a mnemonic not generated by the algorithm described in "Generating the 103 | mnemonic" section is possible, this is not advised and software must compute a 104 | checksum for the mnemonic sentence using a wordlist and issue a warning if it is 105 | invalid. 106 | 107 | The described method also provides plausible deniability, because every passphrase 108 | generates a valid seed (and thus a deterministic wallet) but only the correct one 109 | will make the desired wallet available. 110 | 111 | ==Wordlists== 112 | 113 | * [[bip-0039/bip-0039-wordlists.md|Moved to separate document]] 114 | 115 | ==Test vectors== 116 | 117 | The test vectors include input entropy, mnemonic and seed. The 118 | passphrase "TREZOR" is used for all vectors. 119 | 120 | https://github.com/trezor/python-mnemonic/blob/master/vectors.json 121 | 122 | Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json 123 | 124 | (Japanese wordlist test with heavily normalized symbols as passphrase) 125 | 126 | ==Reference Implementation== 127 | 128 | Reference implementation including wordlists is available from 129 | 130 | http://github.com/trezor/python-mnemonic 131 | 132 | ==Other Implementations== 133 | 134 | Objective-C - https://github.com/nybex/NYMnemonic 135 | 136 | Haskell - https://github.com/haskoin/haskoin 137 | 138 | .NET C# (PCL) - https://github.com/Thashiznets/BIP39.NET 139 | 140 | .NET C# (PCL) - https://github.com/NicolasDorier/NBitcoin 141 | 142 | JavaScript - https://github.com/bitpay/bitcore-mnemonic 143 | -------------------------------------------------------------------------------- /bip-0050.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 50
 3 |   Title: March 2013 Chain Fork Post-Mortem
 4 |   Author: Gavin Andresen 
 5 |   Status: Draft
 6 |   Type: Informational
 7 |   Created: 2013-03-20
 8 |
9 | 10 | ==What went wrong== 11 | A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve. 12 | 13 | In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block. 14 | 15 | During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious. 16 | 17 | ==What went right== 18 | * The split was detected very quickly. 19 | * The right people were online and available in IRC or could be raised via Skype. 20 | * Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version. 21 | * Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly. 22 | * Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money 23 | 24 | ==Root cause== 25 | Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this: 26 | 27 | :The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety. 28 | 29 | Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident. 30 | 31 | Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully. 32 | 33 | Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs. 34 | 35 | This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). 36 | 37 | ==Action items== 38 | 39 | ===Immediately=== 40 | 41 | '''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules: 42 | # Reject blocks that could cause more than 10,000 locks to be taken. 43 | # Limit the maximum block-size created to 500,000 bytes 44 | # Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000 45 | # Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot. 46 | # Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page. 47 | 48 | ===Alert system=== 49 | 50 | '''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys. 51 | 52 | '''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify= Run command when an AppliesToMe() alert is received. 53 | 54 | '''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible). 55 | 56 | Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version. 57 | 58 | ===Safe mode=== 59 | 60 | '''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing). 61 | 62 | ===Testing=== 63 | 64 | Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier. 65 | 66 | ===Double spending=== 67 | 68 | A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system. 69 | 70 | ===Resolution=== 71 | 72 | On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network. 73 | -------------------------------------------------------------------------------- /bip-0121.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 121
  3 |   Title: Proof of Payment URI scheme
  4 |   Author: Kalle Rosenbaum 
  5 |   Status: Draft
  6 |   Type: Standards Track
  7 |   Created: 2015-07-27
  8 |
9 | 10 | == Abstract == 11 | 12 | This is a proposal for a URI scheme to be used in the Proof of Payment 13 | process. 14 | 15 | == Motivation == 16 | 17 | To make a Proof of Payment, the party that wants the proof needs to 18 | transfer a Proof of Payment request to the wallet software of the 19 | other party. To facilitate that transfer, a new URI scheme 20 | representing the PoP request is proposed. This URI can then be encoded 21 | in QR images or be sent over NFC in order to transfer it to the wallet. 22 | 23 | == Specification == 24 | 25 | The specification is the same as BIP0021, with the following 26 | differences: 27 | 28 | * The URI scheme is btcpop instead of bitcoin 29 | * The path component, i.e. the address part, is always empty. 30 | * A mandatory p parameter whose value contains the destination for the PoP. This could for example be a https: URL or a mailto: URI. 31 | * A mandatory n parameter representing the nonce, base58 encoded. 32 | * An optional txid parameter containing the Base58 encoded hash of the transaction to prove. 33 | 34 | Just as in BIP0021, elements of the query component may contain 35 | characters outside the valid range. These must first be encoded 36 | according to UTF-8, and then each octet of the corresponding UTF-8 37 | sequence must be percent-encoded as described in RFC 3986. 38 | 39 | All parameters except p and n are hints to the 40 | wallet on which transaction to create a PoP for. 41 | 42 | The extensibility of BIP0021 applies to this scheme as well. For 43 | example, a date parameter or a toaddr parameter 44 | might be useful. req-* parameters are also allowed and obey 45 | the same rules as in BIP0021, clients not supporting a req-* 46 | parameter must consider the URI invalid. 47 | 48 | === Keep URIs short === 49 | 50 | Implementations should keep the URIs as short as possible. This is 51 | because it makes QR decoding more stable. A camera with a scratched 52 | lens or low resolution may run into problems scanning huge QR 53 | codes. This is why the txid parameter is encoded in Base58 54 | instead of the classic hex encoded string. We get away with 44 55 | characters instead of 64. Also, the nonce parameter is Base58 56 | encoded for the same reason. 57 | 58 | == Interpretation == 59 | 60 | === Transaction hints === 61 | 62 | The wallet processing the URI must use the hints in the PoP request to 63 | filter its transaction set. The label, amount and 64 | message parameters must, if present in the URI, exactly match 65 | the data associated with the original payment according to the 66 | following table: 67 | 68 | {| 69 | | btcpop: URI parameter || bitcoin: URI parameter || BIP70 PaymentDetails data 70 | |- 71 | | label || label || merchant_data 72 | |- 73 | | amount || amount || sum of outputs.amount 74 | |- 75 | | message || message || memo 76 | |} 77 | 78 | The txid parameter value must match the transaction hash of 79 | the payment. 80 | 81 | After filtering, the resulting transaction set is displayed to the 82 | user who selects one of them to prove. An implementation could also 83 | automatically select a transaction in the filtered set, but 84 | there must still be a way for the user to select freely among the 85 | matching transactions. If the filtered set is empty, no transaction 86 | fits the hints and a message about that is presented to the user. If 87 | the filtered set contains exactly one transaction, which is 88 | preferable, that transaction can be automatically selected. 89 | 90 | As a fallback, there must also be a way for the user to select any 91 | transaction from the wallet regardless of the transaction hints. This 92 | can be useful if the metadata of the wallet is lost, possibly due to a 93 | restore from backup. 94 | 95 | === PoP destination p === 96 | 97 | The p parameter value is the destination where to send the 98 | PoP to. This destination is typically a https: URL or a 99 | http: URL, but it could be any type of URI, for example 100 | mailto:. To keep btcpop: URIs short, users should 101 | not make their p parameter unneccesarily long. 102 | 103 | ==== http: and https: URLs ==== 104 | 105 | Wallet implementations must support the http: and 106 | https: schemes in which case POST method must be 107 | used. The content type of the POST request must be set to 108 | 109 | Content-Type: application/bitcoin-pop 110 | Content-Transfer-Encoding: binary 111 | 112 | == Examples == 113 | 114 | Send PoP for a transaction with label "video 42923" to 115 | https://www.example.com/pop/352, using nonce 116 | 0x73 0xd5 0x1a 0xbb 0xd8 0x9c: 117 | 
118 |  btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video 42923
119 |
120 | Send PoP through mail using 121 | mailto:pop@example.com?subject=pop444, amount 122 | is 13370000 satoshis, nonce is 0x6f 0xe 0xfb 0x68 0x92 0xf9. 123 | Note that the ? before subject is OK according to RFC3986, 124 | since the query part starts from the first ?: 125 | 
126 |  btcpop:?p=mailto:pop@example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337
127 |
128 | Send PoP for transaction with id 129 | cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79 130 | to pizza place at http://pizza.example.com/pop/laszlo111 using nonce 0xfc 0xcc 0x2c 0x35 0xf0 0xb8 131 | 
132 |  btcpop:?p=http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL
133 |
134 | == Reference implementation == 135 | 136 | [https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub] 137 | 138 | [https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub] 139 | 140 | == References == 141 | 142 | [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme 143 | 144 | [https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki BIP0120]: Proof of Payment 145 | 146 | [https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier (URI): Generic Syntax 147 | -------------------------------------------------------------------------------- /bip-0014.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 14
 3 |   Title: BIP Protocol Version and User Agent
 4 |   Author: Amir Taaki 
 5 |           Patrick Strateman 
 6 |   Status: Accepted
 7 |   Type: Standards Track
 8 |   Created: 2011-11-10
 9 |   Post-History: 2011-11-02
10 |
11 | 12 | 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. 13 | 14 | == Past Situation == 15 | 16 | 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. 17 | 18 | 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. 19 | 20 | == Rationale == 21 | 22 | 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. 23 | 24 | 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. 25 | 26 | 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. 27 | 28 | 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). 29 | 30 | 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. 31 | 32 | In short: 33 | 34 | * Protocol version: way to distinguish between nodes and behave different accordingly. 35 | * User agent: simple informational tool. Protocol should not be modified depending on user agent. 36 | 37 | == Browser User-Agents == 38 | 39 | [http://tools.ietf.org/html/rfc1945 RFC 1945] vaguely specifies a user agent to be a string of the product with optional comments. 40 | 41 | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20100127 Gentoo Shiretoko/3.5.6 42 | 43 | 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. 44 | 45 | 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. 46 | 47 | == Proposal == 48 | 49 | 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. 50 | 51 | The currently unused sub_version_num field in "version" packets will become the new user-agent string. 52 | 53 | 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. 54 | 55 | Basic format: 56 | 57 | /Name:Version/Name:Version/.../ 58 | 59 | Example: 60 | 61 | /Satoshi:5.64/bitcoin-qt:0.4/ 62 | /Satoshi:5.12/Spesmilo:0.8/ 63 | 64 | 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: 65 | 66 | * Version numbers in the form of Major.Minor.Revision (2.6.41) 67 | * Repository builds using a date in the format of YYYYMMDD (20110128) 68 | 69 | 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. 70 | 71 | 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. 72 | 73 | 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. 74 | 75 | Example: 76 | 77 | /BitcoinJ:0.2(iPad; U; CPU OS 3_2_1)/AndroidBuild:0.8/ 78 | 79 | Reserved symbols are therefore: / : ( ) 80 | 81 | They should not be misused beyond what is specified in this section. 82 | 83 | * / separates the code-stack 84 | * : specifies the implementation version of the particular stack 85 | * ( and ) delimits a comment which optionally separates data using ; 86 | 87 | == Timeline == 88 | 89 | 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. 90 | -------------------------------------------------------------------------------- /bip-0033.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 33
  3 |   Title: Stratized Nodes
  4 |   Author: Amir Taaki 
  5 |   Status: Draft
  6 |   Type: Standards Track
  7 |   Created: 2012-05-15
  8 |
9 | 10 | == Abstract == 11 | 12 | As the Bitcoin network scales, roles are fast becoming specialised. In the beginning, a single Bitcoin user would perform the synonymous roles of miner, merchant and end-user. With the growth however of this system, these functions are being abstracted away to specialised services as a natural part of Bitcoin's growth. 13 | 14 | Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem. 15 | 16 | This document will examine a proposal which will be termed ''stratized nodes'', a modification of an earlier concept termed ''blockchain service''. 17 | 18 | == History == 19 | 20 | Jan Moller created BCCAPI in 2011. BCCAPI allowed a user's client to delegate blockchain interaction to a remote server. This server would store and manage the blockchain while the user client would run queries against that server. 21 | 22 | ThomasV later created Electrum server. BCCAPI's server backend was proprietary, and Electrum required a full Free Software stack. Electrum's server was an adhoc temporary replacement. As it grew and became used, issues started to appear in its design. 23 | 24 | Marek Palatinus (slush) drafted a new standard called Stratum to replace Electrum's server. Stratum has multiple transports and is usable as a blockchain server by merchants, miners and user-clients. Electrum moved to using a Stratum implementation first relying on ABE/bitcoind and more recently libbitcoin. 25 | 26 | Stratum is unmaintained by Marek Palatinus, suffers from easy resource starvation and denial of service attacks, and is insecure. The proposal specified here is intended to replace the Stratum's role as a blockchain for user-clients. The proposal here is solely concerned with removing the onus of blockchain validation and lookups from user-clients to specialised services in a secure manner. Any secondary benefits or uses are purely incidental. 27 | 28 | == Overview == 29 | 30 | During the initial handshake between Bitcoin nodes, a version packet is sent. version packets have a bitfield called services. Nodes can fill this field to tell the network how they behave and which services they support. NODE_NETWORK (1) means a node can be asked for full blocks for example. 31 | 32 | We propose two more values of NODE_SERVICE (2) and NODE_STRATIZED (4). 33 | 34 | === NODE_SERVICE === 35 | 36 | * A blockchain service which supports the additional messages "getoutputs" and "getspends". 37 | * Does not respond to "getdata" messages by itself (unless NODE_NETWORK is specified) 38 | * If NODE_NETWORK is specified, then "getdata" for transactions will retrieve them not only from the memory pool but also check the blockchain if necessary. 39 | 40 | === NODE_STRATIZED === 41 | 42 | * A node which uses the stratized strategy specified in this document. 43 | * NODE_STRATIZED will relay inventories for accepted transactions. 44 | * Does not support "getblocks" as stratized nodes do not contain the entire blockchain. 45 | 46 | Apart from the differences noted above, the nodes are otherwise unchanged in their behaviour from NODE_NETWORK. 47 | 48 | == Specification == 49 | 50 | === Initialisation === 51 | 52 | Four new messages are defined which are represented below in C-like pseudocode. 53 | 54 | "getoutputs" 55 | 
 56 | struct decoded_address
 57 | {
 58 |     uint8_t payment_type;
 59 |     uint8_t address_hash[16];
 60 | };
 61 | 
 62 | struct get_outputs
 63 | {
 64 |     decoded_address dest;
 65 | };
 66 |
67 | 68 | "outputs" 69 | 
 70 | struct point_t
 71 | {
 72 |     uint8_t hash[32];
 73 |     uint32_t index;
 74 | };
 75 | 
 76 | struct outputs
 77 | {
 78 |     decoded_address dest;
 79 |     uint64_t number_outputs;  // variable uint
 80 |     point_t outpoints[];
 81 | };
 82 |
83 | 84 | "getspend" 85 | 
 86 | struct get_spend
 87 | {
 88 |     point_t outpoint;
 89 | };
 90 |
91 | 92 | "spend" 93 | 
 94 | struct spend
 95 | {
 96 |     point_t outpoint, inpoint;
 97 | };
 98 |
99 | 100 | These four messages allow a node to discover the history of a Bitcoin address without needing direct access to the blockchain. 101 | 102 | A typical use case might look like: 103 | # Send "getoutputs" for a decoded Bitcoin address. 104 | # Receive "outputs", and loop through each contained output point: 105 | ## Send "getdata" to download the transaction for that point. 106 | ## Send "getspend" for each output point. 107 | # Receive "spend": 108 | ## Send "getdata" to download the transaction for that input point. 109 | 110 | This sequence allows the gradual but fast build up of history for an address. 111 | 112 | === Updates === 113 | 114 | Nodes receive "inv" messages as normal from service nodes, issuing "getdata" to download the block or transaction data. From this they check for newly sent (in the input points) or received (in the output points) payments in the transaction data. 115 | 116 | Note that blocks must at minimum have their merkle root validated and transactions must be checked for uniqueness by stratized nodes. 117 | 118 | == Security == 119 | 120 | The concern here is that stratized nodes are at the mercy of blockchain services. This proposal deals with that issue by designing this protocol in such a way that the implementation can resolve the common history between multiple services. 121 | 122 | A stratized node will typically connect to 8 blockchain services. It will only accept an output, spend or inventory vector that has been sent by a common subset of all those services (6 in our example). This spreads the risk between all services, and does not make a node vulnerable to any one rogue blockchain service. 123 | 124 | == Privacy == 125 | 126 | The other strategy for thin clients termed ''headers-only'' or ''Simplified. Payment. Verification.'' have the same privacy issues as this proposal. SPV resolves this problem by sending out fake requests for transaction data which obfuscates the client data. By sending out a sufficient number of fake requests, privacy can be kept to a sufficient level. 127 | 128 | == Rationale == 129 | 130 | NODE_SERVICE does not respond to "getdata" requests by itself (unless used in conjunction with NODE_NETWORK) to prevent starvation attacks. This allows a single trusted NODE_SERVICE architecture (possibly acting as a front-end to multiple backends) to service very many nodes while externalising the costs to the Bitcoin network. 131 | 132 | NODE_STRATIZED tries its best to maintain the facade and help upkeep the Bitcoin network (see relaying), but cannot support "getblocks" as it does not have the entire blockchain. 133 | 134 | == Backwards Compatibility == 135 | 136 | This proposal is an addon to the current Bitcoin network, and is completely backwards compatible. 137 | -------------------------------------------------------------------------------- /bip-0017.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 17
  3 |   Title: OP_CHECKHASHVERIFY (CHV)
  4 |   Author: Luke Dashjr 
  5 |   Status: Withdrawn
  6 |   Type: Standards Track
  7 |   Created: 2012-01-18
  8 |
9 | 10 | ==Abstract== 11 | 12 | This BIP describes a new opcode (OP_CHECKHASHVERIFY) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. 13 | 14 | ==Motivation== 15 | 16 | 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. 17 | 18 | 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. 19 | 20 | ==Specification== 21 | 22 | OP_CHECKHASHVERIFY will re-define the existing OP_NOP2 opcode, and will function as follows when executed: 23 | 24 | * First, hash the end of the prior script (in the general case, scriptSig; if no prior script, a null string is hashed) beginning from the last evaluated OP_CODESEPARATOR onward (or from the beginning of the script, if no OP_CODESEPARATOR was present) 25 | * Then, compare this with the item on the top of the stack (if there is none, the script fails immediately) 26 | * If the hashes match, do nothing, proceed as if an OP_NOP; if they do not match, the script fails immediately. 27 | * Note that in the case of a matched hash, the top stack item (the hash being compared with) is not popped off the stack. This is for backward compatibility. 28 | 29 | This opcode reassignment shall be applied when validating transactions in blocks only with timestamps after February 23, 2012 (see the Backwards Compatibility section for details). 30 | 31 | A new standard transaction type that is relayed and included in mined blocks is defined: 32 | 33 | [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP 34 | 35 | [20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes. 36 | 37 | This new transaction type is redeemed by a standard scriptSig: 38 | 39 | ...signatures... OP_CODESEPARATOR {script} 40 | 41 | Transactions that redeem these pay-to-script outpoints are only considered standard if they contain exactly one OP_CODESEPARATOR and the appended ''script'' is, itself, one of the other standard transaction types. 42 | 43 | ==Example== 44 | 45 | For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: 46 | 47 | scriptSig: [signature] OP_CODESEPARATOR [pubkey] OP_CHECKSIG 48 | scriptPubKey: [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_CHECKHASHVERIFY OP_DROP 49 | 50 | 2-of-3: 51 | 52 | scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG 53 | scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP 54 | 55 | ==Rationale== 56 | 57 | This BIP replaces BIP 12 and BIP 16, which propose evaluating a Script from the stack after verifying its hash. 58 | 59 | 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. 60 | 61 | There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is: 62 | 63 | # 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. 64 | # Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software. 65 | # Attacker mines a block that contains both transactions. 66 | 67 | 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. 68 | 69 | 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. 70 | 71 | ==Backwards Compatibility== 72 | 73 | These transactions are non-standard to old implementations, which will (typically) not relay them nor include them in blocks. 74 | 75 | Old implementations will not validate that the {script}'s hash value matches when they validate blocks created by software that fully support this BIP. 76 | 77 | Avoiding a block-chain split by malicious pay-to-script transactions requires careful handling of one case: 78 | 79 | * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners. 80 | 81 | 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. 82 | 83 | To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create. 84 | 85 | On February 8, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If at least 60% contain "p2sh/CHV" in their coinbase, then all blocks with timestamps after 23 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions validated. 86 | 87 | 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). 88 | 89 | OP_NOP2 is used, so existing OP_EVAL (BIP 12) transactions in the block chain can still be redeemed. 90 | 91 | ==Reference Implementation== 92 | 93 | [https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify Validation, sending, and receiving for bitcoind git master] 94 | 95 | [https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/checkhashverify_backport Validation only for 0.3.19+] 96 | 97 | ==See Also== 98 | 99 | * The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] 100 | * [[bip-0011.mediawiki|M-of-N Multisignature Transactions (BIP 11)]] 101 | * Example BIP 17 transaction chain: [http://blockexplorer.com/tx/b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d a] [http://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb b] [http://blockexplorer.com/tx/055707ce7fea7b9776fdc70413f65ceec413d46344424ab01acd5138767db137 c] [http://blockexplorer.com/tx/6d36bc17e947ce00bb6f12f8e7a56a1585c5a36188ffa2b05e10b4743273a74b d] 102 | -------------------------------------------------------------------------------- /bip-0021.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP: 21
  3 |   Title: URI Scheme
  4 |   Author: Nils Schneider 
  5 |           Matt Corallo 
  6 |   Status: Accepted
  7 |   Type: Standards Track
  8 |   Created: 2012-01-29
  9 |
10 | 11 | This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. 12 | 13 | ==Abstract== 14 | This BIP proposes a URI scheme for making Bitcoin payments. 15 | 16 | ==Motivation== 17 | The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. 18 | 19 | ==Specification== 20 | 21 | === General rules for handling (important!) === 22 | 23 | Bitcoin clients MUST NOT act on URIs without getting the user's authorization. 24 | 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. 25 | 26 | === Operating system integration === 27 | 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. 28 | 29 | === General Format === 30 | 31 | 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. 32 | 33 | 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. 34 | 35 | === ABNF grammar === 36 | 37 | (See also [[#Simpler syntax|a simpler representation of syntax]]) 38 | 39 | bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] 40 | bitcoinaddress = *base58 41 | bitcoinparams = bitcoinparam [ "&" bitcoinparams ] 42 | bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ] 43 | amountparam = "amount=" *digit [ "." *digit ] 44 | labelparam = "label=" *qchar 45 | messageparam = "message=" *qchar 46 | otherparam = qchar *qchar [ "=" *qchar ] 47 | reqparam = "req-" qchar *qchar [ "=" *qchar ] 48 | 49 | Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this BIP takes as separators. 50 | 51 | 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. 52 | 53 | === Query Keys === 54 | 55 | *label: Label for that address (e.g. name of receiver) 56 | *address: bitcoin address 57 | *message: message that describes the transaction to the user ([[#Examples|see examples below]]) 58 | *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) 59 | *paycode: payment code (BIP-47) 60 | *(others): optional, for future extensions 61 | 62 | ==== Transfer amount/size ==== 63 | 64 | If an amount is provided, it MUST be specified in decimal BTC. 65 | All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions. 66 | I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid. 67 | 68 | Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. 69 | They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. 70 | 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. 71 | 72 | ==== Payment code ==== 73 | 74 | If a URI provides a payment code, and if the client supports BIP-47, then the resulting transaction SHOULD construct a transaction per BIP-47 instead of using the address provided in the URI. 75 | 76 | == Rationale == 77 | 78 | ===Payment identifiers, not person identifiers=== 79 | Current best practices are that a unique address should be used for every transaction. 80 | Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment. 81 | 82 | ===Accessibility (URI scheme name)=== 83 | Should someone from the outside happen to see such a URI, the URI scheme name already gives a description. 84 | A quick search should then do the rest to help them find the resources needed to make their payment. 85 | Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer. 86 | Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin. 87 | 88 | ==Forward compatibility== 89 | 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. 90 | 91 | ==Backward compatibility== 92 | 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. 93 | 94 | == Appendix == 95 | 96 | === Simpler syntax === 97 | 98 | This section is non-normative and does not cover all possible syntax. 99 | Please see the BNF grammar above for the normative syntax. 100 | 101 | [foo] means optional, <bar> are placeholders 102 | 103 | bitcoin:
[?amount=][?label=