From bda2aa1b0eb6230370789baf74aac47ba5748b1c Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Fri, 27 Dec 2013 17:04:31 +0100 Subject: [PATCH 1/9] Extend description of the partial merkle block format --- bip-0037.mediawiki | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index 7b02b074..d491ce56 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -148,7 +148,40 @@ Obviously, nFlags == 1 or nFlags == 2 mean that the filter will get dirtier as m A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block. -The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding. +====Constructing a partial merkle tree object==== + +* Traverse the merkle tree from the root down, and for each encountered node: +** Check whether this node corresponds to a leaf node (transaction) that is to be included OR any parent thereof: +*** If so, append a '1' bit to the flag bits +*** Otherwise, append a '0' bit. +** Check whether this node is a internal node (non-leaf) AND is the parent of an included leaf node: +*** If so: +**** Descend into its left child node, and process the subtree beneath it entirely (depth-first). +**** If this node has a right child node too, descend into it as well. +*** Otherwise: append this node's hash to the hash list. + +====Parsing a partial merkle tree object==== + +As the partial block message contains the number of transactions in the entire block, the shape of the merkle tree is known before hand. Again, traverse this tree, computing traversed node's hashes along the way: +* Read a bit from the flag bit list: +** If it is '0': +*** Read a hash from the hashes list, and return it as this node's hash. +** If it is '1' and this is a leaf node: +*** Read a hash from the hashes list, store it as a matched txid, and return it as this node's hash. +** If it is '1' and this is an internal node: +*** Descend into its left child tree, and store its computed hash as L. +*** If this node has a right child as well: +**** Descend into its right child, and store its computed hash as R. +**** If L == R, the partial merkle tree object is invalid. +**** Return Hash(L || R). +*** If this node has no right child, return Hash(L || L). + +The partial merkle tree object is only valid if: +* All hashes in the hash list were consumed and no more. +* All bits in the flag bits list were consumed (except padding to make it into a full byte), and no more. +* The hash computed for the root node matches the block header's merkle root. +* The block header is valid, and matches its claimed proof of work. +* In two-child nodes, the hash of the left and right branches was never equal. ===Bloom filter format=== From c148390d1102a0826d7bc7b957a461e536e78181 Mon Sep 17 00:00:00 2001 From: Ming C Date: Sun, 5 Jan 2014 00:51:03 +0800 Subject: [PATCH 2/9] Update bip-0013.mediawiki Clarified that the 4-byte checksum is from double SHA256 rounds --- bip-0013.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index ce71a6a4..367862be 100644 --- a/bip-0013.mediawiki +++ b/bip-0013.mediawiki @@ -25,7 +25,7 @@ The new bitcoin address type is constructed in the same manner as existing bitco Version byte is 5 for a main-network address, 196 for a testnet address. The 20-byte hash is the hash of the script that will be used to redeem the coins. -And the 4-byte checksum is the first four bytes of the SHA256 hash of the version and hash. +And the 4-byte checksum is the first four bytes of the double SHA256 hash of the version and hash. ==Rationale== From 2ca1e6229cd4211b5c317d378d3ea30d55303245 Mon Sep 17 00:00:00 2001 From: Cayman Date: Sun, 12 Jan 2014 14:05:45 -0800 Subject: [PATCH 3/9] Adding link to Go implementation --- bip-0032.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 10dbf9f1..9317a54a 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -238,6 +238,8 @@ A C++ implementation is available at https://github.com/CodeShark/CoinClasses/tr A Ruby implementation is available at https://github.com/wink/money-tree +A Go implementation is available at https://github.com/WeMeetAgain/go-hdwallet + ==Acknowledgements== * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. From 9ffdda80708fda4321bc93c226457ac0aab44f09 Mon Sep 17 00:00:00 2001 From: Chuck Date: Thu, 9 Jan 2014 15:30:58 +0700 Subject: [PATCH 4/9] Link to Sarchar's JavaScript BIP32 implementation. --- bip-0032.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 9317a54a..a835d262 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -240,6 +240,8 @@ A Ruby implementation is available at https://github.com/wink/money-tree A Go implementation is available at https://github.com/WeMeetAgain/go-hdwallet +A JavaScript implementation is available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 + ==Acknowledgements== * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. From f386191bc42bb2f45a4ce61584b4b0ee1a024a45 Mon Sep 17 00:00:00 2001 From: Eli Dourado Date: Thu, 16 Jan 2014 11:31:24 -0500 Subject: [PATCH 5/9] Add Type field to table in README I thought it would be nice to enable people browsing BIPs to be able to tell at a glance which ones are standards track and which are informational. --- README.mediawiki | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/README.mediawiki b/README.mediawiki index 4f1431d2..26b8d5dc 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -10,173 +10,207 @@ Those proposing changes should consider that ultimately consent may rest with th !Number !Title !Owner +!Type !Status |- style="background-color: #cfffcf" | [[bip-0001.mediawiki|1]] | BIP Purpose and Guidelines | Amir Taaki +| Standard | Active |- | [[bip-0010.mediawiki|10]] | Multi-Sig Transaction Distribution | Alan Reiner +| Informational | Draft |- style="background-color: #cfffcf" | [[bip-0011.mediawiki|11]] | M-of-N Standard Transactions | Gavin Andresen +| Standard | Accepted |- style="background-color: #ffcfcf" | [[bip-0012.mediawiki|12]] | OP_EVAL | Gavin Andresen +| Standard | Withdrawn |- style="background-color: #cfffcf" | [[bip-0013.mediawiki|13]] | Address Format for pay-to-script-hash | Gavin Andresen +| Standard | Final |- style="background-color: #cfffcf" | [[bip-0014.mediawiki|14]] | Protocol Version and User Agent | Amir Taaki, Patrick Strateman +| Standard | Accepted |- style="background-color: #ffcfcf" | [[bip-0015.mediawiki|15]] | Aliases | Amir Taaki +| Standard | Withdrawn |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] | Pay To Script Hash | Gavin Andresen +| Standard | Accepted |- style="background-color: #ffcfcf" | [[bip-0017.mediawiki|17]] | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr | Withdrawn +| Draft |- | [[bip-0018.mediawiki|18]] | hashScriptCheck | Luke Dashjr +| Standard | Draft |- | [[bip-0019.mediawiki|19]] | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr +| Standard | Draft |- style="background-color: #ffcfcf" | [[bip-0020.mediawiki|20]] | URI Scheme | Luke Dashjr +| Standard | Replaced |- style="background-color: #cfffcf" | [[bip-0021.mediawiki|21]] | URI Scheme | Nils Schneider, Matt Corallo +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0022.mediawiki|22]] | getblocktemplate - Fundamentals | Luke Dashjr +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0023.mediawiki|23]] | getblocktemplate - Pooled Mining | Luke Dashjr +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0030.mediawiki|30]] | Duplicate transactions | Pieter Wuille +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0031.mediawiki|31]] | Pong message | Mike Hearn +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0032.mediawiki|32]] | Hierarchical Deterministic Wallets | Pieter Wuille +| Informational | Accepted |- | [[bip-0033.mediawiki|33]] | Stratized Nodes | Amir Taaki +| Standard | Draft |- style="background-color: #cfffcf" | [[bip-0034.mediawiki|34]] | Block v2, Height in coinbase | Gavin Andresen +| Standard | Accepted |- style="background-color: #cfffcf" | [[bip-0035.mediawiki|35]] | mempool message | Jeff Garzik +| Standard | Accepted |- | [[bip-0036.mediawiki|36]] | Custom Services | Stefan Thomas +| Standard | Draft |- style="background-color: #cfffcf" | [[bip-0037.mediawiki|37]] | Bloom filtering | Mike Hearn and Matt Corallo +| Standard | Accepted |- | [[bip-0038.mediawiki|38]] | Passphrase-protected private key | Mike Caldwell +| Standard | Draft |- | [[bip-0039.mediawiki|39]] | Mnemonic code for generating deterministic keys | Slush +| Standard | Draft |- | 40 | Stratum wire protocol | Slush +| Standard | BIP number allocated |- | 41 | Stratum mining protocol | Slush +| Standard | BIP number allocated |- | [[bip-0050.mediawiki|50]] | March 2013 Chain Fork Post-Mortem | Gavin Andresen +| Informational | Draft |- | [[bip-0060.mediawiki|60]] | Fixed Length "version" Message (Relay-Transactions Field) | Amir Taaki +| Standard | Draft |- | [[bip-0070.mediawiki|70]] | Payment protocol | Gavin Andresen +| Standard | Draft |- | [[bip-0071.mediawiki|71]] | Payment protocol MIME types | Gavin Andresen +| Standard | Draft |- | [[bip-0072.mediawiki|72]] | Payment protocol URIs | Gavin Andresen +| Standard | Draft |- | [[bip-0073.mediawiki|73]] | Use "Accept" header with Payment Request URLs | Stephen Pair +| Standard | Draft |} From 057f001cf8a7f78fe2cd4db08abed662f3d89370 Mon Sep 17 00:00:00 2001 From: James Brotchie Date: Wed, 22 Jan 2014 09:13:47 +1000 Subject: [PATCH 6/9] Fixed table cell truncation Added spaces after cells in the first column of the `PaymentDetails` table because their contents were being truncated by GitHub's markdown renderer. --- bip-0070.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 7e434f9a..699ff32c 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -84,15 +84,15 @@ about the merchant and a digital signature. {| | network || either "main" for payments on the production Bitcoin network, or "test" for payments on test network. If a client receives a PaymentRequest for a network it does not support it must reject the request. |- -| outputs|| one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). +| outputs || one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). |- -| time|| Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created. +| time || Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created. |- -| expires|| Unix timestamp after which the PaymentRequest should be considered invalid. +| expires || Unix timestamp after which the PaymentRequest should be considered invalid. |- -| memo|| UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for. +| memo || UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for. |- -| payment_url|| Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK. +| payment_url || Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK. |- | merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address. |} From 806495e039114c7a8048250706633f3b20ca4107 Mon Sep 17 00:00:00 2001 From: Matias Alejo Garcia Date: Wed, 22 Jan 2014 15:25:58 -0300 Subject: [PATCH 7/9] fix typo --- bip-0010.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0010.mediawiki b/bip-0010.mediawiki index ac4f4a4b..76712f5c 100644 --- a/bip-0010.mediawiki +++ b/bip-0010.mediawiki @@ -26,7 +26,7 @@ This BIP proposes the following process, with terms in quotes referring to recom # The user creating the TxDP (the preparer) will create the transaction as they would like to see it spent, but with blank TxIn scripts (where the signatures scripts will eventually go). # The proposed transaction will be spending a set of unspent TxOuts available in the blockchain. The full transactions containing these TxOuts will be serialized and included, as well. This so that the values of the TxIns can be verified before signing (the prev-tx-hash is part of the data being signed, but the value is not). By including the full tx, the signing party can verify that the tx matches the OutPoint hash, and then verify input values, all without any access to the blockchain. # The TxDP will have an "DP ID" or "Unsigned ID" which is the hash of the proposed transaction with blanked scripts, in Base58. This is a specific naming convention to make sure it is not confused with the actual the transaction ID that it will have after it is broadcast (the transaction ID cannot be determined until after all signatures are collected). The final Tx ID can be referred to as its "Broadcast ID", in order to distinguish it from the pre-signed ID. -# The TxDP will have an potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. +# The TxDP will have a potentially-unordered list of sig-pubkey pairs which represent collected signatures. If you receive a TxDP missing only your signature, you can broadcast it as soon as you sign it. # Identical TxDP objects with different signatures can be easily combined. This allows one party to send out all the requests for signatures at once, and combine them all when they are received (instead of having to "pass it around". # For cases where the TxDP might be put into a file or sent via email, it should use .txdp or .btcdp suffix From 244f4a115ed4aee8155533f9f41c35ada375e3b1 Mon Sep 17 00:00:00 2001 From: Gregory Maxwell Date: Thu, 23 Jan 2014 04:31:18 -0800 Subject: [PATCH 8/9] Update README.mediawiki Assign BIP61 for reject p2p message --- README.mediawiki | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.mediawiki b/README.mediawiki index 26b8d5dc..985a7bd2 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -189,6 +189,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0061.mediawiki|61]] +| "reject" P2P message +| Gavin Andresen +| Standard +| Draft +|- | [[bip-0070.mediawiki|70]] | Payment protocol | Gavin Andresen From 970d5420106afce2a09947f75b1990e8cc2ac2fd Mon Sep 17 00:00:00 2001 From: Andreas Schildbach Date: Mon, 27 Jan 2014 22:19:55 +0100 Subject: [PATCH 9/9] Fix missing word in pki_data description --- bip-0070.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 699ff32c..323ad676 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -112,7 +112,7 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity: |- | pki_type || public-key infrastructure (PKI) system being used to identify the merchant. All implementation should support "none", "x509+sha256" and "x509+sha1". |- -| pki_data || PKI-system data that identifies the merchant and can be used to create a digital signature. In the case of X.509 certificates, pki_data one or more X.509 certificates (see Certificates section below). +| pki_data || PKI-system data that identifies the merchant and can be used to create a digital signature. In the case of X.509 certificates, pki_data contains one or more X.509 certificates (see Certificates section below). |- | serialized_payment_details || A protocol-buffer serialized PaymentDetails message. |-