Finalize BIP-47 #8
Conversation
bip-0047.mediawiki
Outdated
|
|
||
| ====Binary Serialization==== | ||
|
|
||
| * Byte 0: version. required value: 0x03 |
There was a problem hiding this comment.
consistent with previous versioning 👍
bip-0047.mediawiki
Outdated
| ### 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> | ||
| ## 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> |
There was a problem hiding this comment.
What is the goal of using HMAC-SHA512 here? Why was SHA512 chosen as a hash function? ❓
There was a problem hiding this comment.
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. 👍
There was a problem hiding this comment.
HMAC-SHA512 is also part of BIP-32, so it's a hash function you can guarantee is available in any HD wallet.
bip-0047.mediawiki
Outdated
| ## 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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Addressed now with a comment at the beginning of the sending procedure.
bip-0047.mediawiki
Outdated
| ### 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 Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window. |
There was a problem hiding this comment.
grammatical issue present also in v1 description?
0th public key derived +from+ Alice's payment code
justusranvier
force-pushed
the
bip47
branch
2 times, most recently
from
c8dac65
to
4707710
Compare
bip-0047.mediawiki
Outdated
| ## 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 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]] |
There was a problem hiding this comment.
Do we need v3 test vectors for the sake of completeness?
bip-0141: clarify the sigop count calculation for CHECKMULTISIG
This partially reverts c099104.
BIP 174: require creator to initialize empty output fields
Add BIP 350 (bech32m)
…rification BIP34 encoding clarification
…tsignal-check bip 8: simplify MUST_SIGNAL check
…ents A few lost improvements to BIP350
bip-0350: fix links for reference implementations
BIP-0039: Add Python-HDWallet package
Add another Rust implmentation of BIP-0039
The original implementation of BIP-47 in Samourai Wallet reversed the parameters in the calculation of the HMAC-SHA512 step of notification transaction blinding. This change adjusts the text to match the as-implementend behavior in deployed BIP-47 wallets and the test vectors.
Version 3 payment codes avoid address reuse when the same payment code is
used to receive payments on different blockchains.