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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VrWW4-00034M-6o
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Dec 2013 17:27:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VrWW1-0004RF-Fa
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Dec 2013 17:27:08 +0000
Received: by mail-oa0-f51.google.com with SMTP id i7so2370158oag.38
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Dec 2013 09:27:00 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.16.33 with SMTP id c1mr2541495obd.4.1386955620002; Fri,
13 Dec 2013 09:27:00 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.92.72 with HTTP; Fri, 13 Dec 2013 09:26:59 -0800 (PST)
In-Reply-To: <CABsx9T0VEu15KXH_XPn+cAERQFz=Tmjqna6ZoNpLrxkzeKw9kQ@mail.gmail.com>
References: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
<CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
<CANEZrP33bRx6abbXcf6nQYiPXFOOWSsZJqiFZY+A08x6O3X+pg@mail.gmail.com>
<CABsx9T0VEu15KXH_XPn+cAERQFz=Tmjqna6ZoNpLrxkzeKw9kQ@mail.gmail.com>
Date: Fri, 13 Dec 2013 09:26:59 -0800
X-Google-Sender-Auth: 2kUp-qTFwMnYnrzcwFRE45wsikc
Message-ID: <CANEZrP1ha6y-w1Cpq+7t1ogUwNmxSobEREY2tawp7bcFGRPKiw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04479f930cd03a04ed6dc5c1
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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: payr.com]
X-Headers-End: 1VrWW1-0004RF-Fa
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Paul Rabahy <prabahy@gmail.com>
Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection
encryption
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, 13 Dec 2013 17:27:08 -0000
--f46d04479f930cd03a04ed6dc5c1
Content-Type: text/plain; charset=UTF-8
>
> Why would there be an iteration count? The payer would handle that,
> wouldn't they?
>
I'm thinking about a use case I hope will become common next year -
pastebin style hosting sites for payment requests. Like, if I as a regular
end user wish to use the payment protocol, I could just upload a (possibly
signed) payment request to:
payr.com/a62gahZ
or whatever, and then payr.com can take care of incrementing the iteration
count on each download of my file. That's why it's useful for it to be
unsigned.
> If the use case is: I give the Foundation a "here's where to pay my
> salary" PaymentRequest, maybe with several Outputs each having a different
> xpubkey, then it seems to me the Foundation's wallet software should take
> care of iterating.
>
Absolutely. The two use cases can both be supported. You could give
iteration ranges, for instance, if you want to specify expiry in terms of
number of payments rather than time.
--f46d04479f930cd03a04ed6dc5c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Why would there be an=
iteration count? The payer would handle that, wouldn't they?</span></d=
iv></div></div></div></blockquote><div><br></div><div>I'm thinking abou=
t a use case I hope will become common next year - pastebin style hosting s=
ites for payment requests. Like, if I as a regular end user wish to use the=
payment protocol, I could just upload a (possibly signed) payment request =
to:</div>
<div><br></div><div><a href=3D"http://payr.com/a62gahZ">payr.com/a62gahZ</a=
></div><div><br></div><div>or whatever, and then <a href=3D"http://payr.com=
">payr.com</a> can take care of incrementing the iteration count on each do=
wnload of my file. That's why it's useful for it to be unsigned.</d=
iv>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><span style=
=3D"color:rgb(34,34,34)">If the use case is: =C2=A0I give the Foundation a =
"here's where to pay my salary" PaymentRequest, maybe with se=
veral Outputs each having a different xpubkey, then it seems to me the Foun=
dation's wallet software should take care of iterating.</span></div>
</div></div></div></blockquote><div><br></div><div>Absolutely. The two use =
cases can both be supported. You could give iteration ranges, for instance,=
if you want to specify expiry in terms of number of payments rather than t=
ime.</div>
</div></div></div>
--f46d04479f930cd03a04ed6dc5c1--
|
