I've recently heard about "Reusable Payment Codes" (BIP 47), and it sounds like a great feature, except that I couldn't find a simple explanation of how they work.

Can anybody explain them please?

  • FYI: I haven't followed the details on this BIP, but an earlier name for (I think) a similar proposal was "Stealth Address". – Jannes Jan 6 '16 at 15:08

The gist of the reusable payment code BIP is that you can gain some measure of address privacy by combining BIP32 (hierarchical deterministic wallets) with Diffie-Hellman key exchange. To understand what this means, let's figure out what the current situation of bitcoin wallets is.

Originally, in the reference client, bitcoin wallets simply generated random numbers for private keys, which in turn created a bunch of random addresses. This worked great for sending and receiving, but for privacy, it's not so great. If you publish your address, for example, everyone knows exactly how much you're receiving to that address since the blockchain is a public ledger.

Next came along Deterministic Wallets from Armory. This allowed a single seed to generate a virtually infinite number of addresses. That is, you can generate a single wallet from 256 bits (or less) and get as many addresses as you need. This allowed people to send Armory watch-only wallets to each other and get paid that way. Much better for privacy since you're generally only supposed to use new addresses, but once someone is in possession of your watch-only wallet, they know all the transactions in and out of that wallet. Better than it being public, of course, but still something to be desired when it comes to financial privacy, if, say, your employer was paying you via an Armory watch-only wallet, they know exactly how much of that has been moved and so on.

Then came HD wallets (hierarchical deterministic wallets) which allow you to have multiple levels of wallets from a single seed. Now you can send one person one watch-only wallet (xpub in BIP32 parlance) and another person another watch-only wallet and they won't know anything about what the other one is doing. Again, better for privacy, but now you have to give out different watch-only wallets to everyone you're dealing with, which can get messy.

Reusable Payment Codes is essentially a single code (essentially an xpub from BIP32) that you can publish that creates a new wallet when combined with any other HD wallet. This works via Diffie-Hellman key exchange where the sender uses the xprv from their HD Wallet and combine that with the receiver's xpub to come up with essentially a wallet that only the receiver can open but both the sender and receiver can determine the addresses of. As part of the key exchange, the sender has to send the receiver their xpub so the payments can be bi-directional. If you need a refund, for instance, the Payment Code is symmetric so a wallet going the other way can be deterministically be known to both sides. A refund can be sent to the payment code without crazy work-arounds that typify the current bitcoin landscape.

Reusable Payment Codes are essentially a way to identify yourself without leaking any information about how much was received by or sent to that payment code. Addresses, deterministic wallets and HD wallets all do not have this ability.

  • Great answer, thanks Jimmy! I asked a similar question recently, perhaps you can weigh in on this? – Wizard Of Ozzie Jan 6 '16 at 23:34
  • This is a good explanation in general, but the paragraph about the reusable payment codes is a bit vague. If the receiver can determine the address, how come he cannot "watch" that address? Does the payment code being bidrectional mean the same code can be used for payments from A to B and from B to A? – shx2 Jan 8 '16 at 4:55
  • The sender and receiver both know the combined wallet, but they don't know about any other wallets. This is nice from a privacy perspective. And yes, the payment code being bidirectional means that if A know's B's payment code, B must know A's payment code so two different wallets can be made one that sends from A to B and another that sends from B to A. BTW, if you want a more thorough answer, please ask a StackeExchange question so I have more room to elaborate =) – Jimmy Song Jan 19 '16 at 1:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.