Add link to BIP47 test vectors #257

Results obtained upon implementing BIP47 for Samourai Wallet. Payment codes are calculated assuming v1 specification without use of BitMessage. Also assumes notification transaction from Alice to Bob has been sent.

Hello,

I am trying to very the payment codes using bitcore. For the first, simplest, case:

Master seed: b7b8706d714d9166e66e7ed5b3c61048

Payment code should be: "PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA"

But this is what I get:

1. Master seed: b7b8706d714d9166e66e7ed5b3c61048

2. Master xpriv: xprv9s21ZrQH143K2oD6EPXhzTGnQ6rcGedZRKc2j46W8FUbx2CrhQXpMWerpMfJjDgtpezs6N15qnrM8CQjma4FRNfK8Ec9yUAF6VFEy6ZZt6c

3. Master xpub xpub661MyMwAqRbcFHHZLR4iMbDWx8h6g7MQnYXdXSW7gb1appY1Ewr4uJyLfe3MrVWAFpBkkbMJD1iFSv2HYV4mMHys3MEmPVg2CRskCw8Pm7M

4. 47'/0'/0' xpriv: xprv9yh5yLTKjyvKEjEAPciUAP8JY4TkB2KdDwqHM5K3FY1i9JjiGknuA6tWV69W3bp9LVUKVYJMPARTfLf5cBhFqmLJuNSFchEz1PjY57siDHY

5. 47'/0'/0' xpub: xpub6CgSNqzDaMUcTDJdVeFUXX5366JEaV3UbAkt9TieosYh274rpJ79huCzLM1oB1t8RKLsuKE5fT5Zqyysi9cJaayC9UX6GNZ31EpoEQJcfrC

6. 47'/0'/0' xpub relevant data

chainCode: '6d22f48b78b68898b5e41df6ff4f800fa03bc7e1beb3d2155c86e2934010c34b', publicKey: '025a50e3baddb98f48672f4ad32c7558482a562ed9a26279c9b58a113d5b38f6b0',

7. paymentCode in HEX 0100025a50e3baddb98f48672f4ad32c7558482a562ed9a26279c9b58a113d5b38f6b06d22f48b78b68898b5e41df6ff4f800fa03bc7e1beb3d2155c86e2934010c34b00000000000000000000000000

8. base58check paymentcode:

PM8TJNp5z9XVg3NQzgiBSccj2FUw2EkT4aqsZtAmRioHH31oHvHxCW9fHirkr5rMSHkJVzsNMkBcevfPwJujdep8tqnDuAwsU5aAEuT3cda7m7QyEhwQ

So which is incorrect, @SamouraiDev's test vectors, or bitcore's implementation?

When comparing these two tools:

https://bip32jp.github.io/english/ https://bitcore.io/playground/#/hdkeys

only the first one allows me to enter a seed directly as hex.

When I put in the root xpriv that bip32jp.github.io calculates into bitcore.io, both agree that m/47'/0'/0' is:

xprv9z4XcXV3eLXcvuA72k9mcMAjFtqYoY8QsFLmc5G9bGnAAwJtr9CuMqME9BsaAhddpBsq2w2Xc6XLWmLG1RHfquXb4dy9yehambtmLT6iJuR

and

xpub6D3t231wUi5v9PEa8mgmyV7Tovg3CzrGEUGNQTfm9cK93je3PgX9udfhzUDx29pkeeHQBPpTSHpAxnDgsf2XRbvLrmbCUQybjtHx8SUb3JB

The issue appears to be a difference between how Bitcore calculates the root node from a seed and how Samourai calculates a root node from a seed.

When I put the hex seed from BIP32 test vector 1 into bip32jp.github.io (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Test_Vectors), it produces the wrong root xpriv.

test vector: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi

bip32jp.github.io: xprv9s21ZrQH143K2XojduRLQnU8D8K59KSBoMuQKGx8dW3NBitFDMkYGiJPwZdanjZonM7eXvcEbxwuGf3RdkCyyXjsbHSkwtLnJcsZ9US42Gd

It appears that there was some confusion about the use of the 'hex seed' to define the wallet. This is the BIP39 hex seed. The document has been changed to reflect that and the mnemonic codes for each wallet have been provided to avoid any ambiguity.

Witch compiler version ?

On Sat, 5 Dec 2015 19:52 T Dev D notifications@github.com wrote:

It appears that there was some confusion about the use of the 'hex seed' to define the wallet. This is the BIP39 hex seed. The document has been changed to reflect that and the mnemonic codes for each wallet have been provided to avoid any ambiguity.

