From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TJBD2-0000EV-Bx for bitcoin-development@lists.sourceforge.net; Tue, 02 Oct 2012 22:45:00 +0000 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; Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TJBD1-0004JQ-Ft for bitcoin-development@lists.sourceforge.net; Tue, 02 Oct 2012 22:45:00 +0000 Received: by wibhq12 with SMTP id hq12so1151558wib.10 for ; Tue, 02 Oct 2012 15:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.106.9 with SMTP id gq9mr500874wib.12.1349217893234; Tue, 02 Oct 2012 15:44:53 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.159.131 with HTTP; Tue, 2 Oct 2012 15:44:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 00:44:53 +0200 X-Google-Sender-Auth: zDWm90FHGWwPyqYJIzOTOz-tol0 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1TJBD1-0004JQ-Ft Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment protocol thoughts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:45:00 -0000 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.