Implement BIP47 to improve fungilbility

[gary-rowe]

Worth a discussion given the current privacy concerns of people using Bitcoin.

Primary concerns:

• Significant burden on SPV bloom filters (special mode?)
• Potentially complex UI

Related material:

• BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
• Reddit: https://www.reddit.com/r/Bitcoin/comments/3alzga/bip47_reusable_payment_codes/

Other wallets considering it:

• Breadwallet (see #289)
• Copay (see #3032)
• Core (see #6568)

This is not a trivial piece of work and would require dedicated effort to accomplish.

[xbtdev]

+1 for bip47 support.

http://samouraiwallet.com/ is nearly done implementing bip47, afaik.

[justusranvier]

@gary-rowe Regarding UI complexity, the BIP probably doesn't explain this as well as it could, but the intent is to minimize UI complications.

If you're already doing BIP-44, then your UI already supports accounts. Each account should have one payment code. This was inspired by Darkwallet's approach of displaying one stealth address per account.

There's no need to distinguish between incoming transactions sent to a BIP-44 address and the corresponding payment code for that account - display them all in the same list.

The intent is that what the users experience as an "account" is the union of the BIP-44 account and the payment code.

In your list of incoming transactions for an account, you can add a "from" column that displays the sender's payment code (or address book name), and simply leave this field blank if the incoming transaction was sent to BIP-44 address rather than to the payment code.

[kristovatlas]

+1 for BIP47 support. A number of wallet clients are now working on this, so Multibit HD wouldn't be the only client compatible.

[jim618]

Implementing BIP47 is problematic for MultiBit HD mainly because of how we access the Bitcoin network. It is similar, but more difficult, than support for BIP44 accounts which we haven't implemented.

Here is a write up from an offline discussion Gary and I had:

BIP47 is basically:

1) Alice sends Bob a notification bitcoin transaction with an OP_RETURN nonce 2) Both Alice and Bob use the nonce to work out an ECDH shared secret. 3) Alice and Bob can then create an HD account (that only they know about ) to use for their transactions.

There are various aspects to implementing this:

A) It's a substantial amount of work

B) It requires implementing account support in bitcoinj wallets. As Mike is off the team there isn't really anyone to do this other than us.

C) Every payment code would create a new account. With a lookahead of 20 (same as BIP44) each payment code adds a minimum of 20 private keys into the wallet. These never expire. This is x20 'private key expansion' compared to what we have now.

D) It is trivially easy for users to spam your wallet as they can just send, say, 100 notification transactions. Each of these creates 20 private keys, thus exogenously 2000 private keys are forced into your wallet. We've been seeing significant slow down of syncing when we get wallets in the 1000+ private keys range in MultiBit Classic. HD syncs faster than Classic but the network architecture is basically the same.

E) The ECDH shared secret is unrelated to the wallet words derivation. Thus you cannot recreate your wallet from your wallet words once you start using reusable payment codes. You need a backup of the reusable payment codes to recreate the accounts. This breaks our 'wallet words promise' that if you keep your wallet words safe you can always recover your bitcoin. For entry level users it will be complicated to explain that their wallet words now no longer work "properly".

[justusranvier]

E is not true.

The payment code is derived from the same seed as the rest of the wallet, assuming a BIP-43-derived wallet structure.

The ECDH shared secrets are fully recoverable from this seed - see the section in BIP-47 describing exactly how to perform this function.

It does make sense to implement BIP-44 before BIP-47, since BIP-47 assumes a BIP-44 (or equivalent) structure.

[jim618]

@justusranvier Thanks for the correction on the recoverability of the ECDH shared secrets from the seed. (https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki#Wallet_Recovery).

[kristovatlas]

A) definitely true. Maybe it will get easier as other wallets implement. B) probably true, not familiar enough with BitcoinJ to say whether you definitely need this support or not. Maybe a consortium of funded projects using BitcoinJ could collaborate. C) There's definitely a challenge here with querying all of the derived addresses, but I don't think it is unmanageable. Look-ahead does not necessarily need to be 20 -- indeed, it's not clear to me how a client would ever manage to miss 19 addresses in a row when sending since it's a sender/receiver pair-wise derivation. Additionally, once you receive a payment at a given address, you probably do not not frequently need to re-check that address in the future, because there's no good reason for someone to send a payment to that address in the future. What we need here is smarter algorithms for deciding which addresses are most pertinent for the user and how often to check up on them, but that just seems like a general challenge for SPV wallets. It's entirely possible that adopting a protocol that strongly emphasizes avoiding address reuse will reduce and not increase the total number of addresses you need to frequently query for balance information and utxo selection.

[kristovatlas]

D) See my answer for C above. I'm not saying it's trivial to come up with these smarter algorithms, but it's doable.