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

@justusranvier justusranvier commented Jun 20, 2015

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)

This comment has been minimized.

@dskloet

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


===Purpose===

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.

This comment has been minimized.

@dskloet

dskloet Jun 21, 2015

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

This comment has been minimized.

@justusranvier

justusranvier Jun 21, 2015
Author Contributor

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

===Protocol===

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.

This comment has been minimized.

@dskloet

dskloet Jun 21, 2015

Remove "a" or make "codes" singular.

Bitcoins received via notification transactions require special handling in order to avoid privacy leaks:

# The value of outputs received to notification addresses MUST NOT be displayed to the user as part of their spendable balance.
# 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.

This comment has been minimized.

@dskloet

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

This comment has been minimized.

@justusranvier

justusranvier Jun 21, 2015
Author Contributor

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.

This comment has been minimized.

@dskloet

dskloet Jun 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
Copy link
Member

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

@justusranvier justusranvier commented Jun 22, 2015

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

@erasmospunk
Copy link
Contributor

@erasmospunk erasmospunk commented Jun 25, 2015

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

@justusranvier justusranvier commented Jun 25, 2015

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
Incorporates suggestion by erasmospunk:

bitcoin#159 (comment)
@erasmospunk
Copy link
Contributor

@erasmospunk erasmospunk commented Jun 26, 2015

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

@justusranvier justusranvier commented Jun 26, 2015

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
@justusranvier justusranvier force-pushed the OpenBitcoinPrivacyProject:master branch from 3c37986 to 2e6e5cf Jul 10, 2015
@kristovatlas
Copy link
Contributor

@kristovatlas kristovatlas commented Aug 27, 2015

@justusranvier is this ready to merge?

@justusranvier
Copy link
Contributor Author

@justusranvier justusranvier commented Aug 27, 2015

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

@kristovatlas kristovatlas commented Aug 27, 2015

@laanwj please re-consider for merging.

@gmaxwell
Copy link
Contributor

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

@kristovatlas kristovatlas commented Feb 1, 2016

@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 luke-jr commented Feb 1, 2016

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

@kristovatlas
Copy link
Contributor

@kristovatlas kristovatlas commented Feb 1, 2016

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

@kristovatlas kristovatlas commented Feb 2, 2016

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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.