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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
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 1WGAFk-0006AZ-1W
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 16:44:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.177 as permitted sender)
client-ip=209.85.214.177; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f177.google.com;
Received: from mail-ob0-f177.google.com ([209.85.214.177])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGAFi-0007nI-MK
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 16:44:07 +0000
Received: by mail-ob0-f177.google.com with SMTP id wp18so688363obc.36
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Feb 2014 08:44:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.122.133 with SMTP id ls5mr8068261obb.52.1392828241187;
Wed, 19 Feb 2014 08:44:01 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Wed, 19 Feb 2014 08:44:00 -0800 (PST)
Received: by 10.76.71.231 with HTTP; Wed, 19 Feb 2014 08:44:00 -0800 (PST)
In-Reply-To: <CAJHLa0MGaxJTGPR-bduW36-4Msb348FANqFmw67jqFxq1CLwbw@mail.gmail.com>
References: <le05ca$qn5$1@ger.gmane.org> <5303B110.70603@bitpay.com>
<le0jvf$i7d$1@ger.gmane.org>
<CAJHLa0MGaxJTGPR-bduW36-4Msb348FANqFmw67jqFxq1CLwbw@mail.gmail.com>
Date: Wed, 19 Feb 2014 16:44:00 +0000
X-Google-Sender-Auth: TeX6gQbhXh7U6vybNjm465jv54I
Message-ID: <CANEZrP1QS1Z0_=-sUjK2H5CkrnuCUsCu5PZhggAvEbW4Y2Y_kA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=001a1134a7e48c99ac04f2c51871
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: 1WGAFi-0007nI-MK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP70 proposed changes
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: Wed, 19 Feb 2014 16:44:08 -0000
--001a1134a7e48c99ac04f2c51871
Content-Type: text/plain; charset=UTF-8
Thanks for the feedback guys!
I would also like to understand the problems you've been having with
certificates in node.js. FYI the CA cert is *not* supposed to be included,
this matches what the code in Bitcoin Core and bitcoinj expects. It may be
that Bitcoin Core accepts a redundant CA cert being provided, but if so
that'd fall in the category of openssl being generous. If there are issues
here, it sounds like an issue with node and not the spec. I'm not even sure
why it would matter - certs are just byte arrays so if node can sign a hash
with a private key, the rest should be easy.
With regards to the PKI I'd appreciate it if we don't go around that circle
again. Please remember one of the primary goals of all of this is to show
to the user on their hardware wallet a meaningful name. Almost all
merchants on the Internet already went through the process of associating a
public key with their name, using X.509.
Whilst for now your payment requests will have to be signed as BitPay, this
isn't ideal for the longer term and I'd like to design a protocol extension
to allow merchants to delegate their signature authority to you. In this
way they would be able to sign a secondary key with their own ssl key as
part of the enrolment process, and after that you could sign payment
requests on their behalf. Kind of like a Bitcoin specific subcert (and
there would be no reason to use X.509 format for that).
Re: feedback url. How is this different to a result code in PaymentAck
which already caused much debate? Surely we want a payment to either work
out boy work and for that decision to be made immediately? Your invoice
page switches to a completed state once you see a tx be broadcast so that's
the "done" state today even if there are caveats. I'd like to see a status
code added to PaymentAck so receivers can reject payments if they are bad
in some way.
On 19 Feb 2014 19:41, "Jeff Garzik" <jgarzik@bitpay.com> wrote:
> On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach
> <andreas@schildbach.de> wrote:
> > On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
> >> BitPay is working on a new standard
> >> based on bitcoin-like addresses for authentication. It would be great if
> >> we could work with the community to establish a complete, decentralized
> >> authentication protocol.
> >
> > Sounds interesting, let us know as soon as you have anything.
>
> SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a1134a7e48c99ac04f2c51871
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Thanks for the feedback guys!</p>
<p dir=3D"ltr">I would also like to understand the problems you've been=
having with certificates in node.js. FYI the CA cert is *not* supposed to =
be included, this matches what the code in Bitcoin Core and bitcoinj expect=
s. It may be that Bitcoin Core accepts a redundant CA cert being provided, =
but if so that'd fall in the category of openssl being generous. If the=
re are issues here, it sounds like an issue with node and not the spec. I&#=
39;m not even sure why it would matter - certs are just byte arrays so if n=
ode can sign a hash with a private key, the rest should be easy.</p>
<p dir=3D"ltr">With regards to the PKI I'd appreciate it if we don'=
t go around that circle again. Please remember one of the primary goals of =
all of this is to show to the user on their hardware wallet a meaningful na=
me. Almost all merchants on the Internet already went through the process o=
f associating a public key with their name, using X.509.</p>
<p dir=3D"ltr">Whilst for now your payment requests will have to be signed =
as BitPay, this isn't ideal for the longer term and I'd like to des=
ign a protocol extension to allow merchants to delegate their signature aut=
hority to you. In this way they would be able to sign a secondary key with =
their own ssl key as part of the enrolment process, and after that you coul=
d sign payment requests on their behalf. Kind of like a Bitcoin=C2=A0 speci=
fic subcert (and there would be no reason to use X.509 format for that).</p=
>
<p dir=3D"ltr">Re: feedback url. How is this different to a result code in =
PaymentAck which already caused much debate? Surely we want a payment to ei=
ther work out boy work and for that decision to be made immediately? Your i=
nvoice page switches to a completed state once you see a tx be broadcast so=
that's the "done" state today even if there are caveats. I&#=
39;d like to see a status code added to PaymentAck so receivers can reject =
payments if they are bad in some way.<br>
</p>
<div class=3D"gmail_quote">On 19 Feb 2014 19:41, "Jeff Garzik" &l=
t;<a href=3D"mailto:jgarzik@bitpay.com">jgarzik@bitpay.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach<br>
<<a href=3D"mailto:andreas@schildbach.de">andreas@schildbach.de</a>> =
wrote:<br>
> On 02/18/2014 08:14 PM, Ryan X. Charles wrote:<br>
>> BitPay is working on a new standard<br>
>> based on bitcoin-like addresses for authentication. It would be gr=
eat if<br>
>> we could work with the community to establish a complete, decentra=
lized<br>
>> authentication protocol.<br>
><br>
> Sounds interesting, let us know as soon as you have anything.<br>
<br>
SINs. =C2=A0See <a href=3D"https://en.bitcoin.it/wiki/Identity_protocol_v1"=
target=3D"_blank">https://en.bitcoin.it/wiki/Identity_protocol_v1</a><br>
<br>
--<br>
Jeff Garzik<br>
Bitcoin core developer and open source evangelist<br>
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"=
_blank">https://bitpay.com/</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>
--001a1134a7e48c99ac04f2c51871--
|
