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

Support BIP47 V1 Payment Codes #39

Open
wants to merge 2 commits into
base: cash
from

Conversation

Projects
None yet
5 participants
@kmels
Copy link

kmels commented Apr 30, 2018

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

@kmels kmels changed the title Add BIP47 V1 Support BIP47 V1 Payment Codes Apr 30, 2018

@coveralls

This comment has been minimized.

Copy link

coveralls commented Apr 30, 2018

Coverage Status

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

@HashEngineering

This comment has been minimized.

Copy link
Collaborator

HashEngineering commented May 2, 2018

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

This comment has been minimized.

Copy link

kmels commented May 2, 2018

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

This comment has been minimized.

Copy link
Collaborator

HashEngineering commented May 2, 2018

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

This comment has been minimized.

Copy link

kmels commented May 2, 2018

Neat.. 🗡

  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

This comment has been minimized.

Copy link
Collaborator

HashEngineering commented May 3, 2018

ok, thanks for the answers.

@shadders shadders closed this May 4, 2018

@justusranvier

This comment has been minimized.

Copy link

justusranvier commented May 4, 2018

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

@shadders

This comment has been minimized.

Copy link

shadders commented May 5, 2018

@HashEngineering

This comment has been minimized.

Copy link
Collaborator

HashEngineering commented May 5, 2018

I am reopening this because it is still under consideration.

@usatie usatie referenced this pull request Jul 18, 2018

Open

Reusable Payment Codes #9

@akifuji akifuji referenced this pull request Aug 21, 2018

Open

Reusable Payment Codes #89

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment