BIP47: TL;DR

BIP-0047

Payment Code: {version}{features}{bitmessage}{public_key}{chain-code}{reserved}

Version 1

Setup

• Alice derives Bob’s notification address from his payment code (see BIP32)
• Alice computes payment code using a shared secret (Alice’s private key and Bob’s public key)
• Alice sends notification tx to Bob with payment code in OP_RETURN data
• Bob watches for transactions to his notification address
• Bob decodes Alice’s payment code using the shared secret

To anonymize payments, Alice may use an ephemeral payment code which is a hardened child of her original payment code.

Transfer

• Alice derives 0th private key from her payment code
• Alice derives next unused public key from Bob’s payment code (local counter)
• Alice computes shared secret, calculates Bob’s ephemeral public key and generates P2PKH address
• Bob computes n ephemeral addresses and watches for transactions

Note that in this scheme (ECDH) it is computationally infeasible for a third party to correlate Alice’s payments to Bob.

Refund

• Bob derives Alice’s notification address from her payment code

• Bob sends notification tx to Alice with payment code in OP_RETURN data

• Bob derives 0th private key from his payment code

• Bob derives next unused public key from Alice’s payment code (local counter)

• Bob computes shared secret, calculates Alice’s ephemeral public key and generates P2PKH address

• Alice computes n ephemeral addresses and watches for transactions

Version 2

Identical to the process above, with one exception. Bob’s notification change address is calculated as a multisig:

• BOB_PAYMENT_CODE_ID: payment code identifier; 0x02${sha256(bob_payment_code).toString("hex")}
• ALICE_CHANGE_PUBKEY: notification change output; public key for Alice’s change address in tx

OP_1 <BOB_PAYMENT_CODE_ID> <ALICE_CHANGE_PUBKEY> OP_2 OP_CHECKMULTISIG

Bob should add his payment code identifier to his bloom filter to detect notification transactions.