Payment protocol thoughts

I've been thinking about the requirements for a payment protocol lately. It seems we have consensus that we need one of these. Pieter has a gist on the topic here: https://gist.github.com/1237788

IMHO we'll want to move away from "send X BTC to address Y" and more towards "upload to me transactions that send X BTC to outputs A,B....F,G". In this context by output I mean the obvious interpretation of script+value.

The reasons are privacy and security. Privacy: you don't want people to find out if you have an unexpectedly large balance (from the block chain). Example worst case scenarios

- in a hypothetical Bitcoin-using country, as most people receive income exactly once a month from their employer, you could potentially find out other peoples salaries. Drama ensues.

- business partners could find out their counterparty has an unexpectedly good financial position, messing up negotiations

Security:

- some of the outputs could be in a hot wallet, others in cold wallets, helping you maintain correct balances between them in real time

- the outputs can be multi-sig scripts

Wallets would then craft a series of transactions to try and somewhat balance the size of inputs vs outputs. Because they are separate transactions and all the keys are fresh, there's no way to link them together into a single payment, especially not if they're broadcast in random order with some jitter.

The upside of this is better privacy. The downside is obviously more transactions and therefore more overhead. In theory the sum of tx outputs would end up converging to a reasonable "coin size" for the recipients, eg, businesses might be happy to receive a lot of money in a single output, individuals less, children or very poor people maybe much less.

Let's call payment requests invoices. Here is a brainstorm on other features that may be desirable. I'm not suggesting they're all in v1, just that we think about them a bit to ensure we don't paint ourselves into a corner.

- Optional list of {signature, certificate} pairs. SSL certs can be embedded into the payment request file itself so they can be checked instantly for wallets that want to show a verified identity, but you can also provide other certificates issued outside the regular SSL CA system. For example maybe MtGox issues you a "trusted vendor" certificate. Maybe the better business bureau issues you a cert, etc.

- Optional expiry time (from sipas gist) so outputs that were never sent to can be recycled

- Upload target (URI), where to send the created transactions

- Optional message and branding image/icon that a wallet can display to make the transaction history a bit prettier

- Opaque token that the wallet is supposed to copy into the payment. The merchant can use to link invoice with payment. It's technically redundant, the output set would identify the invoice too, as could a token in the upload target URL, but it may be simpler for some merchant implementations

- Ability to specify payment amount[s] in terms of other currencies. If the amount is specified statically it can just be recorded in the wallet for informational purposes. If there's a URL provided also, it is an endpoint where quotes can be obtained. This allows merchants to make long-lived invoices which are protected against FX volatility. Downside: complicates wallets. Upsides: invoices can be kept around for longer.

- Web/human-usable URL for the order so users can, eg, send messages to the merchant specific to an order, post a review of the merchant, etc

- Support for setting up 2-of-3 dispute mediation. Invoices should be able to name a list of acceptable mediators and the wallet software can intersect this with a list of mediators acceptable to the user, to find one that works best. The whole mechanism by which merchants and users agree on mediators isn't designed yet but we can at least think about it now. It may be there's a simple design everyone agrees on already.

- Support for requesting recurring payments. Eg, I should be able to provide N sets of M outputs, one set for each payment with a payment schedule. Wallets can then ensure they run at the appropriate times to keep up the subscription.

- Suggested tip/service charge. Wallet would give a simple UI to adjust this up/down by X percentage points

- Request to sign inputs with SIGHASH_ANYONECANPAY, allowing the payment to be a pledge for an assurance contract

- Ability to specify minimum confirmation level of coins that will be spent. Some merchants may be OK with you immediately re-spending unconfirmed coins. Other merchants will care more and might want you to take on the burden of getting your transactions into the chain.

On the payment upload side:

- An optional signature under a stable user key that lets users optionally link their payments across merchants. In this way a user can build cross-market reputation which may help them in future, by relaxing confirmation requirements or reducing the chance of being asked to enter dispute mediation. Needs more thought.

- Optionally, an invoice for a refund if the merchant chooses to refund the money in the absence of dispute mediation.

- A list of Bitcoin transactions that make payments to the outputs requested in the invoice

- The opaque token provided in the invoice

Re: format. I would (surprise) strongly suggest protocol buffers over JSON. I cannot think of any justification for using JSON (for anything) but especially not for data structures that mostly contain binary data like hashes or keys. Protobufs are easier to work with in code, have a more efficient encoding, can be printed/parsed from ASCII if you need to (eg for debugging purposes) and have fewer sharp edges than JSON does.

I agree we need a payment protocol, but instead of thinking of all of the things we might possibly want I would like to solve a few boring problems that we have right now.

Absolutely critical:

+ Bitcoin addresses by themselves are insecure against man-in-the-middle attacks. We need a payment protocol so if you get a donation link for "Bitcoin Foundation" in an email message and click on it you can be reasonably certain that your coins will actually go to the Foundation and not some hacker at your ISP that modified the email message.

