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

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

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.

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

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.

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.

@justusranvier is this ready to merge?

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.

@laanwj please re-consider for merging.

I think this can be merged?

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...

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

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

@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?

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.

Thanks.