Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIP-0047: Reusable payment codes #159

Merged
merged 6 commits into from Sep 3, 2015

Conversation

justusranvier
Copy link
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.


When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form.

* The version byte is: 0x37 (produces a "P" as the first character of the serialized form)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@laanwj
Copy link
Member

laanwj commented Jun 22, 2015

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
Copy link
Contributor Author

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

@erasmospunk
Copy link
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
Copy link
Contributor Author

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

justusranvier added a commit to OpenBitcoinPrivacyProject/bips that referenced this pull request Jun 25, 2015
@erasmospunk
Copy link
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
Copy link
Contributor Author

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.

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.
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
@kristovatlas
Copy link
Contributor

@justusranvier is this ready to merge?

@justusranvier
Copy link
Contributor Author

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
Copy link
Contributor

@laanwj please re-consider for merging.

@gmaxwell
Copy link
Contributor

gmaxwell commented Sep 3, 2015

I think this can be merged?

luke-jr added a commit that referenced this pull request Sep 3, 2015
@luke-jr luke-jr merged commit 67a5ed4 into bitcoin:master Sep 3, 2015
@luke-jr
Copy link
Member

luke-jr commented Feb 1, 2016

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
Copy link
Contributor

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

@luke-jr
Copy link
Member

luke-jr commented Feb 1, 2016

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

@kristovatlas
Copy link
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
Copy link
Member

luke-jr commented Feb 1, 2016

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
Copy link
Contributor

Thanks.

hypo-test pushed a commit to hypo-test/BitcoinBips-713993353 that referenced this pull request Nov 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants