diff options
| -rw-r--r-- | README.mediawiki | 24 | ||||
| -rw-r--r-- | bip-0062.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0066.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0067.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0101.mediawiki | 126 | ||||
| -rw-r--r-- | bip-0105.mediawiki | 100 | ||||
| -rw-r--r-- | bip-0111.mediawiki | 85 | ||||
| -rw-r--r-- | bip-0120.mediawiki | 152 | ||||
| -rw-r--r-- | bip-0121.mediawiki | 146 |
9 files changed, 637 insertions, 4 deletions
diff --git a/README.mediawiki b/README.mediawiki index ac27ba8..1480b6f 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -289,6 +289,30 @@ Those proposing changes should consider that ultimately consent may rest with th | Stephen Pair | Standard | Draft +|- +| [[bip-0101.mediawiki|101]] +| Increase maximum block size +| Gavin Andresen +| Standard +| Draft +|- +| [[bip-0111.mediawiki|111]] +| NODE_BLOOM service bit +| Matt Corallo and Peter Todd +| Standard +| Draft +|- +| [[bip-0120.mediawiki|120]] +| Proof of Payment +| Kalle Rosenbaum +| Standard +| Draft +|- +| [[bip-0121.mediawiki|121]] +| Proof of Payment URI scheme +| Kalle Rosenbaum +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 4846abf..feb4d58 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to delibrately create an invalid signature for with OP_CHECKSIG and OP_CHECKMULTISIG the empty byte array (the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for OP_CHECKSIG and OP_CHECKMULTISIG, an empty byte array (i.e., the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. # '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index 41cbd8f..1235afd 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -2,7 +2,7 @@ BIP: 66 Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> - Status: Draft + Status: Final Type: Standards Track Created: 2015-01-10 </pre> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 9c4f3de..8be5c9b 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -4,8 +4,8 @@ Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft - Type: Standard - Created: 8 February 2015 + Type: Standards Track + Created: 2015-02-08 </pre> ==Abstract== diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki new file mode 100644 index 0000000..a76db0f --- /dev/null +++ b/bip-0101.mediawiki @@ -0,0 +1,126 @@ +<pre> + BIP: 101 + Title: Increase maximum block size + Author: Gavin Andresen <gavinandresen@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-06-22 +</pre> + +==Abstract== + +This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. + +==Motivation== + +Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth. + +==Specification== + +After deployment (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header. + +The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes. + +Expressed in pseudo-code, using integer math, assuming that block_timestamp is after the activation time (as described in the Deployment section below): + + function max_block_size(block_timestamp): + + time_start = 1452470400 + time_double = 60*60*24*365*2 + size_start = 8000000 + if block_timestamp >= time_start+time_double*10 + return size_start * 2^10 + + // Piecewise-linear-between-doublings growth: + time_delta = block_timestamp - time_start + doublings = time_delta / time_double + remainder = time_delta % time_double + interpolate = (size_start * 2^doublings * remainder) / time_double + max_size = size_start * 2^doublings + interpolate + + return max_size + +==Deployment== + +Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC. + +Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. + +Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block. + +==Test network== + +Test network parameters are the same as the main network, except starting earlier with easier supermajority conditions and a shorter grace period: + + starting time: 1 Aug 2015 (timestamp 1438387200) + activation condition: 75 of 100 blocks + grace period: 24 hours + +==Rationale== + +The initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners on bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China). + +The doubling interval was chosen based on long-term growth trends for CPU power, storage, and Internet bandwidth. The 20-year limit was chosen because exponential growth cannot continue forever. If long-term trends do not continue, maximum block sizes can be reduced by miner consensus (a soft-fork). + +Calculations are based on timestamps and not blockchain height because a timestamp is part of every block's header. This allows implementations to know a block's maximum size after they have downloaded it's header, but before downloading any transactions. + +The deployment plan is taken from Jeff Garzik's proposed BIP100 block size increase, and is designed to give miners, merchants, and full-node-running-end-users sufficient time to upgrade to software that supports bigger blocks. A 75% supermajority was chosen so that one large mining pool does not have effective veto power over a blocksize increase. The version number scheme is designed to be compatible with Pieter's Wuille's proposed "Version bits" BIP, and to not interfere with any other consensus rule changes in the process of being rolled out. + +==Objections to this proposal== + +Raising the 1MB block size has been [https://www.google.com/webhp?#q=1mb+limit+site%3Abitcointalk.org discussed and debated for years]. + +===Centralization of full nodes=== + +The number of fully-validating nodes reachable on the network has been steadily declining. Increasing the capacity of the network to handle transactions by increasing the maximum block size may accelerate that decline, meaning a less distributed network that is more vulnerable to disruption. The size of this effect is debatable; the author of this BIP believes that the decline in fully validating nodes on the network is largely due to the availability of convenient, attractive, secure, lightweight wallet software and the general trend away from computing on desktop computers to mobile phones and tablets. + +Increasing the capacity of the network to handle transactions should enable increased adoption by users and businesses, especially in areas of the world where existing financial infrastructure is weak. That could lead to a more robust network with nodes running in more political jurisdictions. + +===Centralization of mining: costs=== + +Miners benefit from low-latency, high-bandwidth connections because they increase their chances of winning a "block race" (two or more blocks found at approximately the same time). With the current peer-to-peer networking protocol, announcing larger blocks requires more bandwidth. If the costs grow high enough, the result will be a very small number of very large miners. + +The limits proposed by this BIP are designed so that running a fully validating node has very modest costs, which, if current trends in the cost of technology continue, will become even less expensive over time. + +===Centralization of mining: big-block attacks=== + +[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of miners with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/ ). + +If latency and bandwidth to other miners were the only variable that affected the profitability of mining, and miners were driven purely by profit, the end result would be one miner running on one machine, where latency was zero and bandwidth was essentially infinite. + +However, many other factors influence miner profitability, including cost of electricity and labor and real estate, ability to use waste heat productively, access to capital to invest in mining equipment, etc. Increasing the influence of bandwidth in the mining profitability equation will not necessarily lead to more centralization. + +===Unspent Transaction Output Growth=== + +This BIP makes no attempt to restrict the approximately 100% per-year growth in unspent transaction outputs (see http://gavinandresen.ninja/utxo-uhoh for details), because the author believe that problem should be solved by a further restriction on blocks described in a separate BIP (perhaps an additional limit on how much the transactions in any block may increase the UTXO set size). + +==Long-term fee incentives== + +http://gavinandresen.ninja/block-size-and-miner-fees-again + +==Other solutions considered== + +There have been dozens of proposals for increasing the block size over the years. Some notable ideas: + +===One-time increase=== + +A small, quick one-time increase to, for example, 2MB blocks, would be the most conservative option. + +However, a one-time increase requires just as much care in testing and deployment as a longer-term fix. And the entire debate over how large or small a limit is appropriate would be repeated as soon as the new limit was reached. + +===Dynamic limit proposals=== + +BIP 100 proposes a dynamic limit determined by miner preferences expressed in coinbase transactions, with limits on the rate of growth. It gives miners more direct control over the maximum block size, which some people see as an advantage over this proposal and some see as a disadvantage. It is more complex to implement, because the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched out-of-order in a 'headers-first' mode). + +[https://bitcointalk.org/index.php?topic=1078521.0 Meni Rosenfeld has proposed] that miners sacrifice mining reward to "pay for" bigger blocks, so there is an incentive to create bigger blocks only if transaction fees cover the cost of creating a larger block. This proposal is significantly more complex to implement, and it is not clear if a set of parameters for setting the cost of making a block bigger can be found that is not equivalent to a centrally-controlled network-wide minimum transaction fee. + +==Compatibility== + +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. + +Simplified Payment Verification software is not affected, unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size. + +==Implementation== + +https://github.com/bitcoin/bitcoin/pull/6341 + diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki new file mode 100644 index 0000000..7aaef04 --- /dev/null +++ b/bip-0105.mediawiki @@ -0,0 +1,100 @@ +<pre> + BIP: 105 + Title: Consensus based block size retargeting algorithm + Author: BtcDrak <btcdrak@gmail.com> + Status: Draft + Type: Standards Track + Created: 2015-08-21 +</pre> + +==Abstract== + +A method of altering the maximum allowed block size of the Bitcoin protocol +using a consensus based approach. + +==Motivation== + +There is a belief that Bitcoin cannot easily respond to raising the +blocksize limit if popularity was to suddenly increase due to a mass adoption +curve, because co-ordinating a hard fork takes considerable time, and being +unable to respond in a timely manner would irreparably harm the credibility of +bitcoin. + +Additionally, predetermined block size increases are problematic because they +attempt to predict the future, and if too large could have unintended +consequences like damaging the possibility for a fee market to develop +as block subsidy decreases substantially over the next 9 years; introducing +or exacerbating mining attack vectors; or somehow affect the network in unknown +or unpredicted ways. Since fixed changes are hard to deploy, the damage could be +extensive. + +Dynamic block size adjustments also suffer from the potential to be gamed by the +larger hash power. + +Free voting as suggested by BIP100 allows miners to sell their votes out of band +at no risk, and enable the sponsor the ability to manipulate the blocksize. +It also provides a cost free method or the larger pools to vote in ways to +manipulate the blocksize such to disadvantage or attack smaller pools. + + +==Rationale== + +By introducing a cost to increase the block size ensures the mining community +will collude to increase it only when there is a clear necessity, and reduce it +when it is unnecessary. Larger miners cannot force their wishes so easily +because not only will they have to pay extra a difficulty target, then can be +downvoted at no cost by the objecting hash power. + +Using difficulty as a penalty is better than a fixed cost in bitcoins because it +is less predictable. + +In order to prevent miners having complete control over blocksize, an upper +limit is required at protocol level. This feature ensures full nodes retain +control over consensus, remembering full nodes are the mechanism to keep miners +honest. + + +==Specification== + +The initial block size limit shall be 1MB. + +Each time a miner creates a block, they may vote to increase or decrease the +blocksize by a maximum of 10% of the current block size limit. These votes will +be used to recalculate the new block size limit every 2016 blocks. + +Votes are cast using the block's coinbase field. + +The first 4 bytes of the coinbase field shall be repurposed for voting as an +unsigned long integer which will be the block size in bytes. + +If a miner votes for an increase, the block hash must meet a difficulty target +which is proportionally larger than the standard difficulty target based on the +percentage increase they voted for. + +Votes proposing decreasing the block size limit do not need to meet a higher +difficulty target. + +Miners can vote for no change by voting for the current block size. + +For blocks to be valid the blockhash must meet the required difficulty target +for the vote otherwise the block is invalid and will be rejected. + +Every 2016 blocks, the block size limit will be recalculated by the median of +all votes in the last 2016 blocks. This will redefine the block size limit for +the next 2016 blocks. + +Blocks that are larger than the calculated base block size limit are invalid and +will be rejected. + +The base block size limit may not reduce below 1MB or increase above 8MB. + + +==Acknowledgements== + +This proposal is based on ideas and concepts derived from the writings of +Meni Rosenfeld and Gregory Maxwell. + + +==Copyright== + +This work is placed in the public domain. diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki new file mode 100644 index 0000000..d3bd630 --- /dev/null +++ b/bip-0111.mediawiki @@ -0,0 +1,85 @@ +<pre> + BIP: 111 + Title: NODE_BLOOM service bit + Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-08-20 +</pre> + +== Abstract == + +This BIP extends BIP 37, Connection Bloom filtering, by defining a +service bit to allow peers to advertise that they support bloom filters +explicitly. It also bumps the protocol version to allow peers to +identify old nodes which allow bloom filtering of the connection despite +lacking the new service bit. + + +== Motivation == + +BIP 37 did not specify a service bit for the bloom filter service, thus +implicitly assuming that all nodes that serve peers data support it. +However, the connection filtering algorithm proposed in BIP 37, and +implemented in several clients today, has been shown to provide little +to no privacy<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[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.</ref>. +Thus, allowing node operators to disable connection bloom filtering is a +much-needed feature. + + +== Specification == + +The following protocol bit is added: + +<pre> + NODE_BLOOM = (1 << 2) +</pre> + +Nodes which support bloom filters should set that protocol bit. +Otherwise it should remain unset. In addition the protocol version is +increased from 70002 to 70011 in the reference implementation. It is +often the case that nodes which have a protocol version smaller than +70011, but larger than 70000 support bloom filtered connections without +the NODE_BLOOM bit set, however clients which require bloom filtered +connections should avoid making this assumption. + +NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise +NODE_BLOOM but not NODE_NETWORK (though there is little reason to do +so now, some proposals may make this more useful in the future) + +If a node does not support bloom filters but receives a "filterload", +"filteradd", or "filterclear" message from a peer the node should +disconnect that peer immediately. For backwards compatibility, in +initial implementations, nodes may choose to only disconnect nodes which +have the new protocol version set and attempt to send a filter command. + +While outside the scope of this BIP it is suggested that DNS seeds and +other peer discovery mechanisms support the ability to specify the +services required; current implementations simply check only that +NODE_NETWORK is set. + + +== Design rational == + +A service bit was chosen as applying a bloom filter is a service. + +The increase in protocol version is for backwards compatibility. In +initial implementations, old nodes which are not yet aware of NODE_BLOOM +and use a protocol version < 70011 may still send filter messages to a +node without NODE_BLOOM. This feature may be removed after there are +sufficient NODE_BLOOM nodes available and SPV clients have upgraded, +allowing node operators to fully close the bloom-related DoS vectors. + + +== Reference Implementation == + +https://github.com/bitcoin/bitcoin/pull/6579 + + +== Copyright == + +This document is placed in the public domain. + + +== References == +<references> diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki new file mode 100644 index 0000000..e099f5b --- /dev/null +++ b/bip-0120.mediawiki @@ -0,0 +1,152 @@ +<pre> + BIP: 120 + Title: Proof of Payment + Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Status: Draft + Type: Standards Track + Created: 2015-07-28 +</pre> + +== Abstract == + +This BIP describes a system called Proof of Payment, PoP. It is used to prove that a wallet has the credentials that were used to sign a previously generated transaction. Or simply put, it lets you prove that you have made a payment. + +== Motivation == + +There are several scenarios in which it would be useful to prove that you have paid for something. For example: + +* A pre-paid hotel room where your PoP functions as a key to the door. +* An online video rental service where you pay for a video and watch it on any device. +* An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. +* Log in to a pay site using a PoP. +* A parking lot you pay for monthly and the car authenticates itself using PoP. +* A lottery where all participants pay to the same address, and the winner is selected among the transactions to that address. You exchange the prize for a PoP for the winning transaction. + +With Proof of Payment, these use cases can be achieved without any personal information (user name, password, e-mail address, etc) being involved. + +== Rationale == + +Desirable properties: + +# A PoP should be generated on demand. +# It should only be usable once to avoid issues due to theft. +# It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). +# It should prove that you have enough credentials to unlock all the inputs of the proven transaction. +# It should be easy to implement by wallets and servers to ease adoption. + +Current methods of proving a payment: + +* In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5. +* Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so. + +If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not neccesarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address. + +== Specification == + +=== Data structure === + +A proof of payment for a transaction T, here called PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and in the same order as in T, but with each sequence number set to 0. There is exactly one output, here called the pop output, with value 0. The pop output must have the following format: + + OP_RETURN <version> <txid> <nonce> + +{| +! Field !! Size [B] !! Description +|- +| <version> || 2 || Version, little endian, currently 0x01 0x00 +|- +| <txid> || 32 || The transaction to prove +|- +| <nonce> || 6 || Random data +|} + +The lock_time of the PoP must be set to 499999999 to prevent the PoP from being included in a block, should it appear on the bitcoin p2p network. This is also the reason for setting the sequence numbers to 0, since sequence number of ffffffff would make lock_time ineffective. This specification demands that all input sequence numbers are 0, not just one of them, which would be sufficient to make lock_time effective. This is for simplicity reasons. + +An illustration of the PoP data structure and its original payment is shown below. + +<pre> + T + +------------------------------------------------+ + |inputs | outputs | + | Value,Sequence | Value,Script | + +------------------------------------------------+ + |input0 1,ffffffff | 0,pay to A | + |input1 3,ffffffff | 2,OP_RETURN <some data> | + |input2 4,ffffffff | 1,pay to B | + | | 4,pay to C | + +------------------------------------------------+ + + PoP(T) + +-------------------------------------------------------------+ + | inputs | outputs | + | Value,Sequence | Value,Script | + +-------------------------------------------------------------+ + |input0 1,00000000 | 0,OP_RETURN <version> <txid> <nonce> | + |input1 3,00000000 | | + |input2 4,00000000 | | + +-------------------------------------------------------------+ + | lock_time=499999999 | + +-------------------------------------------------------------+ +</pre> + +The PoP is signed using the same signing process that is used for bitcoin transactions. + +The purpose of the nonce is to make it harder to use a stolen PoP; Once the PoP has reached the server, that PoP is useless since the server will generate a new nonce for every PoP request. + +=== Process === + +# A proof of payment request is sent from the server to the wallet. The PoP request contains: +## a random nonce +## a destination where to send the PoP, for example a https URL +## data hinting the wallet which transaction to create a proof for. For example: +##* txid, if known by the server +##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment) +##* amount, label, message or other information from a BIP0021 URI +# The wallet identifies a transaction T, if possible. Otherwise it asks the user to select among the ones that match the hints in 1.iii. +# The wallet creates an unsigned PoP (UPoP) for T, and asks the user to sign it. +# The user confirms +# The UPoP(T) is signed by the wallet, creating PoP(T). +# The PoP is sent to the destination in 1.ii. +# The server receiving the PoP validates it and responds with “valid” or “invalid”. +# The wallet displays the response in some way to the user. + +'''Remarks:''' + +* The method of transferring the PoP request at step 1 is not specified here. Instead that is specified in separate specifications, see BIP0121. +* The nonce must be randomly generated by the server for every new PoP request. + +=== Validating a PoP === + +The server needs to validate the PoP and reply with "valid" or "invalid". That process is outlined below. If any step fails, the validation is aborted and "invalid" is returned: + +# Check the format of the PoP. It must pass normal transaction checks, except that the inputs may already be spent. +# Check that lock_time is 499999999. +# Check that there is exactly one output. This output must have value 0 and conform to the OP_RETURN output format outlined above. +# Check that the nonce is the same as the one requested. +# Check that the inputs of the PoP are exactly the same as in transaction T, except that the sequence numbers must all be 0. The ordering of the inputs must also be the same as in T. +# Run the scripts of all the inputs. All scipts must return true. +# Check that the txid in the PoP output is the transaction you actually want proof for. If you don’t know exactly what transaction you want proof for, check that the transaction actually pays for the product/service you deliver. +# Return "valid". + +== Security considerations == + +* Someone can intercept the PoP-request and change any parameter in it. These can be mitigated by using secure connections. Examples of tampered parameters: +** Pop destination - Stealing your PoP. +** label - Trick you to sign an unintended pop or set a label that your wallet doesn't have any record for, resulting in a broken service. Always check the PoP before signing. +** nonce - Your pop will not validate on server. +* Someone can steal a PoP, for example by tampering with the PoP request, and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^48). The server should have a mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so. +* Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied. +* Transaction malleability may cause the server to have another transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions. + +== Reference implementation == + +[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub] + +[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub] + +== References == + +[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme + +[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP0070]: Payment Protocol + +[https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki BIP0121]: Proof of Payment URI scheme diff --git a/bip-0121.mediawiki b/bip-0121.mediawiki new file mode 100644 index 0000000..76513dd --- /dev/null +++ b/bip-0121.mediawiki @@ -0,0 +1,146 @@ +<pre> + BIP: 121 + Title: Proof of Payment URI scheme + Author: Kalle Rosenbaum <kalle@rosenbaum.se> + Status: Draft + Type: Standards Track + Created: 2015-07-27 +</pre> + +== Abstract == + +This is a proposal for a URI scheme to be used in the Proof of Payment +process. + +== Motivation == + +To make a Proof of Payment, the party that wants the proof needs to +transfer a Proof of Payment request to the wallet software of the +other party. To facilitate that transfer, a new URI scheme +representing the PoP request is proposed. This URI can then be encoded +in QR images or be sent over NFC in order to transfer it to the wallet. + +== Specification == + +The specification is the same as BIP0021, with the following +differences: + +* The URI scheme is <tt>btcpop</tt> instead of <tt>bitcoin</tt> +* The path component, i.e. the address part, is always empty. +* A mandatory <tt>p</tt> parameter whose value contains the destination for the PoP. This could for example be a <tt>https:</tt> URL or a <tt>mailto:</tt> URI. +* A mandatory <tt>n</tt> parameter representing the nonce, base58 encoded. +* An optional <tt>txid</tt> parameter containing the Base58 encoded hash of the transaction to prove. + +Just as in BIP0021, 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. + +All parameters except <tt>p</tt> and <tt>n</tt> are hints to the +wallet on which transaction to create a PoP for. + +The extensibility of BIP0021 applies to this scheme as well. For +example, a <tt>date</tt> parameter or a <tt>toaddr</tt> parameter +might be useful. <tt>req-*</tt> parameters are also allowed and obey +the same rules as in BIP0021, clients not supporting a <tt>req-*</tt> +parameter must consider the URI invalid. + +=== Keep URIs short === + +Implementations should keep the URIs as short as possible. This is +because it makes QR decoding more stable. A camera with a scratched +lens or low resolution may run into problems scanning huge QR +codes. This is why the <tt>txid</tt> parameter is encoded in Base58 +instead of the classic hex encoded string. We get away with 44 +characters instead of 64. Also, the <tt>nonce</tt> parameter is Base58 +encoded for the same reason. + +== Interpretation == + +=== Transaction hints === + +The wallet processing the URI must use the hints in the PoP request to +filter its transaction set. The <tt>label</tt>, <tt>amount</tt> and +<tt>message</tt> parameters must, if present in the URI, exactly match +the data associated with the original payment according to the +following table: + +{| +| <tt>btcpop:</tt> URI parameter || <tt>bitcoin:</tt> URI parameter || BIP70 PaymentDetails data +|- +| <tt>label</tt> || <tt>label</tt> || <tt>merchant_data</tt> +|- +| <tt>amount</tt> || <tt>amount</tt> || <tt>sum of outputs.amount</tt> +|- +| <tt>message</tt> || <tt>message</tt> || <tt>memo</tt> +|} + +The <tt>txid</tt> parameter value must match the transaction hash of +the payment. + +After filtering, the resulting transaction set is displayed to the +user who selects one of them to prove. An implementation could also +automatically select a transaction in the filtered set, but +there must still be a way for the user to select freely among the +matching transactions. If the filtered set is empty, no transaction +fits the hints and a message about that is presented to the user. If +the filtered set contains exactly one transaction, which is +preferable, that transaction can be automatically selected. + +As a fallback, there must also be a way for the user to select any +transaction from the wallet regardless of the transaction hints. This +can be useful if the metadata of the wallet is lost, possibly due to a +restore from backup. + +=== PoP destination <tt>p</tt> === + +The <tt>p</tt> parameter value is the destination where to send the +PoP to. This destination is typically a <tt>https:</tt> URL or a +<tt>http:</tt> URL, but it could be any type of URI, for example +<tt>mailto:</tt>. To keep <tt>btcpop:</tt> URIs short, users should +not make their <tt>p</tt> parameter unneccesarily long. + +==== <tt>http:</tt> and <tt>https:</tt> URLs ==== + +Wallet implementations must support the <tt>http:</tt> and +<tt>https:</tt> schemes in which case <tt>POST</tt> method must be +used. The content type of the POST request must be set to + + Content-Type: application/bitcoin-pop + Content-Transfer-Encoding: binary + +== Examples == + +Send PoP for a transaction with label "video 42923" to +<nowiki>https://www.example.com/pop/352</nowiki>, using nonce +<tt>0x73 0xd5 0x1a 0xbb 0xd8 0x9c</tt>: +<pre> + btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video 42923 +</pre> +Send PoP through mail using +<nowiki>mailto:pop@example.com?subject=pop444</nowiki>, amount +is 13370000 satoshis, nonce is <tt>0x6f 0xe 0xfb 0x68 0x92 0xf9</tt>. +Note that the <tt>?</tt> before <tt>subject</tt> is OK according to RFC3986, +since the query part starts from the first <tt>?</tt>: +<pre> + btcpop:?p=mailto:pop@example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337 +</pre> +Send PoP for transaction with id +<tt>cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79</tt> +to pizza place at <nowiki>http://pizza.example.com/pop/laszlo111</nowiki> using nonce <tt>0xfc 0xcc 0x2c 0x35 0xf0 0xb8</tt> +<pre> + btcpop:?p=http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL +</pre> +== Reference implementation == + +[https://github.com/kallerosenbaum/poppoc PoP Demo server on GitHub] + +[https://github.com/kallerosenbaum/wallet PoP-enabled Mycelium fork on GitHub] + +== References == + +[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]: URI Scheme + +[https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki BIP0120]: Proof of Payment + +[https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier (URI): Generic Syntax |