diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2012-12-07 11:19:12 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-07 16:19:30 +0000 |
| commit | 5ca4ebd910047a1889fea98c2ee601bde4f400eb (patch) | |
| tree | 5807b5e2eabcfe961f1a7dc684e3a7627031eb28 | |
| parent | c9ebfdcc98766b057c6e9bdf2844c9476966aab6 (diff) | |
| download | pi-bitcoindev-5ca4ebd910047a1889fea98c2ee601bde4f400eb.tar.gz pi-bitcoindev-5ca4ebd910047a1889fea98c2ee601bde4f400eb.zip | |
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
| -rw-r--r-- | 53/6c2c12416b84cbcf61b996240990a60b9bf036 | 240 |
1 files changed, 240 insertions, 0 deletions
diff --git a/53/6c2c12416b84cbcf61b996240990a60b9bf036 b/53/6c2c12416b84cbcf61b996240990a60b9bf036 new file mode 100644 index 000000000..438d26c4a --- /dev/null +++ b/53/6c2c12416b84cbcf61b996240990a60b9bf036 @@ -0,0 +1,240 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gavinandresen@gmail.com>) id 1Th0eA-00088t-8R + for bitcoin-development@lists.sourceforge.net; + Fri, 07 Dec 2012 16:19:30 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.43 as permitted sender) + client-ip=74.125.82.43; envelope-from=gavinandresen@gmail.com; + helo=mail-wg0-f43.google.com; +Received: from mail-wg0-f43.google.com ([74.125.82.43]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Th0e5-0004vZ-U9 + for bitcoin-development@lists.sourceforge.net; + Fri, 07 Dec 2012 16:19:30 +0000 +Received: by mail-wg0-f43.google.com with SMTP id e12so317645wge.10 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 07 Dec 2012 08:19:19 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.216.145.160 with SMTP id p32mr2115032wej.44.1354897153169; + Fri, 07 Dec 2012 08:19:13 -0800 (PST) +Received: by 10.194.27.136 with HTTP; Fri, 7 Dec 2012 08:19:12 -0800 (PST) +In-Reply-To: <CANEZrP1WRT21KZwFGAkhbAUNbNKX+xs-d3ZfEM52wYBa=4hWXw@mail.gmail.com> +References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com> + <20121128233619.GA6368@giles.gnomon.org.uk> + <CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com> + <20121129170713.GD6368@giles.gnomon.org.uk> + <CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com> + <20121129185330.GE6368@giles.gnomon.org.uk> + <CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com> + <CANEZrP2riPBViBqAOWfY9uSQwoEm=gN108JU988XvouMbai1Ug@mail.gmail.com> + <CABsx9T023aw11cq6iiZhT3cgfNYJXr=qG40Fzc7rYZOimJ=62w@mail.gmail.com> + <50C03BDA.6010600@petersson.at> + <CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com> + <CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com> + <CANEZrP2VLsh0mi=saQ0ZOnjVijUHoqEMxTG3LHcaCb2Ua-f-gQ@mail.gmail.com> + <CABsx9T23Lpju6Pz87G1uuQ=gjdKhNh=rMCmmv9=vj2ikONwONQ@mail.gmail.com> + <CANEZrP1P-SW-SatU8hFbAM6rw1Gbvau9_8HB=yvS7V1j36VVxA@mail.gmail.com> + <CANEZrP1WRT21KZwFGAkhbAUNbNKX+xs-d3ZfEM52wYBa=4hWXw@mail.gmail.com> +Date: Fri, 7 Dec 2012 11:19:12 -0500 +Message-ID: <CABsx9T3MkK-aWKv34G4GwR-HafYiz1t5sK4xsvX4jP6_xq8QPA@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=0016e6d647e5859a8704d04593d7 +X-Spam-Score: -0.6 (/) +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 + (gavinandresen[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 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: 1Th0e5-0004vZ-U9 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Payment Protocol Proposal: + Invoices/Payments/Receipts +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: Fri, 07 Dec 2012 16:19:30 -0000 + +--0016e6d647e5859a8704d04593d7 +Content-Type: text/plain; charset=ISO-8859-1 + +On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn <mike@plan99.net> wrote: + +> Yet more comments (I guess at some point we need to stick a fork in it +> - or at least move on to implementing a prototype version). +> + +Yes, my next step is prototyping. + +Note that this is not a BIP yet: I want to have a working implementation +before making this an Official BIP. + + +> Maybe don't require the payment URI to be HTTPS. + + +Changed: + receipt_url: Secure (usually https) location where... + +Though it's not strictly necessary, it'd be nice to have defined +> behavior for if you want to pay more than the requested amount, for a +> tip. + + +yeah... I had similar thoughts on what to do if some Outputs specify an +amount and others don't. I'm still waffling on whether or not I like +allowing repeated Outputs; a single Output would make the spec a fair bit +simpler, and if a merchant wants to split up a payment for some reason they +could just generate another transaction. + +I want to move on to actually implementing this before creating complicated +rules. Maybe the best way to tip a waitress is to get two separate +PaymentRequests, one for the restaurant and one that goes directly to the +waitress (depends on whether or not the restaurant needs or wants to know +how much their employees are getting tipped, I suppose). Maybe it would be +best to have a separate "gratuity" Output in the PaymentRequest. That's the +kind of detail I think doesn't need to be worked out right now, I'd rather +restaurants tell us what they need/want. + + +> "Display the proposed Outputs in as human-friendly a form as possible" +> .... ??? Surely you'd just display the total amount requested? I don't +> think it ever makes sense to try and display outputs to the user +> directly. +> + +This is the case of getting an UNSIGNED payment request; I've changed the +wording a little to make that more clear. + +If a bitcoin client accepts unsigned payment requests (a couple of people +have asked if that would be possible so I think that is desired), then it +doesn't have the payer's identity-- all it has is the Outputs that will be +paid. + + + +> Re: the UI TODO - agreed but let's take it out of the BIP... + + +Not a BIP yet.... + +serialized_paymentrequest -> serialized_payment_request? + + +Done. + + +> The question of root CAs still needs resolution. I stick with +> my recommendation to support all CAs that browsers support. + + +I still like the idea of only including the root CAs who have jumped +through the hoops needed to get the "allowed to issue EV certs" blessing. + I'm not suggesting that all bitcoin merchants must get EV certs, but I am +suggesting that they must get a certificate from one of the most reputable +certificate authorities, and the ability to issue EV certificates is, I +think, a good proxy for that. + +But, again: Not a BIP yet. Lets get something implemented and then hammer +out details (implementing always turns up edge cases you forgot when +spec'ing). + + +-- +-- +Gavin Andresen + +--0016e6d647e5859a8704d04593d7 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D= +"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> w= +rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= +=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Yet more comments (I guess at some point we need to stick a fork in it<br> +- or at least move on to implementing a prototype version).<br></blockquote= +><div><br></div><div>Yes, my next step is prototyping.</div><div><br></div>= +<div>Note that this is not a BIP yet: =A0I want to have a working implement= +ation before making this an Official BIP.</div> +<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= +border-left:1px #ccc solid;padding-left:1ex"> +Maybe don't require the payment URI to be HTTPS.</blockquote><div><br><= +/div><div>Changed:</div><div>=A0 =A0receipt_url: Secure (usually https) loc= +ation where...</div><div><br></div><blockquote class=3D"gmail_quote" style= +=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Though it's not strictly necessary, it'd be nice to have defined<br= +> +behavior for if you want to pay more than the requested amount, for a<br> +tip.</blockquote><div><br></div><div>yeah... I had similar thoughts on what= + to do if some Outputs specify an amount and others don't. I'm stil= +l waffling on whether or not I like allowing repeated Outputs; a single Out= +put would make the spec a fair bit simpler, and if a merchant wants to spli= +t up a payment for some reason they could just generate another transaction= +.</div> +<div><br></div><div>I want to move on to actually implementing this before = +creating complicated rules. Maybe the best way to tip a waitress is to get = +two separate PaymentRequests, one for the restaurant and one that goes dire= +ctly to the waitress (depends on whether or not the restaurant needs or wan= +ts to know how much their employees are getting tipped, I suppose). =A0Mayb= +e it would be best to have a separate "gratuity" Output in the Pa= +ymentRequest. That's the kind of detail I think doesn't need to be = +worked out right now, I'd rather restaurants tell us what they need/wan= +t.</div> +<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= +border-left:1px #ccc solid;padding-left:1ex"> +"Display the proposed Outputs in as human-friendly a form as possible&= +quot;<br> +.... ??? Surely you'd just display the total amount requested? I don= +9;t<br> +think it ever makes sense to try and display outputs to the user<br> +directly.<br></blockquote><div><br></div><div>This is the case of getting a= +n UNSIGNED payment request; I've changed the wording a little to make t= +hat more clear.</div><div><br></div><div>If a bitcoin client accepts unsign= +ed payment requests (a couple of people have asked if that would be possibl= +e so I think that is desired), then it doesn't have the payer's ide= +ntity-- all it has is the Outputs that will be paid.</div> +<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Re: the UI TODO= + - agreed but let's take it out of the BIP...</blockquote><div><br></di= +v> +<div>Not a BIP yet....</div><div><br></div><blockquote class=3D"gmail_quote= +" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">s= +erialized_paymentrequest -> serialized_payment_request?</blockquote><div= +> +<br></div><div>Done.</div><div>=A0</div><blockquote class=3D"gmail_quote" s= +tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The = +question of root CAs still needs resolution. =A0I stick with my=A0recommend= +ation to support all CAs that browsers support.</blockquote> +<div><br></div><div>I still like the idea of only including the root CAs wh= +o have jumped through the hoops needed to get the "allowed to issue EV= + certs" blessing. =A0I'm not suggesting that all bitcoin merchants= + must get EV certs, but I am suggesting that they must get a certificate fr= +om one of the most reputable certificate authorities, and the ability to is= +sue EV certificates is, I think, a good proxy for that.</div> +<div><br></div><div>But, again: =A0Not a BIP yet. =A0Lets get something imp= +lemented and then hammer out details (implementing always turns up edge cas= +es you forgot when spec'ing).</div><div><br></div></div><div><br></div> +-- <br>--<br>Gavin Andresen<br><br> + +--0016e6d647e5859a8704d04593d7-- + + |