1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
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--
|
