Utilizing hierarchical deterministic wallets as described in BIP-0032 and the "Purpose Field" in BIP-0043, this document specifies the multiparty pay-to-contract key derivation scheme outlined by Ilja Gerhardt and Timo Hanke.[0]
This BIP is a particular application of BIP-0043 and is based on BIP-0044.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
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.
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.
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.
We define the following levels in BIP32 path:
<code>
m / purpose' / coin_type' / contract_hash
</code>
<code>contract_hash</code> consists of mulitple levels.
Apostrophe in the path indicates that BIP32 hardened derivation is used.
We define the following extended public keys:
Payment base denoted as <code>payment_base</code>:
m / purpose' / coin_type'
Payment address denoted as <code>payment_address</code>:
m / purpose' / coin_type' / contract_hash
or
m / payment_base / contract_hash
Each level has special meaning described in the chapters below.
===Purpose===
Purpose is a constant set to <code>999'</code> (or <code>0x800003E7</code>) following the BIP-0043 recommendation. It indicates that the subtree of this node is used according to this specification.
<code>
m / 999' / *
</code>
Hardened derivation is used at this level.
===Coin type===
The coin type field is identical to the same field in BIP-0044.
Hardened derivation is used at this level.
===Payment Address Generation===
For a given contract documents denoted by c<sub>1</sub> ,...,c<sub>n</sub>, payment base extended public key denoted by <code>payment_base</code>, and cryptographic hash function denoted by <code>h</code>.
1. Compute cryptographic hashes for all contract documents, by applying the hash function.
h(c1),...,h(cn)
2. Sort all hashes lexicographically.
hash_1,...,hash_n
3. Concatenate the sorted hashes and apply the hash function.
h(hash_1+...+hash_n)
4. Compute a partial BIP32 derivation path from the combined hash as defined in Hash to Partial Derivation Path Mapping procedure below.
contract_hash
5. Prepend <code>payment_base</code> to contract_hash derivation path.
payment_base / contract_hash
6. Compute public extended key from the derivation path in step 5.
7. Compute address of the public extended key (P2PKH) from step 6.
===Payment Address Verification===
For a given Bitcoin address, <code>payment_base</code> extended public key, contract documents denoted by c<sub>1</sub>,...,c<sub>n</sub>, and cryptographic hash function denoted by <code>h</code>, we can verify the integrity of the address by the following steps:
1. Compute contract address from the given inputs as described in Contract Address Generation section.
2. Compare the computed address from step 1 with the given Bitcoin address as an input.
===Redemption===
The merchant is able to construct the private key offline using the method described in the Payment Address Generation section.
The merchant should actively monitor the blockchain for the payment to the payment address.
Because the address is generated from the payment base and the contract, the merchant must implicitly agree to those terms in order to spend the funds.
The act of making the payment to that address thus serves as a receipt for the customer.
===Hash to Partial Derivation Path Mapping===
At this section, we define hash to partial BIP32 derivation path mapping procedure that maps between an arbitrary hex number to a partial BIP32 derivation path.
For a given hex number, do the following:
1. Partition hex number into parts, each part length is 4 chars.
2. Convert each part to integer in decimal format.
3. Concatenate all numbers with slash <code>/</code>.
7. Compute address of the public extended key (P2PKH).
1JwnGxLhT9K6RbUsWcjL2mtmpPEHsLFvXG
8. As expected the address doesn't match the Bitcoin address from the last example <code>1LeYXs63uVSDu2XSb82xdEc7RumohCpB7Q</code>.
Verification operation will succeed only if we use identical documents to ones that have been used in the contract address generation.
==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]])