— Reply to this email directly or view it on GitHub #257 (comment).

@SamouraiDev @justusranvier Can you tell me, for HMAC-SHA512(x,o), what o is, specifically, and whether the donation is indicating x and o are data and salt, respectively? I can calculate Alice's S0, but I'm stuck on this part. Perhaps clarification in the BIP?

"o" is the outpoint being spent by the first pubkey-exposing input of the transaction. The inputs sent by Alice must not be associated with her notification address. Basically, they can come from anywhere which is why I didn't include notification transactions in the test vectors. Currently I'm using the bitcoinj serialization of the outpoint hex identifier.

@wizardofozzie A notification transaction must expose a public key in its input scripts, so the recipient can perform an ECDH calculation. By BIP47 protocol, the recipient looks at the first exposed pubkey for by checking appropriate script types in the inputs. (we should probably enumerate those in BIP47).

If we only used the ECDH secret to blind the payment code in the notification transaction, there's a possibility that somebody might make a client that re-uses a public key. (if the first input for two notification transactions spends funds from the same address) and use the same blinding factor more than once.

To make sure the binding factor is always unique, we take an HMAC that uses the ECDH secret and the outpoint of the input which provides the public key. Since causing an outpoint collision is infeasible, this insures the binding factor is always different, even if a public key is improperly reused.

@SamouraiDev @justusranvier Ok, I think I see where the outpoint comes from now. Is that value, o, included in the test vectors? Also to clarify, is o the outpoint's txid, or are we using the pubkey? If it's the pubkey being used, are we keeping the 02 or 03?

Also, can you please clarify HMAC-SHA512(x, o)? Are we concatenating x and o? Or is x the payload, and o is the salt? (ie o is like the optional password from BIP39)

@wizardofozzie o is the complete output, serialized exactly as it appears in a transaction.

See here for definition: https://bitcoin.org/en/glossary/outpoint

x is the shared secret derived as part of the BIP-47 notification procedure.

HMAC-SHA512(x, o) notation comes from RFC 2104. (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Definition_.28from_RFC_2104.29)

Whatever library you use for BIP-32 should also provide HMAC-SHA215.

@SamouraiDev @justusranvier Can we have some example TxIDs? The Twitter feed for @SamouraiDev mentions bad5802e2183be44007b6b94395113d7cb513dbeb68d40245a83f5fadfcc76f3. What is this Tx showing?

@justusranvier Fantastic! FYI I'm writing a bip47.py for my fork of pybitcointools

я в этих таблицах и формулах нечего не понимаю

Четверг, 17 декабря 2015, 16:29 -08:00 от WizardOfOzzie notifications@github.com:

@SamouraiDev @justusranvier Ok, I think I see where the outpoint comes from now. Is that value, o, included in the test vectors? Also to clarify, is o the outpoint's txid, or are we using the pubkey? If it's the pubkey being used, are we keeping the 02 or 03? Also, can you please clarify HMAC-SHA512(x, o)? Are we concatenating x and o? Or is x the payload, and o is the salt? (ie o is like the optional password from BIP39) — Reply to this email directly or view it on GitHub .

@wizardofozzie Notifications transactions were not included in the test vectors. Only the calculation of payment addresses was covered. Here is a notification transaction that uses the same Alice & Bob wallets as in the test vectors: https://live.blockcypher.com/btc/tx/9414f1681fb1255bd168a806254321a837008dd4480c02226063183deb100204/

Added BIP32 hex seed values following suggestions by caedes from darkwallet.

@SamouraiDev I finally understand how this works! Genius! Can I recommend rephrasing phrases such as "Alice selects the private key corresponding to the first exposed public key, of the first pubkey-exposing input, of the transaction". To me, that is downright confusing. Perhaps even:

"Alice selects the private key (a) corresponding to the first exposed public key (A), of the first P2PKH input, for Alice's transaction (Atx)"

@justusranvier ACK/NACK?

Would you embed the test vectors into the actual BIP document as opposed to an external link?

@justusranvier

enter a seed directly as hex.

You misunderstand. The site does not say "enter seed" but it says "enter entropy."

It does not use the hex string you input directly as a seed. It uses the entry as entropy to derive the BIP39 phrase.

@luke-jr @jprichardson

I agree with this PR as it stands, and I also agree that merging it into the main text is advisable.

I'd rather see this merged to avoid holding up progress, and then anyone with the cycles/motivation to do the merge into a single document submit that as a separate PR.