New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bip47: define version 3 payment codes #8

Open
wants to merge 3 commits into
base: bip47
from
File filter...
Filter file types
Jump to file or symbol
Failed to load files and symbols.
+45 −6
Diff settings

Always

Just for now

Copy path View file
@@ -1,7 +1,7 @@
RECENT CHANGES:
* (28 Sep 2017) Define version 3 payment codes
* (28 Sep 2017) Adjust text to match test vectors
* (19 Apr 2016) Define version 2 payment codes
* (17 Apr 2016) Clarify usage of outpoints in notification transactions
* (18 Dec 2015) Update explanations to resolve FAQs
<pre>
BIP: 47
@@ -65,7 +65,11 @@ Purpose is a constant set to 47' (or 0x8000002F) following the BIP43 recommendat

===Coin type===

The coin type field is identical to the same field in BIP44
Wallets which only support one coin type and use BIP-44 SHOULD set this value per BIP-44

Wallets which support multiple coin types and do not use version 3 payment codes SHOULD create a different payment code for each coin type and set this value per BIP-44.

Wallets which support version 3 payment codes should use one payment code per logical user identity regardless of the number of coin types the wallet supports and SHOULD set this value to 0'.

Hardened derivation is used at this level.

@@ -101,10 +105,13 @@ Currently specified versions:
* Version 2
** Address type: P2PKH
** Notification type: bloom-multisig
* Version 3
** Address type: P2PKH
** Notification type: bloom-multisig
===Recommended Versions===

* Wallets which have bloom filtering capabilities SHOULD create version 2 payment codes instead of version 1 payment codes.
* Wallets which have bloom filtering capabilities SHOULD create version 2 or higher payment codes instead of version 1 payment codes.
* Version 1 payment codes are only recommended for wallets which lack access to bloom filtering capability.
==Version 1==
@@ -158,7 +165,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of
## Alice selects the private key corresponding to the designated pubkey: <pre>a</pre>
## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre>
## Alice calculates a secret point: <pre>S = aB</pre>
## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre>
## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(o, x)</pre>
### "x" is the x value of the secret point
### "o" is the outpoint being spent by the designated input
# Alice serializes her payment code in binary form.
@@ -229,7 +236,7 @@ The following actions are recommended to reduce this risk:
<img src="bip-0047/reusable_payment_codes-04.png" />
<img src="bip-0047/reusable_payment_codes-05.png" />
# Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice.
## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.
## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.
## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre>
## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre>
<img src="bip-0047/reusable_payment_codes-02.png" />
@@ -365,6 +372,37 @@ Bob detects notification transactions by adding his payment code identifier to h
Alice's wallet should spend the notification change output at the next appropriate opportunity.

==Version 3==

A user of version 3 payment codes may use the same payment code to receive payments on different blockchains without address collisions.

Version 3 payment codes behave identifically to version 2 payment codes, except as modified below.

===Representation===

====Binary Serialization====

* Byte 0: version. required value: 0x03

This comment has been minimized.

@kristovatlas

kristovatlas Sep 28, 2017

Member

consistent with previous versioning 👍

===Protocol===

====Sending====

# Prior to this prodcedure, Alice MUST ensure that Bob is capable of accepting payments on the blockchain to be used via a suitable method. Such methods are outside the scope of this specification.
# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH as follows:
## Alice selects the 0th private key derived from her payment code: <pre>a</pre>
## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre>
### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob
## Alice selects the 4 byte registered coin type for the transaction based on SLIP-0044: <pre>t</pre>

This comment has been minimized.

@kristovatlas

kristovatlas Sep 28, 2017

Member

N.B.: The coin types accepted by Bob for payment will be need to negotiated at another protocol layer since SLIP-0044 has many coins and is subject to updates.

This comment has been minimized.

@justusranvier

justusranvier Sep 28, 2017

Addressed now with a comment at the beginning of the sending procedure.

This comment has been minimized.

@kristovatlas
## Alice calculates a secret point: <pre>S = aB</pre>
## Alice calculates a scalar shared secret using the x value of S: <pre>s = SHA256(HMAC-SHA512(Sx, t))</pre>

This comment has been minimized.

@kristovatlas

kristovatlas Sep 28, 2017

Member

What is the goal of using HMAC-SHA512 here? Why was SHA512 chosen as a hash function?

This comment has been minimized.

@kristovatlas

kristovatlas Sep 28, 2017

Member

Note: Adding HMAC-SHA512 doesn't require the addition of any new functions to BIP47 implementations, as it is used for calculating the blinding factor of the notification transaction. 👍

This comment has been minimized.

@justusranvier

justusranvier Sep 28, 2017

HMAC-SHA512 is also part of BIP-32, so it's a hash function you can guarantee is available in any HD wallet.

### If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again.
## Alice uses the scalar shared secret to calculate the ephemeral public key used to generate the P2PKH address for this transaction: <pre>B' = B + sG</pre>
# Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice.
## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.
## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre>
## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre>
==Test Vectors==

* [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]]

This comment has been minimized.

@kristovatlas

kristovatlas Oct 1, 2017

Member

Do we need v3 test vectors for the sake of completeness?

@@ -374,6 +412,7 @@ Alice's wallet should spend the notification change output at the next appropria
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
* [[https://github.com/satoshilabs/slips/blob/master/slip-0044.md|SLIP-0044 : Registered coin types for BIP-0044]]
* [[https://bitcoin.org/en/developer-reference#outpoint|Outpoint]]
* [[https://github.com/petertodd/dust-b-gone|dust-b-gone]]
* [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]]
ProTip! Use n and p to navigate between commits in a pull request.