+ After sending payment I should have a receipt that proves I followed the payee's instructions, so if the payee says they never received the funds I can prove that it wasn't my fault.

+ Protocol for gathering signatures from multiple devices (extension/variation of the basic payment protocol, I think).

Not absolutely necessary, but I think v1 should have it anyway:

+ Where-to-send-refund information included with payments, so overpayments/refunds can be handled efficiently and displayed intelligently in the customer's wallet.

Everything else I think can wait.

There are tons of scenarios, some discussed here on this list previously, which would benefit from out of band messages and notes.

This is small, but an interesting tidbit from BTC Foundation payments; roughly 3-5% of our initial members double-spent. WOW, that's terrible.

I presume that's because they use web wallets without double-click prevention. But, seriously! A tiny UI issue that's a big deal in an irrevocable payment system.

On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <gavinandresen@gmail•com>wrote:

> I agree we need a payment protocol, but instead of thinking of all of the
> things we might possibly want I would like to solve a few boring problems
> that we have right now.
>
> Absolutely critical:
>
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks. We need a payment protocol so if you get a donation link for
> "Bitcoin Foundation" in an email message and click on it you can be
> reasonably certain that your coins will actually go to the Foundation and
> not some hacker at your ISP that modified the email message.
>
>

I'm trying but can't think of a lightweight solution to this off the top of my head. Not that that proves much.

> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.
>
>

+ Protocol for gathering signatures from multiple devices

> (extension/variation of the basic payment protocol, I think).
>
> With the foundation trying to operate without bank accounts, I think it

comes into clarity for me just how innovative and incredibly awesome this would be for financial controls for companies. Imagine the bookkeeper inputting payments, and the owner (or 2 of 3 owners) approving them. I can even imagine large member groups having 2/3 or majority spend rules.

When we talk about stuff like this, I come back around to thinking there should be many different GUIs -- this use case is more business-y, it's stuff like this that I always think about the bitcoin testing project helping provide -- a standard backend that a bookkeeping GUI could go on top of..

> Not absolutely necessary, but I think v1 should have it anyway:
>
> + Where-to-send-refund information included with payments, so
> overpayments/refunds can be handled efficiently and displayed intelligently
> in the customer's wallet.
>
>
> Everything else I think can wait.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes <peter@coinlab•com> wrote:

> This is small, but an interesting tidbit from BTC Foundation payments;
> roughly 3-5% of our initial members double-spent. WOW, that's terrible.

To be specific, do you mean

a) paid twice
     or
b) sent BF coins, then sent the same coins elsewhere
?

Double-spend is a specific technical term....

I meant sent twice, a.

No double-spends that I'm aware of. Sorry for the loose verbiage!

Peter

On Tue, Oct 2, 2012 at 11:07 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:

> On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes <peter@coinlab•com> wrote:
> > This is small, but an interesting tidbit from BTC Foundation payments;
> > roughly 3-5% of our initial members double-spent. WOW, that's terrible.
>
> To be specific, do you mean
>
> a) paid twice
>      or
> b) sent BF coins, then sent the same coins elsewhere
> ?
>
> Double-spend is a specific technical term....
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>

I think it's worth pondering the different things we may want in future, even if that future is quite far out, just to ensure we have a robust design that won't box us in later. Brainstorming feature ideas now doesn't commit anyone to implementing them, but it may help improve the final v1 design.

> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks.

A simple way to solve this problem is just use the SSL identity of the server that is taking part in the protocol, but it's not much harder to embed a signature + cert chain into the invoice itself. And once you're doing that, allowing several different sigs/cert chains is pretty easy. It means you keep the design open to cases where SSL may not be appropriate. Eg, you could create invoices signed by your web-of-trust identity, or some non-SSL Bitcoin specific verification system.

None of those things have to actually be implemented, but by considering them now we can make the protocol more future prooof.

> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.

A signed invoice + the blockchain transactions does this, BUT with a major caveat: if you have not set up dispute mediation, there is nobody to prove faultlessness to.

So I'm not sure this would be very useful. Supporting real dispute mediation seems more practical, but also more work.

> + Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).

This would be nice, I think invoices could be wrapped by another protocol that handles it. I'm not sure it needs to be a part of the core payment protocol. There are lots of different ways to implement this and I'm not sure there's agreement on what it should look like - somebody needs to build a "proprietary" implementation first.

On Tue, Oct 2, 2012 at 6:44 PM, Mike Hearn <mike@plan99•net> wrote:

> A simple way to solve this problem is just use the SSL identity of the
> server that is taking part in the protocol, but it's not much harder

SSL itself (as opposed to using the certs as you suggest) is not non-reputablable, so it's not enough for the below concerns

> A signed invoice + the blockchain transactions does this, BUT with a
> major caveat: if you have not set up dispute mediation, there is
> nobody to prove faultlessness to.

To their prospective customer base. "I can prove to the public that you ripped me off" is protective, even if there isn't formal direct remedy available.