Support BIP47 V1 Payment Codes

[kmels]

Overview

BIP47 allows merchants to transact in bitcoin multiple times without exchanging bitcoin addresses. It improves the privacy of users by using a different deposit address in every payment. Senders and recipients set up a shared secret together when the payer sends a "notification transaction" containing his payment code wrapped in an OP_RETURN output. After this notification is broadcasted and received, the recipient's wallet uses BIP32 with the secret key to generate his future deposit addresses in advance and maintains a configurable look ahead.

Version 1 of Payment Codes support notification transactions with up to 3 outputs: the minimum allowed spend of 546 satoshis to the recipient, the OP_RETURN output with the payment code and possibly a change to the payer.

Considerations for integrating BIP47

When the recipient's PeerGroup is disconnected and needs to catchup with the blockchain, a race condition occurs between the notification and the payment transaction when encountering a filteredBlock in Peer. We solved this problem by making BlockChain#rollbackBlockStore public and calling it everytime to replay a block everytime we see a notification transaction to guarantee that the notification is processed first.

Goals

• Send and receive BIP47 transactions using SPV wallets and V1 payment codes
• Provide unit tests for BIP47 vector tests

[coveralls]

Coverage decreased (-0.9%) to 76.354% when pulling bb396718b21f19fe122d5bce972f666b9def68e0 on kmels:cash_bip47 into d3d6998a710254cb94225fe8581e245703967868 on bitcoinj-cash:cash.

[HashEngineering]

I have worked with BIP47 before and it is rather interesting.

What other software supports BIP47? Samourai for Bitcoin.

For Bitcoin Cash: https://play.google.com/store/apps/details?id=com.stash.wallet

BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

[kmels]

I edited the description to clarify: BIP47 payments use different deposit addresses on each payment but it's not always the case that it eliminates the possibility of linking two transactions from the sender..

Afaik the first wallet to implement BIP47 was Samourai in 2016. Currently there is also Billion for iOS (https://billionapp.com/) and Stash Wallet for Android (on which I work). I am finishing a tutorial to go with this PR, should be ready soon.

[HashEngineering]

I reviewed this code and have a few questions:

1. BIP47 transactions uses addresses derived from m/47H/0H/0? If so how does bitcoinj track these while it syncs with the blockchain. The wallet object (which uses m/0H or BIP32) creates bloom filters and then bitcoinj will receive relevant transactions. I see the BIP47 account is created separately from the Wallet object, so I don't see how BIP47 transactions are followed.

2. How do you spend from the Wallet and the BIP47 account as if they are a single entity?

[kmels]

Neat.. :dagger:

1. Yes, but it the identity part is hardened too: m/47H/0H/0H. So, there are two parts to follow BIP47 transactions, firstly the notification address needs to be watched. After setAccount() is called, the notification address can be derived and then vWallet.addWatchedAddress(notificationAddress) is invoked. Secondly for payments, the transaction listener checks if isNotificationTransaction is true, then it imports the contact, creates the channel and invokes generateKeys intially. If there is a new payment, generateNewBip47IncomingAddress is used.

2. A wallet entity should be able to hold many BIP47 accounts (identities). For example one for paying the rent and another for buying coffees. But right now the implementation only sets *one bip47 account. So it is technically the same entity right now. In order to support more accounts, we could use a new coin selector that doesn't mix the accounts (ideally), also the wallet would need to check what contacts belong to what accounts too. Right now is version 1.. so even the coin_type is fixed to 0' (Bitcoin)

[HashEngineering]

ok, thanks for the answers.

[kmels]

BIP47 Tutorial PR submitted: https://github.com/bitcoinj/bitcoinj.github.io/pull/31

Preview: http://htmlpreview.github.io/?https://raw.githubusercontent.com/kmels/bitcoinj.github.io/bip47_render/_site/payment-codes.html

[justusranvier]

@shadders Is there something about this pull request that needs to be changed before it can be merged?

[shadders]

Hi Justus,

Apologies I only just saw this now. Been busy working on the op codes. I'll have a look at it asap.

On Sat, May 5, 2018, 12:43 AM Justus Ranvier notifications@github.com wrote:

@shadders https://github.com/shadders Is there something about this pull request that needs to be changed before it can be merged?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoinj-cash/bitcoinj/pull/39#issuecomment-386623648, or mute the thread https://github.com/notifications/unsubscribe-auth/AA52iPsG70b9yKbwaCbQA1vB3rKLDkg9ks5tvGkVgaJpZM4TtSvq .

[HashEngineering]

I am reopening this because it is still under consideration.