BIP-0047: Reusable payment codes #159

justusranvier commented at 10:41 PM on June 20, 2015: contributor

Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds.

Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy.

Compared to stealth addresses, payment codes require less blockchain data storage.

Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction.

in bip-0047.mediawiki:None in edb0781b83 outdated

  68 | +
  69 | +====Base58 Serialization====
  70 | +
  71 | +When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form.
  72 | +
  73 | +* The version byte is: 0x37 (produces a "P" as the first character of the serialized form)

dskloet commented at 6:25 PM on June 21, 2015:

There's non mention of a version byte in the previous section. But the first byte (type) is described as 0x01, not 0x37.

in bip-0047.mediawiki:None in edb0781b83 outdated

  31 | +
  32 | +Each level has a special meaning, described in the chapters below.
  33 | +
  34 | +===Purpose===
  35 | +
  36 | +Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "47" with the most signifigant bit set to indicate hardened derivation (0x8000002F). It indicates that the subtree of this node is used according to this specification.

dskloet commented at 6:25 PM on June 21, 2015:

I don't see what this has to do with ASCII.

justusranvier commented at 11:22 PM on June 21, 2015:

The ASCII reference is a left over from before we were using a BIP number for that path level.

in bip-0047.mediawiki:None in edb0781b83 outdated

  73 | +* The version byte is: 0x37 (produces a "P" as the first character of the serialized form)
  74 | +* The payload is the binary serialization of the payment code
  75 | +
  76 | +===Protocol===
  77 | +
  78 | +In the following examples, Alice and Bob are identities with a corresponding payment codes. Alice initiates a Bitcoin transaction, and Bob is the recipient of the transaction.

dskloet commented at 6:26 PM on June 21, 2015:

Remove "a" or make "codes" singular.

in bip-0047.mediawiki:None in edb0781b83 outdated

 108 | +Alice will never again need to send a notification transaction to Bob.
 109 | +
 110 | +Bitcoins received via notification transactions require special handling in order to avoid privacy leaks:
 111 | +
 112 | +# The value of outputs received to notification addresses MUST NOT be displayed to the user as part of their spendable balance.
 113 | +# Outputs received to notification addresses MUST NOT be used as inputs for any transaction that involve ECDH calculations using any of the user's payment codes.

dskloet commented at 6:37 PM on June 21, 2015:

Since Alice got Bob's payment code out of band, I wonder if it makes sense to allow Alice to send her payment code to Bob out of band as well. That way you can avoid worrying about leaking the notification address.

justusranvier commented at 11:26 PM on June 21, 2015:

Alice getting Bob's payment code out of band might mean that it was printed on a business card which Alice got from Bob at a conference, or on paper fliers, or embedded into a DNS TXT record for a web site.

We're trying to avoid requirements for interactive communication here, in particular it would make payment codes vastly less useful if the recipient had to be online in order to receive payments.

The reason that Alice sends her payment code to Bob via a notification transaction, even if she also uses some other communication channel at the same time, is to preserve Bob's ability to recover his wallet from a seed.

dskloet commented at 7:16 PM on June 22, 2015:

Except for charity donations I can't think of any use cases where you'd want to send money without prior communication. Maybe you can include some examples in the text?

Being able to recover the wallet from a seed is a good point. Though the protocol could be changed to make Bob responsible for recording the sender payment codes in the blockchain. I'm not saying one is better than the other but I think it would be good to allow for both options. It especially worries me that the send has to take special care not to mix up the coins in the notification address.

In any case it would be good to mention the argument about being able to recover the wallet from a seed in the text.

laanwj commented at 12:12 PM on June 22, 2015: member

Ready for merging?

Edit: maybe add a reference to the discussion on mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007812.html

justusranvier commented at 12:16 PM on June 22, 2015: contributor

There's a correction to the serialization format that I want to push before this will be ready for merge.

erasmospunk commented at 2:34 PM on June 25, 2015: contributor

How do the payment codes interact with the URI scheme (BIP21) and payment protocol (BIP70)?

For the URI, there could be a new parameter paycode:

bitcoin:1FpVXFZ3ZYE6SLg8T2U1pTKgySx46rmq2Z?amount=0.01&paycode=PXXXXXXXXXX

Like this, incompatible clients will gracefully degrade. In case of the BIP72 r= parameter, it would take precedence as the spec dictates.

There could be separate BIPs that define this behavior, but it would be nice to have everything in one place.

justusranvier commented at 3:15 PM on June 25, 2015: contributor

If it would be appropriate, I could extend this pull request to update BIP 21 and/or BIP 70 as well.

justusranvier referenced this in commit 3c3798662e on Jun 25, 2015

