diff options
33 files changed, 163 insertions, 62 deletions
diff --git a/README.mediawiki b/README.mediawiki index 6cc42b5..816531b 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -174,7 +174,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Slush | Standard | BIP number allocated -<!-- 42-49 reserved for stratum extensions --> +|- +| [[bip-0042.mediawiki|42]] +| A finite monetary supply for Bitcoin +| Pieter Wuille +| Standard +| Draft +<!-- 43-49 reserved for stratum extensions --> |- | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem @@ -196,15 +202,16 @@ Those proposing changes should consider that ultimately consent may rest with th | Draft |- | [[bip-0062.mediawiki|62]] -| Non-malleable transactions +| Dealing with malleability | Pieter Wuille | Standard | Draft |- -| [[bip-0062.mediawiki|62]] -| Dealing with malleability -| Pieter Wuille -| Draft +| 63 +| Stealth Addresses +| Peter Todd +| Standard +| BIP number allocated |- | [[bip-0070.mediawiki|70]] | Payment protocol diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki index adfa60d..c9857a8 100644 --- a/bip-0001.mediawiki +++ b/bip-0001.mediawiki @@ -3,7 +3,7 @@ Title: BIP Purpose and Guidelines Status: Accepted Type: Standards Track - Created: 19-08-2011 + Created: 2011-08-19 </pre> ==What is a BIP?== @@ -100,7 +100,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded> Type: <Standards Track | Informational | Process> - Created: <date created on, in dd-mm-yyyy format> + Created: <date created on, in ISO 8601 (yyyy-mm-dd) format> * Post-History: <dates of postings to bitcoin mailing list> * Replaces: <BIP number> * Superseded-By: <BIP number> @@ -125,7 +125,7 @@ While a BIP is in private discussions (usually during the initial Draft phase), The Type header specifies the type of BIP: Standards Track, Informational, or Process. -The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. +The Created header records the date that the BIP was assigned a number, while Post-History is used to record the dates of when new versions of the BIP are posted to bitcoin mailing lists. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on. diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index 76712f5..b3d750b 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -4,7 +4,7 @@ Author: Alan Reiner Status: Draft Type: Informational - Created: 28-10-2011 + Created: 2011-10-28 </pre> A multi-signature transaction is one where a certain number of Bitcoins are "encumbered" with more than one recipient address. The subsequent transaction that spends these coins will require each party involved (or some subset, depending on the script), to see the proposed transaction and sign it with their private key. This necessarily requires collaboration between all parties -- to propose a distribution of encumbered funds, collect signatures from all necessary participants, and then broadcast the completed transaction. diff --git a/bip-0011.mediawiki b/bip-0011.mediawiki index 6a4edbe..2499ac0 100644 --- a/bip-0011.mediawiki +++ b/bip-0011.mediawiki @@ -4,8 +4,8 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Accepted Type: Standards Track - Created: 18-10-2011 - Post-History: 02-10-2011 + Created: 2011-10-18 + Post-History: 2011-10-02 </pre> ==Abstract== diff --git a/bip-0012.mediawiki b/bip-0012.mediawiki index 922283a..ee2fda6 100644 --- a/bip-0012.mediawiki +++ b/bip-0012.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Withdrawn Type: Standards Track - Created: 18-10-2011 + Created: 2011-10-18 </pre> ==Abstract== diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index 367862b..a537d16 100644 --- a/bip-0013.mediawiki +++ b/bip-0013.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Final Type: Standards Track - Created: 18-10-2011 + Created: 2011-10-18 </pre> ==Abstract== diff --git a/bip-0014.mediawiki b/bip-0014.mediawiki index 213afb9..111eb78 100644 --- a/bip-0014.mediawiki +++ b/bip-0014.mediawiki @@ -5,8 +5,8 @@ Patrick Strateman <bitcoin-bips@covertinferno.org> Status: Accepted Type: Standards Track - Created: 10-11-2011 - Post-History: 02-11-2011 + Created: 2011-11-10 + Post-History: 2011-11-02 </pre> In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion. diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index 1ec6f12..c08498f 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -4,7 +4,7 @@ Author: Amir Taaki <genjix@riseup.net> Status: Deferred Type: Standards Track - Created: 10-12-2011 + Created: 2011-12-10 </pre> [[bip-0070.mediawiki|BIP 0070]] (payment protocol) may be seen as the alternative to Aliases. diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index c99f5e1..0a539fc 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Final Type: Standards Track - Created: 03-01-2012 + Created: 2012-01-03 </pre> ==Abstract== @@ -29,7 +29,7 @@ This new transaction type is redeemed by a standard scriptSig: ...signatures... {serialized script} -Transactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' is, itself, one of the other standard transaction types. +Transactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' - also referred to as the ''redeemScript'' - is, itself, one of the other standard transaction types. The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows: @@ -96,6 +96,11 @@ On February 1, 2012, the block-chain will be examined to determine the number of If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved). +===520-byte limitation on serialized script size=== + +As a consequence of the requirement for backwards compatiblity the serialized script is itself subject to the same rules as any other PUSHDATA operation, including the rule that no data greater than 520 bytes may be pushed to the stack. Thus is it not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length. For instance while the OP_CHECKMULTISIG opcode can itself accept up to 20 pubkeys, with 33-byte compressed pubkeys it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes. + + ==Reference Implementation== https://gist.github.com/gavinandresen/3966071 @@ -103,8 +108,8 @@ https://gist.github.com/gavinandresen/3966071 ==See Also== * https://bitcointalk.org/index.php?topic=46538 -* The [[BIP 0013|Address format for Pay to Script Hash BIP]] -* M-of-N Multisignature Transactions [[BIP 0011|BIP 11]] +* The [[bip-0013.mediawiki|Address format for Pay to Script Hash BIP]] +* M-of-N Multisignature Transactions [[bip-0011.mediawiki|BIP 11]] * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]] == References == diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki index fa13c0b..07dca96 100644 --- a/bip-0017.mediawiki +++ b/bip-0017.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip17@dashjr.org> Status: Draft Type: Withdrawn - Created: 18-01-2012 + Created: 2012-01-18 </pre> ==Abstract== diff --git a/bip-0018.mediawiki b/bip-0018.mediawiki index c0d8082..023b2bf 100644 --- a/bip-0018.mediawiki +++ b/bip-0018.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip17@dashjr.org> Status: Draft Type: Standards Track - Created: 27-01-2012 + Created: 2012-01-27 </pre> ==Abstract== diff --git a/bip-0019.mediawiki b/bip-0019.mediawiki index 2255313..7784e08 100644 --- a/bip-0019.mediawiki +++ b/bip-0019.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip17@dashjr.org> Status: Draft Type: Standards Track - Created: 30-01-2012 + Created: 2012-01-30 </pre> ==Abstract== diff --git a/bip-0020.mediawiki b/bip-0020.mediawiki index 53823e8..fad634b 100644 --- a/bip-0020.mediawiki +++ b/bip-0020.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip@dashjr.org> Status: Replaced Type: Standards Track - Created: 10-01-2011 + Created: 2011-01-10 </pre> BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021''' diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki index 8f2201b..00d9a53 100644 --- a/bip-0021.mediawiki +++ b/bip-0021.mediawiki @@ -5,7 +5,7 @@ Matt Corallo <bip21@bluematt.me> Status: Accepted Type: Standards Track - Created: 29-01-2012 + Created: 2012-01-29 </pre> 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. @@ -26,19 +26,29 @@ They SHOULD require the user to manually approve each payment individually, thou === Operating system integration === Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client. -=== BNF grammar === +=== General Format === + +Bitcoin URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a bitcoin address, and the query component provides additional payment options. + +Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. + +=== ABNF grammar === (See also [[#Simpler syntax|a simpler representation of syntax]]) bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ] - bitcoinaddress = base58 *base58 - bitcoinparams = *bitcoinparam - bitcoinparam = amountparam | labelparam | messageparam | otherparam | reqparam + bitcoinaddress = *base58 + bitcoinparams = bitcoinparam [ "&" bitcoinparams ] + bitcoinparam = [ amountparam / labelparam / messageparam / otherparam / reqparam ] amountparam = "amount=" *digit [ "." *digit ] - labelparam = "label=" *pchar - messageparam = "message=" *pchar - otherparam = pchar *pchar "=" *pchar - reqparam = "req-" pchar *pchar "=" *pchar + labelparam = "label=" *qchar + messageparam = "message=" *qchar + otherparam = qchar *qchar [ "=" *qchar ] + reqparam = "req-" qchar *qchar [ "=" *qchar ] + +Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this BIP takes as separators. + +The scheme component ("bitcoin:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys. === Query Keys === diff --git a/bip-0022.mediawiki b/bip-0022.mediawiki index 793b5f3..ffb303b 100644 --- a/bip-0022.mediawiki +++ b/bip-0022.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip22@dashjr.org> Status: Accepted Type: Standards Track - Created: 28-02-2012 + Created: 2012-02-28 </pre> ==Abstract== diff --git a/bip-0023.mediawiki b/bip-0023.mediawiki index 4cdaa31..a53b00b 100644 --- a/bip-0023.mediawiki +++ b/bip-0023.mediawiki @@ -4,7 +4,7 @@ Author: Luke Dashjr <luke+bip22@dashjr.org> Status: Accepted Type: Standards Track - Created: 28-02-2012 + Created: 2012-02-28 </pre> ==Abstract== diff --git a/bip-0030.mediawiki b/bip-0030.mediawiki index cd725b8..135d300 100644 --- a/bip-0030.mediawiki +++ b/bip-0030.mediawiki @@ -4,7 +4,7 @@ Author: Pieter Wuille <pieter.wuille@gmail.com> Status: Final Type: Standards Track - Created: 22-02-2012 + Created: 2012-02-22 </pre> ==Abstract== @@ -17,7 +17,7 @@ So far, the Bitcoin reference implementation always assumed duplicate transactio To counter this problem, the following network rule is introduced: *Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain. -This rule is to be applied to all blocks whose timestamp is after a point in time that is yet to be decided. +This rule initially applied to all blocks whose timestamp is after March 15, 2012, 00:00 UTC (testnet: February 20, 2012 00:00 UTC). It was later extended by Commit [https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 Apply BIP30 checks to all blocks except the two historic violations.] to apply to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in. ==Rationale== Whatever solution is used, the following law must be obeyed to guarantee sane behaviour: the set of usable diff --git a/bip-0031.mediawiki b/bip-0031.mediawiki index 2c40ead..8adcd29 100644 --- a/bip-0031.mediawiki +++ b/bip-0031.mediawiki @@ -4,7 +4,7 @@ Author: Mike Hearn <hearn@google.com> Status: Accepted Type: Standards Track - Created: 11-04-2012 + Created: 2012-04-11 </pre> ==Abstract== diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 2f59711..fdc9613 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -2,7 +2,7 @@ RECENT CHANGES: * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors -* (15 Jan 2014) Rename keys with index ≥ 0x8000000 to hardened keys, and add explicit covnersion functions. +* (15 Jan 2014) Rename keys with index ≥ 0x8000000 to hardened keys, and add explicit conversion functions. <pre> BIP: 32 @@ -10,7 +10,7 @@ RECENT CHANGES: Author: Pieter Wuille Status: Accepted Type: Informational - Created: 11-02-2012 + Created: 2012-02-11 </pre> ==Abstract== diff --git a/bip-0033.mediawiki b/bip-0033.mediawiki index c5721f4..6768e19 100644 --- a/bip-0033.mediawiki +++ b/bip-0033.mediawiki @@ -4,7 +4,7 @@ Author: Amir Taaki <genjix@riseup.net> Status: Draft Type: Standards Track - Created: 15-05-2012 + Created: 2012-05-15 </pre> == Abstract == diff --git a/bip-0036.mediawiki b/bip-0036.mediawiki index 8b114b4..9c61fdb 100644 --- a/bip-0036.mediawiki +++ b/bip-0036.mediawiki @@ -4,7 +4,7 @@ Author: Stefan Thomas <justmoon@members.fsf.org> Status: Draft Type: Standards Track - Created: 03-08-2012 + Created: 2012-08-03 </pre> ==Abstract== diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index d491ce5..8179393 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -4,7 +4,7 @@ Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me> Status: Accepted Type: Standards Track - Created: 24-10-2012 + Created: 2012-10-24 </pre> ==Abstract== diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index 6f5dd45..39f0632 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -1,10 +1,11 @@ <pre> BIP: 38 Title: Passphrase-protected private key - Author: Mike Caldwell + Authors: Mike Caldwell + Aaron Voisine <voisine@gmail.com> Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion) Type: Standards Track - Created: 20-11-2012 + Created: 2012-11-20 </pre> ==Abstract== @@ -139,9 +140,9 @@ Steps to create new encrypted private keys given ''intermediate_passphrase_strin # Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''. # Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt #*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation. -#*Split the result into two 16-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''. -# Do AES256Encrypt(seedb[0...15]] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1'' -# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedseedb''. The "+" operator is concatenation. +#*Split the result into two 32-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''. +# Do AES256Encrypt(seedb[0...15] xor derivedhalf1[0...15], derivedhalf2), call the 16-byte result ''encryptedpart1'' +# Do AES256Encrypt((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31], derivedhalf2), call the 16-byte result ''encryptedpart2''. The "+" operator is concatenation. The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum: * 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2'' @@ -163,7 +164,7 @@ A confirmation tool, given a passphrase and a confirmation code, can recalculate =====Decryption===== # Collect encrypted private key and passphrase from user. -# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint'' +# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint'' # Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownersalt'' # Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''. # Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index a04a745..cfa3bd5 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -8,7 +8,7 @@ Sean Bowe <ewillbefull@gmail.com> Status: Draft Type: Standards Track - Created: 10-09-2013 + Created: 2013-09-10 </pre> ==Abstract== diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki new file mode 100644 index 0000000..d7ce71c --- /dev/null +++ b/bip-0042.mediawiki @@ -0,0 +1,77 @@ +<pre> + BIP: 42 + Title: A finite monetary supply for Bitcoin + Author: Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 2014-04-01 +</pre> + +==Abstract== + +Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. + +This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. + +To combat this, this document proposes a controversial change: making Bitcoin's monetary supply finite. + +==Details== + +As is well known, Satoshi was a master programmer whose knowledge of C++ was surpassed only by his knowledge of Japanese culture. The code below: + + int64_t nSubsidy = 50 * COIN; + // Subsidy is cut in half every 210,000 blocks + // which will occur approximately every 4 years. + nSubsidy >>= (nHeight / 210000); + +is carefully written to rely on undefined behaviour in the C++ specification - perhaps so it can be hardware accelerated in future. + +The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units. Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings on all currently supported platforms. + +Despite the nice showoff of underhanded programming skills - we want Bitcoin to be well-specified. Otherwise, we're clearly in for a bumpy ride: + +<img src="bip-0042/inflation.png"></img> + +Note that several other programming languages do not exhibit this behaviour, making new implementations likely to be slower and generally more bogus than Bitcoin Core. For example, Python unexpectedly returns 0 when shifting an integer beyond its size. + +==Other solutions== + +===Floating-point approximation=== + +An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. + +===Truncation=== + +An alternative solution would be to represent the total number of bitcoins as a string: + + "21000000000000000000000" + +and then use string manipulation to remove the rightmost zero every 4 years, give or take a leap-year: + + strSubsidy = strSubsidy.substr(0, strSubsidy.size() - 2); + +This style relies less heavily on clever C++ and is more familiar to the Core Dev Team who are primarily PHP programmers. + +==Proposal== + +Instead, how about we stop thinking about long term issues when we'll all be dead (barring near lightspeed travel, cryogenic revival, or other technology— like cryptocurrency— which only exists in science fiction). + +A softfork (see BIP16, BIP34, BIP62) will take place on april 1st 2214, permanently setting the subsidy to zero. The result of this will be that the total currency supply will be limited to 42 halfmillion (including the genesis coinbase output, which is not actually spendable). + +==Implementation== + +An implementation for the reference client can be found on https://github.com/bitcoin/bitcoin/pull/3842 . + +==Compatibility== + +Given the moderate time frame over which this change is to be implemented, we expect all miners to choose to screw themselves and deploy this change before 2214. + +If they don't, and a minority remains on the old code base, a fork may occur. Essentially, they'll be mining fool's gold after that time. + +==Acknowledgements== + +Thanks to Gregory Maxwell for proposing this solution, and to Mike Hearn for insights into web development. Also thanks to "ditto-b" on github to implement a prototype ahead of time. + +==Copyright== + +This document is placed in the public domain. diff --git a/bip-0042/inflation.png b/bip-0042/inflation.png Binary files differnew file mode 100644 index 0000000..3ebc254 --- /dev/null +++ b/bip-0042/inflation.png diff --git a/bip-0050.mediawiki b/bip-0050.mediawiki index ea5243d..9ff29d6 100644 --- a/bip-0050.mediawiki +++ b/bip-0050.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Draft Type: Informational - Created: 20-03-2013 + Created: 2013-03-20 </pre> ==What went wrong== diff --git a/bip-0060.mediawiki b/bip-0060.mediawiki index e23ecae..ae9592a 100644 --- a/bip-0060.mediawiki +++ b/bip-0060.mediawiki @@ -4,7 +4,7 @@ Author: Amir Taaki <genjix@riseup.net> Status: Draft Type: Standards Track - Created: 16-06-2013 + Created: 2013-06-16 </pre> ==Abstract== diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index dfa4072..3f11050 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -4,7 +4,7 @@ Author: Pieter Wuille <pieter.wuille@gmail.com> Status: Draft Type: Standards Track - Created: 12-03-2014 + Created: 2014-03-12 </pre> ==Abstract== diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 158c821..657b4f2 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 </pre> ==Abstract== diff --git a/bip-0071.mediawiki b/bip-0071.mediawiki index 1fcb174..44b4d3d 100644 --- a/bip-0071.mediawiki +++ b/bip-0071.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 </pre> ==Abstract== diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index 4edd749..dae53f4 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -4,7 +4,7 @@ Author: Gavin Andresen <gavinandresen@gmail.com> Status: Draft Type: Standards Track - Created: 29-07-2013 + Created: 2013-07-29 </pre> ==Abstract== @@ -22,8 +22,9 @@ bitcoin wallets. The bitcoin: URI scheme is extended with an additional, optional "r" parameter, whose value is a URL from which a PaymentRequest -message should be fetched (unsafe and reserved octets in the URL value -must be encoded as described in RFC 1738). +message should be fetched (characters not allowed within the scope +of a query parameter must be percent-encoded as described in RFC 3986 +and bip-0021). If the "r" parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be @@ -52,9 +53,9 @@ r parameter and will initiate a payment to bitcoin address. ==Examples== A backwards-compatible request: <pre> -bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe +bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe </pre> Non-backwards-compatible equivalent: <pre> -bitcoin:?r=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe +bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe </pre> diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki index 4414351..a020fb5 100644 --- a/bip-0073.mediawiki +++ b/bip-0073.mediawiki @@ -4,7 +4,7 @@ Author: Stephen Pair <stephen@bitpay.com> Status: Draft Type: Standards Track - Created: 27-08-2013 + Created: 2013-08-27 </pre> ==Abstract== |
