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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Tgvgd-0003Vh-VA
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Dec 2012 11:01:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tgvgc-0002m3-2t
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Dec 2012 11:01:43 +0000
Received: by mail-oa0-f47.google.com with SMTP id h1so283173oag.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 07 Dec 2012 03:01:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.32.73 with SMTP id g9mr3060129oei.134.1354878096765; Fri,
07 Dec 2012 03:01:36 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Fri, 7 Dec 2012 03:01:36 -0800 (PST)
In-Reply-To: <CANEZrP1P-SW-SatU8hFbAM6rw1Gbvau9_8HB=yvS7V1j36VVxA@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>
Date: Fri, 7 Dec 2012 12:01:36 +0100
X-Google-Sender-Auth: GG6nBuR5tdGXCIYMButP0qbkQQ4
Message-ID: <CANEZrP1WRT21KZwFGAkhbAUNbNKX+xs-d3ZfEM52wYBa=4hWXw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
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: 1Tgvgc-0002m3-2t
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 11:01:44 -0000
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).
Maybe don't require the payment URI to be HTTPS. If you want to pay a
Tor hidden service then HTTPS just adds unnecessary complexity. Just
recommend to merchants that they use an encrypted connection and leave
it at that.
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. Perhaps rather than "zero value outputs will be ignored" say, "if
some outputs have value and others don't, the user will be given the
option of overpaying and the extra money will be split evenly between
the zero valued outputs". That way a waitress can have the phone add a
zero-valued output to her own wallet and that would prompt the wallet
software to display some convenient UI for adding on 10% or whatever.
receiptURI -> receipt_url ? technically it has to be resolvable so
"uri" isn't quite right.
"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.
Re: the UI TODO - agreed but let's take it out of the BIP and maybe
make it an alternative document. Or just replace it with a
recommendation that "the user interface should be designed to ensure
users understand the difference between an unsigned and signed payment
request, for best practices see <here>"
serialized_paymentrequest -> serialized_payment_request? Otherwise
languages that use CamelCase will look odd ....
setSerializedPaymentrequest()
The question of root CAs still needs resolution. I stick with my
recommendation to support all CAs that browsers support. Obviously,
it's better for a merchant to obtain an EV cert than a domain
verification cert - the UI can reflect the higher level of
verification.
I doubt there's a need to specify a max number of certs in a chain.
But if you want to, go for something high, like 256. There's no point
in trying to put DoS mitigations into something like this, for the
same reason HTML doesn't impose a maximum page size. It's in the
message builders interest to ensure it gets read by all users.
Crashing their clients doesn't achieve anything as long as the crash
isn't exploitable.
On Fri, Dec 7, 2012 at 11:45 AM, Mike Hearn <mike@plan99.net> wrote:
>> OK. I want to keep the signature field required, though, so how about:
>>
>> signature: digital signature over a protocol buffer serialized variation of
>> the SignedPaymentRequest message where signature is a zero-byte array and
>> fields are serialized in numerical order (all current protocol buffer
>> implementations serialize fields in numerical order), using the public key
>> in pki_data.
>
> Looks good to me.
|