erasmospunk commented at 1:46 AM on June 26, 2015: contributor

When we are using BIP-70 the client always gets a set of addresses (outputs) to pay, so paycodes seem redundant from a privacy perspective.

On the other hand one scenarios that comes in mind:

Alice joins an online dice game, she scans the qr-code and connects with the BIP-70 compatible server that sends her a paycode. She then replies to the server with the BIP-47 notification and the first bet transaction. This creates the dice game paycode/identity in her wallet, that she can create more transactions without talking again to the BIP-70 server. So after she won, she sends again to the dice paycode/identity (without sending again the notification) and retains her privacy. This emulates the famous 1diceXXXX address but with the additional benefit of the privacy.

Another usage is in an exchange, where you use paycodes to fill the account balance and using different address in subsequent deposits. The wallet could even send the refund address as a paycode so that the withdrawals are also privacy protected.

In BIP-47 we need a BIP-70 notification flag additionally to the Bitmessage notification. In BIP-70 an extension needs to be created to support the above use cases. Probably adding an optional bytes paycode to the message Output.

justusranvier commented at 3:01 PM on June 26, 2015: contributor

The BIP-47 workflow intentionally differs from BIP-70 in that it's designed for the payer to choose the outputs instead of the payee. This gives the sender more control over their privacy, because they have the option to use multiple blockchain transactions to complete a single business transaction.

It's also designed for a TOFU security model, where only the initial payment code exchange needs to be verified instead of every subsequent payment address.

I'm not sure how easy it would be to make that workflow fit into BIP-70.

BIP-0047: Reusable payment codes

Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses which provide useful features such as positively identifying
senders to recipients and automatically providing for transaction refunds.

Payment codes can be publicly advertised and associated with a real-life
identity without causing a loss of financial privacy.

Compared to stealth addresses, payment codes require less blockchain data
storage.

Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair,
while stealth addresses require 40 bytes per transaction.

1612a0016a

Correct serialization

Since the length of the data encoded by base58check affects the version
byte needed to produce a desired leading character, fix the length of
the payment code at 80 bytes, and correct the version byte to 0x23

114ed229d3

add mailing list discussion reference 2616c9abc3

improve Bitmessage key derivation e700392b15

Update BIP-21 URI scheme for payment code support

Incorporates suggestion by erasmospunk:

https://github.com/bitcoin/bips/pull/159#issuecomment-115277577

2e6e5cf958

justusranvier force-pushed on Jul 10, 2015

update readme 9135a1f3b2

kristovatlas commented at 3:46 AM on August 27, 2015: contributor

@justusranvier is this ready to merge?

justusranvier commented at 4:03 AM on August 27, 2015: contributor

As far as I know there is no barrier to merging it in its current form, other than lacking yet-to-be-developed BIP-70 integration, which could be the subject of a different pull request.

kristovatlas commented at 5:31 PM on August 27, 2015: contributor

@laanwj please re-consider for merging.

gmaxwell commented at 11:07 PM on September 3, 2015: contributor

I think this can be merged?

luke-jr referenced this in commit 67a5ed4c39 on Sep 3, 2015

luke-jr merged this on Sep 3, 2015

luke-jr closed this on Sep 3, 2015

luke-jr commented at 8:38 PM on February 1, 2016: member

Note: This snuck in a modification to BIP 21. I have reverted it. BIP 21 is no longer modifyable - include any changes in a new BIP or update BIP 47 with them...

kristovatlas commented at 8:46 PM on February 1, 2016: contributor

@luke-jr why did you not revert the previous 8 or so commits that were made after BIP 21 was accepted?

luke-jr commented at 10:46 PM on February 1, 2016: member

@kristovatlas They were not substantial changes, just minor corrections.

kristovatlas commented at 11:01 PM on February 1, 2016: contributor

@luke-jr Thanks for the clarification. If new BIPs such as BIP-47 imply additional kinds of identifiers to include in URI schemes, as the current BIP maintainer, would you prefer to see:

A new BIP repeating everything in the last URI Scheme BIP + the new information
A new BIP containing only the new information and including a pointer to BIP-21?
Something else?

luke-jr commented at 11:10 PM on February 1, 2016: member

A new BIP containing only the new information and including a pointer to BIP-21, seems better to me, at least in this case. It might even make sense as an additional section in BIP 47 itself.

kristovatlas commented at 1:30 AM on February 2, 2016: contributor

Thanks.

hypo-test referenced this in commit 13cd04d8e4 on Nov 25, 2018

Dezzj approved

Dezzj commented at 5:19 AM on June 19, 2023: none

Approved