├── bip-0073 ├── a.png └── b.png ├── bip-0001 └── process.png ├── bip-0032 └── derivation.png ├── bip-0070 └── Protocol_Sequence.png ├── bip-0071.mediawiki ├── bip-0035.mediawiki ├── bip-0034.mediawiki ├── bip-0072.mediawiki ├── bip-0031.mediawiki ├── bip-0013.mediawiki ├── bip-0019.mediawiki ├── bip-0030.mediawiki ├── bip-0073.mediawiki ├── bip-0011.mediawiki ├── bip-0060.mediawiki ├── bip-0039.mediawiki ├── README.mediawiki ├── bip-0012.mediawiki ├── bip-0021.mediawiki ├── bip-0050.mediawiki ├── bip-0014.mediawiki ├── bip-0033.mediawiki ├── bip-0017.mediawiki ├── bip-0016.mediawiki ├── bip-0018.mediawiki ├── bip-0010.mediawiki ├── bip-0016 └── qa.mediawiki ├── bip-0020.mediawiki ├── bip-0036.mediawiki ├── bip-0022.mediawiki ├── bip-0070.mediawiki ├── bip-0023.mediawiki ├── bip-0001.mediawiki └── bip-0037.mediawiki /bip-0073/a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jeffbr13/bips/master/bip-0073/a.png -------------------------------------------------------------------------------- /bip-0073/b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jeffbr13/bips/master/bip-0073/b.png -------------------------------------------------------------------------------- /bip-0001/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jeffbr13/bips/master/bip-0001/process.png -------------------------------------------------------------------------------- /bip-0032/derivation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jeffbr13/bips/master/bip-0032/derivation.png -------------------------------------------------------------------------------- /bip-0070/Protocol_Sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jeffbr13/bips/master/bip-0070/Protocol_Sequence.png -------------------------------------------------------------------------------- /bip-0071.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 71
 3 |   Title: Payment Protocol MIME types
 4 |   Author: Gavin Andresen 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 29-07-2013
 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 | -------------------------------------------------------------------------------- /bip-0072.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 72
 3 |   Title: bitcoin: uri extensions for Payment Protocol
 4 |   Author: Gavin Andresen 
 5 |   Status: Draft
 6 |   Type: Standards Track
 7 |   Created: 29-07-2013
 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 (unsafe and reserved octets in the URL value 26 | must be encoded as described in RFC 1738). 27 | 28 | If the "r" parameter is provided and backwards compatibility 29 | is not required, then the bitcoin address portion of the URI may be 30 | omitted (the URI will be of the form: bitcoin:?r=... ). 31 | 32 | When Bitcoin wallet software that supports this BIP receives a 33 | bitcoin: URI with a request parameter, it should ignore the bitcoin 34 | address/amount/label/message in the URI and instead fetch a 35 | PaymentRequest message and then follow the payment protocol, as 36 | described in BIP 70. 37 | 38 | Bitcoin wallets must support fetching PaymentRequests via http and 39 | https protocols; they may support other protocols. Wallets must 40 | include an Accept HTTP header in HTTP(s) requests: 41 | 
Accept: application/bitcoin-paymentrequest
42 | 43 | If a PaymentRequest cannot be obtained (perhaps the server is 44 | unavailable), then the customer should be informed that the merchant's 45 | payment processing system is unavailable. 46 | 47 | ==Compatibility== 48 | 49 | Wallet software that does not support this BIP will simply ignore the 50 | r parameter and will initiate a payment to bitcoin address. 51 | 52 | ==Examples== 53 | A backwards-compatible request: 54 | 
55 | bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
56 |
57 | Non-backwards-compatible equivalent: 58 | 
59 | bitcoin:?r=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
60 |
61 | -------------------------------------------------------------------------------- /bip-0031.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 31
 3 |   Title: Pong message
 4 |   Author: Mike Hearn 
 5 |   Status: Accepted
 6 |   Type: Standards Track
 7 |   Created: 11-04-2012
 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-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: 18-10-2011
 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 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-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: 30-01-2012
 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: 22-02-2012
 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 is to be applied to all blocks whose timestamp is after a point in time that is yet to be decided. 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-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: 27-08-2013
 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: 18-10-2011
 8 |   Post-History: 02-10-2011
 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-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: 16-06-2013
 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-0039.mediawiki: -------------------------------------------------------------------------------- 1 | 
  2 |   BIP:     BIP-0039
  3 |   Title:   Mnemonic code for generating deterministic keys
  4 |   Authors: Marek Palatinus 
  5 |            Pavol Rusnak 
  6 |            ThomasV 
  7 |            Aaron Voisine 
  8 |   Status:  Draft
  9 |   Type:    Standards Track
 10 |   Created: 10-09-2013
 11 |
