Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TJ6dz-00031V-6v for bitcoin-development@lists.sourceforge.net; Tue, 02 Oct 2012 17:52:31 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.223.175 as permitted sender) client-ip=209.85.223.175; envelope-from=peter@coinlab.com; helo=mail-ie0-f175.google.com; Received: from mail-ie0-f175.google.com ([209.85.223.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TJ6dy-0005Qw-4t for bitcoin-development@lists.sourceforge.net; Tue, 02 Oct 2012 17:52:31 +0000 Received: by iebc13 with SMTP id c13so16235162ieb.34 for ; Tue, 02 Oct 2012 10:52:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Z2Bc2Mw4g3B2EeWCn4o+PHfHLocvKp8+9J0yHpJyAuE=; b=aA3Hjn/Zb3kkPx3fPob9LrQ7J1UGlPHbWjZoRbZzKzulCh89kZSSZk2uyQO0cLUZhV BMnlJGWPm4pz2pG9j1PTYRpboi4S9coxA7s9STZn1jHT3Za8V4BvGWihlxzGgKltjGfX HExuQOKXoALxIm5+cgNh+XabztunFqQ/1MzVC40dQnAR3eogofOW9z0EiWL41hRYqoI/ TeDwHIXpeS4Y3mppqHt9V3n+Re3ws/vkOpJ79KWjUNRgDsa9EpJ6S+MGbbiOs1JpquR2 EdCutrsrcNaroDN6o0Up08Xsuqz6SBdzZQCnJIvcR4QgUiF/nDowT7PO70csdyvxLXaW JJPg== Received: by 10.50.11.194 with SMTP id s2mr9723424igb.24.1349200344607; Tue, 02 Oct 2012 10:52:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.216.137 with HTTP; Tue, 2 Oct 2012 10:52:04 -0700 (PDT) In-Reply-To: References: From: Peter Vessenes Date: Tue, 2 Oct 2012 10:52:04 -0700 Message-ID: To: Gavin Andresen Content-Type: multipart/alternative; boundary=e89a8f646b07456b2504cb172f51 X-Gm-Message-State: ALoCoQm6Q8OIwiJO8bC42etY9hi1r3Und9zndilSSwRTC9+4f+wa6UkfdH3bsvuApGLqtiuuKu2W X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1TJ6dy-0005Qw-4t 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 17:52:31 -0000 --e89a8f646b07456b2504cb172f51 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > -- ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 --e89a8f646b07456b2504cb172f51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are tons of scenarios, some discussed here on this list previously, w= hich would benefit from out of band messages and notes.=A0

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

I presume that's because they use web wallets witho= ut double-click prevention. But, seriously! A tiny UI issue that's a bi= g 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 proble= ms 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 donat= ion link for "Bitcoin Foundation" in an email message and click o= n 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.
=A0
+ After sending payment I should have a receipt that proves= I followed the payee's instructions, so if the payee says they never r= eceived the funds I can prove that it wasn't my fault.
=A0
+ Protocol for = gathering signatures from multiple devices (extension/variation of the basi= c payment protocol, I think).

With the foundation trying to operate with= out 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 majo= rity spend rules.=A0

When we talk about stuff like this, I come back around = to thinking there should be many different GUIs -- this use case is more bu= siness-y, it's stuff like this that I always think about the bitcoin te= sting project helping provide -- a standard backend that a bookkeeping GUI = could go on top of..=A0
=A0
Not absolutely= necessary, but I think v1 should have it anyway:

+ Where-to-send-refund information included with paymen= ts, so overpayments/refunds can be handled efficiently and displayed intell= igently 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 AP= M
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104

--e89a8f646b07456b2504cb172f51--