Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.181 as permitted sender)
	client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f181.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
References: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
	<CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
Date: Wed, 3 Oct 2012 00:44:53 +0200
Message-ID: <CANEZrP3iot94HW17HpdH9ALMehMQKtRYY0LEe88FgRqU3BAchw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol thoughts
Precedence: list

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.