12 | 13 | ==Abstract== 14 | 15 | This BIP describes an usage of mnemonic code or mnemonic sentence - a group of 16 | easy to remember words - to generate deterministic wallets. 17 | 18 | It consists of two parts: generating the mnemonic and converting it into 19 | a binary seed. This seed can be later used to generate deterministic wallets 20 | using BIP-0032 or similar methods. 21 | 22 | ==Motivation== 23 | 24 | Such mnemonic code or mnemonic sentence is much easier to work with than working 25 | with the binary data directly (or its hexadecimal interpretation). The sentence 26 | could be writen down on paper (e.g. for storing in a secure location such as 27 | safe), told over telephone or other voice communication method, or memorized 28 | in ones memory (this method is called brainwallet). 29 | 30 | ==Generating the mnemonic== 31 | 32 | First, we decide how much entropy we want mnemonic to encode. Recommended size 33 | is 128-256 bits, but basically any multiple of 32 bits will do. More bits 34 | mean more security, but also longer word sentence. 35 | 36 | We take initial entropy of ENT bits and compute its checksum by taking first 37 | ENT / 32 bits of its SHA256 hash. We append these bits to the end of the initial 38 | entropy. Next we take these concatenated bits and split them into groups of 11 39 | bits. Each group encodes number from 0-2047 which is a position in a wordlist. 40 | We convert numbers into words and use joined words as mnemonic sentence. 41 | 42 | The following table describes the relation between initial entropy length (ENT), 43 | checksum length (CS) and length of the generated mnemonic sentence (MS) in words. 44 | 45 | 
 46 | CS = ENT / 32
 47 | MS = (ENT + CS) / 11
 48 | 
 49 | |  ENT  | CS | ENT+CS |  MS  |
 50 | +-------+----+--------+------+
 51 | |  128  |  4 |   132  |  12  |
 52 | |  160  |  5 |   165  |  15  |
 53 | |  192  |  6 |   198  |  18  |
 54 | |  224  |  7 |   231  |  21  |
 55 | |  256  |  8 |   264  |  24  |
 56 |
