diff options
author | Mike Hearn <mike@plan99.net> | 2014-03-28 16:23:10 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-28 15:23:16 +0000 |
commit | 21b56371342f62f4d29b165bf805e45ae7ed66d0 (patch) | |
tree | 067750daf69b4b5d6c2af6cd1b65df917ec02aa8 | |
parent | 2c0f637f1edc5acdcc58d1e58d496490d356dc33 (diff) | |
download | pi-bitcoindev-21b56371342f62f4d29b165bf805e45ae7ed66d0.tar.gz pi-bitcoindev-21b56371342f62f4d29b165bf805e45ae7ed66d0.zip |
Re: [Bitcoin-development] BIP 70 refund field
-rw-r--r-- | 63/aa4db5da60bfdbb533fc304cb4624060626a5d | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/63/aa4db5da60bfdbb533fc304cb4624060626a5d b/63/aa4db5da60bfdbb533fc304cb4624060626a5d new file mode 100644 index 000000000..8b2d8c100 --- /dev/null +++ b/63/aa4db5da60bfdbb533fc304cb4624060626a5d @@ -0,0 +1,152 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1WTYcm-0000eb-Im + for bitcoin-development@lists.sourceforge.net; + Fri, 28 Mar 2014 15:23:16 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.44 as permitted sender) + client-ip=209.85.219.44; envelope-from=mh.in.england@gmail.com; + helo=mail-oa0-f44.google.com; +Received: from mail-oa0-f44.google.com ([209.85.219.44]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WTYcl-00036f-Ji + for bitcoin-development@lists.sourceforge.net; + Fri, 28 Mar 2014 15:23:16 +0000 +Received: by mail-oa0-f44.google.com with SMTP id n16so6312249oag.31 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 28 Mar 2014 08:23:10 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.173.99 with SMTP id bj3mr1684942oec.55.1396020190286; + Fri, 28 Mar 2014 08:23:10 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 08:23:10 -0700 (PDT) +In-Reply-To: <85A1792C-502E-4AC6-B8BC-A10C8FC1917F@bitsofproof.com> +References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com> + <612FFAAD-14FF-4261-927D-BD2E0F287257@bitsofproof.com> + <D7D06593-1987-490A-8DCD-21922E022E39@bitsofproof.com> + <CABsx9T1POJ3KTqSz_c=SdYTg=EKWa9jqjOpHPZoMoPGXozsvJA@mail.gmail.com> + <85A1792C-502E-4AC6-B8BC-A10C8FC1917F@bitsofproof.com> +Date: Fri, 28 Mar 2014 16:23:10 +0100 +X-Google-Sender-Auth: TNyLh7qS7uaKoMUpULQ0WLjYgyo +Message-ID: <CANEZrP26+hWJaFYkZ2oUKhr9FQ03CXCdvt8V1Mm4mGJaPCy2Hw@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Tamas Blummer <tamas@bitsofproof.com> +Content-Type: multipart/alternative; boundary=047d7ba9818c8a9b7404f5ac47fc +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 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 + 1.0 HTML_MESSAGE BODY: HTML included in message + 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: 1WTYcl-00036f-Ji +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] BIP 70 refund field +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, 28 Mar 2014 15:23:16 -0000 + +--047d7ba9818c8a9b7404f5ac47fc +Content-Type: text/plain; charset=UTF-8 + +So I take it BOPShop won't be supporting BIP70 then? :( + + +On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer <tamas@bitsofproof.com>wrote: + +> I have nothing against incremental development. This will however not pick +> up until it offers some incremental benefit compared to current payment +> processor solutions, +> such as e.g. +> +> 1. Symmetrical. One can also offer a payment. +> 2. Aggregating and Netting. Handle multiple installments and/or net with +> previous cash flows. +> 3. More secure. One has a check not only on the payment address (which +> already has one with https:// in the web shop scenario it is currently +> able support) but not on the refund. +> +> +> On 28.03.2014, at 15:01, Gavin Andresen <gavinandresen@gmail.com> wrote: +> +> On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <tamas@bitsofproof.com>wrote: +> +>> May I ask how the current payment protocol is supposed to handle salaries? +>> +> +> It doesn't. +> +> "walk before you run" and all that; lets see what problems we run into +> with the minimal payment protocol we have now (like refund outputs you have +> to remember forever) before we create an insurmountable set of problems by +> trying to solve everything we can think of all at once. +> +> -- +> -- +> Gavin Andresen +> +> +> + +--047d7ba9818c8a9b7404f5ac47fc +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">So I take it BOPShop won't be supporting BIP70 then? := +(</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri= +, Mar 28, 2014 at 3:27 PM, Tamas Blummer <span dir=3D"ltr"><<a href=3D"m= +ailto:tamas@bitsofproof.com" target=3D"_blank">tamas@bitsofproof.com</a>>= +;</span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>I h= +ave nothing against incremental development. This will however not pick up = +until it offers some incremental benefit compared to current payment proces= +sor solutions,=C2=A0</div> +<div>such as e.g.</div><div><br></div><div>1. Symmetrical. One can also off= +er a payment.</div><div>2. Aggregating and Netting. Handle multiple install= +ments and/or net with previous cash flows.</div><div>3. More secure. One ha= +s a check not only on the payment address (which already has one with https= +:// in the web shop scenario it is currently able support) but not on the r= +efund.</div> +<div><div class=3D"h5"><div><br></div><div> +<br><div><div>On 28.03.2014, at 15:01, Gavin Andresen <<a href=3D"mailto= +:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>>= + wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"g= +mail_extra"> +<div class=3D"gmail_quote">On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer <= +span dir=3D"ltr"><<a href=3D"mailto:tamas@bitsofproof.com" target=3D"_bl= +ank">tamas@bitsofproof.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">May I as= +k how the current payment protocol is supposed to handle salaries?</div></b= +lockquote> + +<div><br></div><div>It doesn't.</div><div><br></div><div>"walk bef= +ore you run" and all that; lets see what problems we run into with the= + minimal payment protocol we have now (like refund outputs you have to reme= +mber forever) before we create an insurmountable set of problems by trying = +to solve everything we can think of all at once.</div> + +</div><div><br></div>-- <br>--<br>Gavin Andresen<br> +</div></div> +</blockquote></div><br></div></div></div></div></blockquote></div><br></div= +> + +--047d7ba9818c8a9b7404f5ac47fc-- + + |