Support for payment codes (bip47)

@cculianu and I had a short conversation and I promised to put the details here.

Related:

• Bip47 - Payment Codes
• Cash Account Protocol for better UX
• Cash Account Issue: #1035 (I know some of you prefer another name - I don’t control that so please discuss that issue over there : )
• a hack to create payment codes through EC

Basically it allows creation of a private channel between two seeds with one notification transaction that happens in the clear (but does not reveal the identity of the sending party). The way the standard is written is to bolt the bip47 features onto any bip44 wallet by deriving a parallel bip32 branch from the same seed. Then if a wallet adds support for payment codes, you basically get payment code functionality for free on all of your bip44 wallets. It can also apply to non-bip44 wallets although it would require some custom alignment between the two.

This is one idea of how it could be incorporated if EC decides payment codes are a good idea.

(note: In my opinion, the multi-wallet changes required below would be a higher priority than the payment code)

Concept

• EC notices a wallet is bip44, maybe by assuming that m/44'/x'/i' wallets are bip44
• EC watches the parallel bip47 branch for notification transactions (one notification transaction is required to setup the secret channel).
• The secret wallet becomes available as a separate element in EC, perhaps a new tab for secret wallets. The secret wallet is defined by the pair of payment codes so that would be its unique identity (see below for UX features that would make it user friendly).
• The separate wallet is only for sending to the counterparty so I guess it would need a somewhat different interface for transactions.
• Because this is privacy focused, a lot of care needs to be taken to follow the protocol when working on the 47' path. Probably other places too.

UX bonuses

• EC checks with a cashaccount indexer to see if this account already has a payment code registered. If so, it picks that up and uses it as the identity for the users’s side of any secret channels. (it could have several for a given payment code, so maybe let the user choose an identity for each payment code).
• If there is not already an identity, EC offers to go register one for the user. Provide a name and it gets registered on the next block. Having the parallel bip47 branch is what allows EC to make the payment code.
• If EC picks up any notification transactions on the payment code, it does the lookup for the other side’s identity. The receiver can know the other side’s payment code / identity through the notification transaction, but the world cannot. Neat.

[imaginaryusername]

I don’t exactly oppose BIP47 if progress on RPA is deemed too sluggish to continue - I like RPA more and think it solves a few more problems BIP47 doesn’t (I wrote the specs, duh), but am not gonna stand in way of progress of some form of reusable address. I guess since @fyookball is spearheading the implementation it’s up to him to assess the prospects of RPA in the near future.

[cculianu]

Thanks for putting this together.

I like this idea but the real implementation will of course be extensive. It would require Electron Cash to do what no wallet has done before: fully implement BIP47 derivation paths… and monitor something on an alternate path. Would be cool to have, for sure. 😃

We’ll leave this open and on the table, of course.