57 | 58 | ==Wordlist== 59 | 60 | In previous section we described how to pick words from a wordlist. Now we 61 | describe how does a good wordlist look like. 62 | 63 | a) smart selection of words 64 | - wordlist is created in such way that it's enough to type just first four 65 | letters to unambiguously identify the word 66 | 67 | b) similar words avoided 68 | - words as "build" and "built", "woman" and "women" or "quick" or "quickly" 69 | not only make remembering the sentence difficult, but are also more error 70 | prone and more difficult to guess (see point below) 71 | - we avoid these words by carefully selecting them during addition 72 | 73 | c) sorted wordlists 74 | - wordlist is sorted which allow more efficient lookup of the code words 75 | (i.e. implementation can use binary search instead of linear search) 76 | - this also allows trie (prefix tree) to be used, e.g. for better compression 77 | 78 | Wordlist can contain native characters, but they have to be encoded using UTF-8. 79 | 80 | ==From mnemonic to seed== 81 | 82 | User can decide to protect his mnemonic by passphrase. If passphrase is not present 83 | an empty string "" is used instead. 84 | 85 | To create binary seed from mnemonic, we use PBKDF2 function with mnemonic sentence 86 | (in UTF-8) used as a password and string "mnemonic" + passphrase (again in UTF-8) 87 | used as a salt. Iteration count is set to 4096 and HMAC-SHA512 is used as a pseudo- 88 | random function. Desired length of the derived key is 512 bits (= 64 bytes). 89 | 90 | This seed can be later used to generate deterministic wallets using BIP-0032 or 91 | similar methods. 92 | 93 | The conversion of the mnemonic sentence to binary seed is completely independent 94 | from generating the sentence. This results in rather simple code, there are no 95 | constraints on sentence structure and clients are free to implement their own 96 | wordlists or even whole sentence generators (they'll lose the proposed method 97 | for typo detection in that case, but they can come up with their own). 98 | 99 | Described method also provides plausable deniability, because every passphrase 100 | generates a valid seed (and thus deterministic wallet) but only the correct one 101 | will make the desired wallet available. 102 | 103 | ==Test vectors== 104 | 105 | See https://github.com/trezor/python-mnemonic/blob/master/vectors.json 106 | 107 | ==Reference Implementation== 108 | 109 | Reference implementation including wordlists is available from 110 | 111 | http://github.com/trezor/python-mnemonic 112 | 113 | -------------------------------------------------------------------------------- /README.mediawiki: -------------------------------------------------------------------------------- 1 | People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. 2 | 3 | We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. 4 | 5 | Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community. 6 | 7 | Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority]). 8 | 9 | {| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" 10 | !Number 11 | !Title 12 | !Owner 13 | !Status 14 | |- style="background-color: #cfffcf" 15 | | [[bip-0001.mediawiki|1]] 16 | | BIP Purpose and Guidelines 17 | | Amir Taaki 18 | | Active 19 | |- 20 | | [[bip-0010.mediawiki|10]] 21 | | Multi-Sig Transaction Distribution 22 | | Alan Reiner 23 | | Draft 24 | |- style="background-color: #cfffcf" 25 | | [[bip-0011.mediawiki|11]] 26 | | M-of-N Standard Transactions 27 | | Gavin Andresen 28 | | Accepted 29 | |- style="background-color: #ffcfcf" 30 | | [[bip-0012.mediawiki|12]] 31 | | OP_EVAL 32 | | Gavin Andresen 33 | | Withdrawn 34 | |- style="background-color: #cfffcf" 35 | | [[bip-0013.mediawiki|13]] 36 | | Address Format for pay-to-script-hash 37 | | Gavin Andresen 38 | | Final 39 | |- style="background-color: #cfffcf" 40 | | [[bip-0014.mediawiki|14]] 41 | | Protocol Version and User Agent 42 | | Amir Taaki, Patrick Strateman 43 | | Accepted 44 | |- style="background-color: #ffcfcf" 45 | | [[bip-0015.mediawiki|15]] 46 | | Aliases 47 | | Amir Taaki 48 | | Withdrawn 49 | |- style="background-color: #cfffcf" 50 | | [[bip-0016.mediawiki|16]] 51 | | Pay To Script Hash 52 | | Gavin Andresen 53 | | Accepted 54 | |- style="background-color: #ffcfcf" 55 | | [[bip-0017.mediawiki|17]] 56 | | OP_CHECKHASHVERIFY (CHV) 57 | | Luke Dashjr 58 | | Withdrawn 59 | |- 60 | | [[bip-0018.mediawiki|18]] 61 | | hashScriptCheck 62 | | Luke Dashjr 63 | | Draft 64 | |- 65 | | [[bip-0019.mediawiki|19]] 66 | | M-of-N Standard Transactions (Low SigOp) 67 | | Luke Dashjr 68 | | Draft 69 | |- style="background-color: #ffcfcf" 70 | | [[bip-0020.mediawiki|20]] 71 | | URI Scheme 72 | | Luke Dashjr 73 | | Replaced 74 | |- style="background-color: #cfffcf" 75 | | [[bip-0021.mediawiki|21]] 76 | | URI Scheme 77 | | Nils Schneider, Matt Corallo 78 | | Accepted 79 | |- style="background-color: #cfffcf" 80 | | [[bip-0022.mediawiki|22]] 81 | | getblocktemplate - Fundamentals 82 | | Luke Dashjr 83 | | Accepted 84 | |- style="background-color: #cfffcf" 85 | | [[bip-0023.mediawiki|23]] 86 | | getblocktemplate - Pooled Mining 87 | | Luke Dashjr 88 | | Accepted 89 | |- style="background-color: #cfffcf" 90 | | [[bip-0030.mediawiki|30]] 91 | | Duplicate transactions 92 | | Pieter Wuille 93 | | Accepted 94 | |- style="background-color: #cfffcf" 95 | | [[bip-0031.mediawiki|31]] 96 | | Pong message 97 | | Mike Hearn 98 | | Accepted 99 | |- style="background-color: #cfffcf" 100 | | [[bip-0032.mediawiki|32]] 101 | | Hierarchical Deterministic Wallets 102 | | Pieter Wuille 103 | | Accepted 104 | |- 105 | | [[bip-0033.mediawiki|33]] 106 | | Stratized Nodes 107 | | Amir Taaki 108 | | Draft 109 | |- style="background-color: #cfffcf" 110 | | [[bip-0034.mediawiki|34]] 111 | | Block v2, Height in coinbase 112 | | Gavin Andresen 113 | | Accepted 114 | |- style="background-color: #cfffcf" 115 | | [[bip-0035.mediawiki|35]] 116 | | mempool message 117 | | Jeff Garzik 118 | | Accepted 119 | |- 120 | | [[bip-0036.mediawiki|36]] 121 | | Custom Services 122 | | Stefan Thomas 123 | | Draft 124 | |- style="background-color: #cfffcf" 125 | | [[bip-0037.mediawiki|37]] 126 | | Bloom filtering 127 | | Mike Hearn and Matt Corallo 128 | | Accepted 129 | |- 130 | | [[bip-0038.mediawiki|38]] 131 | | Passphrase-protected private key 132 | | Mike Caldwell 133 | | Draft 134 | |- 135 | | [[bip-0039.mediawiki|39]] 136 | | Mnemonic code for generating deterministic keys 137 | | Slush 138 | | Draft 139 | |- 140 | | 40 141 | | Stratum wire protocol 142 | | Slush 143 | | BIP number allocated 144 | |- 145 | | 41 146 | | Stratum mining protocol 147 | | Slush 148 | | BIP number allocated 149 | 150 | |- 151 | | [[bip-0050.mediawiki|50]] 152 | | March 2013 Chain Fork Post-Mortem 153 | | Gavin Andresen 154 | | Draft 155 | 156 | |- 157 | | [[bip-0060.mediawiki|60]] 158 | | Fixed Length "version" Message (Relay-Transactions Field) 159 | | Amir Taaki 160 | | Draft 161 | |- 162 | | [[bip-0070.mediawiki|70]] 163 | | Payment protocol 164 | | Gavin Andresen 165 | | Draft 166 | |- 167 | | [[bip-0071.mediawiki|71]] 168 | | Payment protocol MIME types 169 | | Gavin Andresen 170 | | Draft 171 | |- 172 | | [[bip-0072.mediawiki|72]] 173 | | Payment protocol URIs 174 | | Gavin Andresen 175 | | Draft 176 | |- 177 | | [[bip-0073.mediawiki|73]] 178 | | Use "Accept" header with Payment Request URLs 179 | | Stephen Pair 180 | | Draft 181 | |} 182 | 183 | 184 | -------------------------------------------------------------------------------- /bip-0012.mediawiki: -------------------------------------------------------------------------------- 1 | 
 2 |   BIP: 12
 3 |   Title: OP_EVAL
 4 |   Author: Gavin Andresen 
 5 |   Status: Withdrawn
 6 |   Type: Standards Track
 7 |   Created: 18-10-2011
 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-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: 29-01-2012
  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 | === BNF grammar === 30 | 31 | (See also [[#Simpler syntax|a simpler representation of syntax]]) 32 | 33 | bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] 34 | bitcoinaddress = base58 *base58 35 | bitcoinparams = *bitcoinparam 36 | bitcoinparam = amountparam | labelparam | messageparam | otherparam | reqparam 37 | amountparam = "amount=" *digit [ "." *digit ] 38 | labelparam = "label=" *pchar 39 | messageparam = "message=" *pchar 40 | otherparam = pchar *pchar "=" *pchar 41 | reqparam = "req-" pchar *pchar "=" *pchar 42 | 43 | === Query Keys === 44 | 45 | *label: Label for that address (e.g. name of receiver) 46 | *address: bitcoin address 47 | *message: message that describes the transaction to the user ([[#Examples|see examples below]]) 48 | *size: amount of base bitcoin units ([[#Transfer amount/size|see below]]) 49 | *(others): optional, for future extensions 50 | 51 | ==== Transfer amount/size ==== 52 | 53 | If an amount is provided, it MUST be specified in decimal BTC. 54 | All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions. 55 | I.e. amount=50.00 or amount=50 is treated as 50 BTC, and amount=50,000.00 is invalid. 56 | 57 | Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. 58 | They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. 59 | 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. 60 | == Rationale == 61 | 62 | ===Payment identifiers, not person identifiers=== 63 | Current best practices are that a unique address should be used for every transaction. 64 | Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment. 65 | 66 | ===Accessibility (URI scheme name)=== 67 | Should someone from the outside happen to see such a URI, the URI scheme name already gives a description. 68 | A quick search should then do the rest to help them find the resources needed to make their payment. 69 | Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer. 70 | Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin. 71 | 72 | ==Forward compatibility== 73 | 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. 74 | 75 | ==Backward compatibility== 76 | 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. 77 | 78 | == Appendix == 79 | 80 | === Simpler syntax === 81 | 82 | This section is non-normative and does not cover all possible syntax. 83 | Please see the BNF grammar above for the normative syntax. 84 | 85 | [foo] means optional, <bar> are placeholders 86 | 87 | bitcoin:
[?amount=][?label=