diff options
| author | Peter Vessenes <peter@coinlab.com> | 2012-10-02 10:52:04 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-10-02 17:52:31 +0000 |
| commit | 3ca8f4807790b18dc5290e837be0f61e21d336d8 (patch) | |
| tree | 30ace4189a4185002bba3acdc40c5c40e547b3ee | |
| parent | accf4ceabd10b7313d9d0b0bf425120d3b0863c5 (diff) | |
| download | pi-bitcoindev-3ca8f4807790b18dc5290e837be0f61e21d336d8.tar.gz pi-bitcoindev-3ca8f4807790b18dc5290e837be0f61e21d336d8.zip | |
Re: [Bitcoin-development] Payment protocol thoughts
| -rw-r--r-- | 7e/a8923a8871652b710e49e22b6ec2e7ea1d4eeb | 272 |
1 files changed, 272 insertions, 0 deletions
diff --git a/7e/a8923a8871652b710e49e22b6ec2e7ea1d4eeb b/7e/a8923a8871652b710e49e22b6ec2e7ea1d4eeb new file mode 100644 index 000000000..2a07dccbc --- /dev/null +++ b/7e/a8923a8871652b710e49e22b6ec2e7ea1d4eeb @@ -0,0 +1,272 @@ +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 <peter@coinlab.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com> +References: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com> + <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com> +From: Peter Vessenes <peter@coinlab.com> +Date: Tue, 2 Oct 2012 10:52:04 -0700 +Message-ID: <CAMGNxUuqyASMxu6DyL0n1_k7+Xt-3yeXbP8txiRjdUFrQtHNjA@mail.gmail.com> +To: Gavin Andresen <gavinandresen@gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Payment protocol thoughts +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 +> +> + + +-- +------------------------------ + +[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<div><br></div><d= +iv>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> + +<div><br></div><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.</div><div><br><div><br><div class= +=3D"gmail_quote"> + +On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <span dir=3D"ltr"><<a hr= +ef=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail= +.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + +<div>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.</div><div><br></div><div>Absolutely critical:</d= +iv> + + +<div><br></div><div>+ 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.= +</div> + + +<div><br></div></blockquote><div><br></div><div>I'm trying but can'= +t think of a lightweight solution to this off the top of my head. Not that = +that proves much.</div><div>=A0</div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + +<div></div><div>+ 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.</div><div>=A0</d= +iv> + +</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= +order-left:1px #ccc solid;padding-left:1ex"><div></div><div>+ Protocol for = +gathering signatures from multiple devices (extension/variation of the basi= +c payment protocol, I think).</div> + +<div><br></div></blockquote><div>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</div> + +<div><br></div><div>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</div> + +<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= +border-left:1px #ccc solid;padding-left:1ex"><div></div><div>Not absolutely= + necessary, but I think v1 should have it anyway:</div> +<div><br></div><div>+ 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.</div><div><br></div><div><br></div> + + +<div>Everything else I think can wait.</div><span class=3D"HOEnZb"><font co= +lor=3D"#888888"><div><br></div>-- <br>--<br>Gavin Andresen<br><br> +</font></span><br>---------------------------------------------------------= +---------------------<br> +Don't let slow site performance ruin your business. Deploy New Relic AP= +M<br> +Deploy New Relic app performance management and know exactly<br> +what is happening inside your Ruby, Python, PHP, Java, and .NET app<br> +Try New Relic at no cost today and get our sweet Data Nerd shirt too!<br> +<a href=3D"http://p.sf.net/sfu/newrelic-dev2dev" target=3D"_blank">http://p= +.sf.net/sfu/newrelic-dev2dev</a><br>_______________________________________= +________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><hr styl= +e=3D"font-family:Times;font-size:medium;border-right-width:0px;border-botto= +m-width:0px;border-left-width:0px;border-top-style:solid;border-top-color:r= +gb(204,204,204);margin:10px 0px"> + +<p style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1= +em"><span style=3D"color:rgb(50,90,135);text-transform:uppercase"><img src= +=3D"http://coinlab.com/static/images/email_logo.jpg" align=3D"right" alt=3D= +"CoinLab Logo" width=3D"130">PETER=A0<span style=3D"font-weight:bold">VESSE= +NES=A0</span><br> + +<span style=3D"color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p><p= + style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1em= +"><span style=3D"color:rgb(96,58,23);font-size:0.9em"><strong><a href=3D"ma= +ilto:peter@coinlab.com" style=3D"text-decoration:none;color:rgb(96,58,23)" = +target=3D"_blank">peter@coinlab.com</a>=A0</strong>=A0/=A0=A0206.486.6856 = +=A0/=A0<span style=3D"font-size:0.7em;text-transform:uppercase">SKYPE:</spa= +n>=A0vessenes=A0</span><br> + +<span style=3D"color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase= +">811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104</span></p><b= +r> +</div></div> + +--e89a8f646b07456b2504cb172f51-- + + |