diff options
| -rw-r--r-- | bip-0175.mediawiki | 31 |
1 files changed, 17 insertions, 14 deletions
diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki index 697a148..c1858ad 100644 --- a/bip-0175.mediawiki +++ b/bip-0175.mediawiki @@ -20,7 +20,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ==Motivation== -A Bitcoin transaction represents a "real world" contract between two parties transferring value. Counterparties in a business interaction traditionally keep track of a payment with bills (invoices) and receipts. Delivery of a good is made by the payee once the payor has signed the receipt, agreeing to pay for the items on the invoice. Gerhardt and Hanke [0] formulate this interaction within the confines of the Bitcoin protocol using homomorphic payment addresses and the multiparty pay-to-contract protocol. +A Bitcoin transaction represents a "real world" contract between two parties transferring value. Counterparties in a business interaction traditionally keep track of a payment with bills (invoices) and receipts. Delivery of a good is made by the payee once the payer has signed the receipt, agreeing to pay for the items on the invoice. Gerhardt and Hanke [0] formulate this interaction within the confines of the Bitcoin protocol using homomorphic payment addresses and the multiparty pay-to-contract protocol. The protocol is constructed in such a way that all parties have cryptographic proof of both who is being paid and for what. Using the technique described in this BIP, an address can be provably derived from the terms of a contract and the payee's public key. This derivation scheme does not bloat the UTXO and is completely hidden to network participants; the derived address looks like any other P2(W)PKH or P2(W)SH address. Redemption of the funds requires knowledge of the contract and the payee's private key. @@ -30,7 +30,7 @@ This scheme utilizes the foundations of BIP-0032, providing a consistent way for This key derivation scheme requires two parties: a payer (customer) and a payee (merchant). The customer submits to the merchant a purchase request, specifying what goods/services they would like to buy. From the purchase request the merchant constructs an invoice (contract), specifying the billable items and total amount to be paid. -The merchant must give this contract alongside a “payment base” extended public key to the customer. Given this information, the customer will be able to fulfill the contract by generating the public key of the payment address associated with the contract and the payment base and sending the funds there. +The merchant must give this contract alongside a “payment base” extended public key to the customer. Given this information, the customer will be able to fulfill the contract by generating the public key of the payment address associated with the contract and the payment base, then sending the funds there. We define the following levels in BIP32 path: @@ -38,7 +38,7 @@ We define the following levels in BIP32 path: m / purpose' / coin_type' / contract_hash </code> -<code>contract_hash</code> consists of mulitple levels. +<code>contract_hash</code> consists of multiple levels. Apostrophe in the path indicates that BIP32 hardened derivation is used. @@ -145,13 +145,16 @@ we can compute payment base as follows: In the below examples, we are going to use SHA256 as a cryptographic hash function, and the above contract base public key. -payment address generation: +====Payment address generation:==== As an input, we have a contract that consists of two documents, below are contents: - document 1: +document 1: + bar - document 2: + +document 2: + foo 1. Apply the hash function: @@ -161,7 +164,6 @@ As an input, we have a contract that consists of two documents, below are conten document 2: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae - 2. Sort all hashes lexicographically: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae @@ -193,18 +195,19 @@ As an input, we have a contract that consists of two documents, below are conten 1HYjhPTtMmpBJBd5tVepZDAVdvPA7o8KHJ -verification example 1 (negative test): +====Verification example 1 (negative test):==== -Similarliy to the input above, except this time we have a contract that consists of one document, below is content: +Similar to the input above, except this time we have a contract that consists of one document, below is the content: + +document 1: - document 1: baz 1. Apply the hash function. baa5a0964d3320fbc0c6a922140453c8513ea24ab8fd0577034804a967248096 -2. Apply the hash function second time (list of one item). +2. Apply the hash function a second time (list of one item). 3a08605829413ce0bf551b08d21e4a28dbda6e407f90eff1c448e839050c73a1 @@ -232,13 +235,13 @@ Verification operation will succeed only if we use identical documents to ones t ==Compatibility== -This specification is not backward compatibile with BIP32 specification, the proposed derivation scheme in this BIP is a BIP32 compliant. -Communication between payor and payee as well as hashing the contract and generating the path requires significant modification to the wallet. +This specification is not backward compatible with BIP32 specification, the proposed derivation scheme in this BIP is a BIP32 compliant. +Communication between payer and payee as well as hashing the contract and generating the path requires significant modification to the wallet. ==Reference implementations== * Reference wallet implementation, based on Copay project : https://github.com/commerceblock/copay ([[https://github.com/commerceblock/copay/pull/1|pull_request]]) -* Reference implementaion to Hash to Partial Derivation Path Mapping in javascript ([[https://github.com/commerceblock/pay-to-contract-lib/blob/master/lib/contract.js|https://github.com/commerceblock/pay-to-contract-lib]]) +* Reference implementation to Hash to Partial Derivation Path Mapping in javascript ([[https://github.com/commerceblock/pay-to-contract-lib/blob/master/lib/contract.js|https://github.com/commerceblock/pay-to-contract-lib]]) ==Reference== |