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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1UW5tr-0000Pu-6t
for bitcoin-development@lists.sourceforge.net;
Sat, 27 Apr 2013 14:14:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.171 as permitted sender)
client-ip=209.85.217.171; envelope-from=melvincarvalho@gmail.com;
helo=mail-lb0-f171.google.com;
Received: from mail-lb0-f171.google.com ([209.85.217.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UW5tp-0003zb-G0
for bitcoin-development@lists.sourceforge.net;
Sat, 27 Apr 2013 14:14:51 +0000
Received: by mail-lb0-f171.google.com with SMTP id r11so158753lbv.16
for <bitcoin-development@lists.sourceforge.net>;
Sat, 27 Apr 2013 07:14:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.4.40 with SMTP id h8mr23933036lah.34.1367072082725; Sat,
27 Apr 2013 07:14:42 -0700 (PDT)
Received: by 10.112.143.38 with HTTP; Sat, 27 Apr 2013 07:14:42 -0700 (PDT)
In-Reply-To: <20130424144649.GB29213@theagricolas.org>
References: <CAKaEYhLNS-9MLVr1AWB0mWUMoADvd03-7KMQp77ZGCfcu8E1Qg@mail.gmail.com>
<20130424144649.GB29213@theagricolas.org>
Date: Sat, 27 Apr 2013 16:14:42 +0200
Message-ID: <CAKaEYhJPZQW1vTg=8ej6XR5Q=VMnBMPBcu3aEvaQXtoEQ5CbTA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Craig B Agricola <craig@theagricolas.org>
Content-Type: multipart/alternative; boundary=089e013d1d92df926a04db5845cc
X-Spam-Score: -0.6 (/)
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
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1UW5tp-0003zb-G0
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Web Payments <public-webpayments@w3.org>, public-rww <public-rww@w3.org>
Subject: Re: [Bitcoin-development] Sending Bitcoins using RSA keys
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: Sat, 27 Apr 2013 14:14:51 -0000
--089e013d1d92df926a04db5845cc
Content-Type: text/plain; charset=ISO-8859-1
On 24 April 2013 16:46, Craig B Agricola <craig@theagricolas.org> wrote:
> Maybe I'm missing something crucial, but what benefit does this dance give
> over
> the slightly more obvious mechanism of simply:
> 1) Alice generates a new address with her bitcoin client and sends the BTC
> to
> this new address
> 2) Alice exports the private key for that address (there is a well
> supported
> format for that)
> 3) Alice writes a nice email to Bob, including that exported private key
> 4) Alice encrypts the email with Bob's public key using GPG and sends it
> to him
> by email
> 5) Bob decrypts the email
> 6) Bob imports the private key into his wallet
>
Yes this works too.
However is it dependent on the bitcoin client address generation algorithm?
I think what I'm trying to describe is something more akin to the way a
shared secret is generated by TLS.
Agree, that the wallet is also shared, ive not yet worked out a way to
'blind' one side of the wallet, but nor have a proved it's impossible, so
still working onthat :)
>
> There's no need for sending a whole wallet; just the one key is needed.
> Every
> bit of infrastructure needed above already exists. And of course, the
> above
> has the same issue as your proposal; this is a way for two trusting
> parties to
> send BTC without using the Bitcoin network, but it's not a payment
> mechanism.
> They now share control of an address; whoever spends that BTC first wins,
> so
> until Bob uses the Bitcoin network to spend that BTC to another address
> that
> only he controls, it's still in joint custody. And if ensuring that he has
> control of the BTC is the last (implicit) step in the procedure above, as
> well
> as yours, then they might as well have simply used the Bitcoin network to
> do
> the transfer in the first place.
>
> Did I miss the point entirely?
>
Perhaps I've not described the problem statement as clearly as I could,
I'll work on it. Essentially it's an automated way to bootstrap the RSA
key community together with bitcoin. e.g. 99% of GPG users probably dont
have a bitcion wallet or address or client. I think maybe a user story
will help.
>
> -Craig
>
> PS. Re-reading, I realize that the above might come off sounding snarky or
> dismissive; it's not intended that way. I'm wondering if I'm missing
> the
> big picture.
>
Not snarky at all! Appreciate the feedback...
>
> On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote:
> > So there's a slight world divide in digital payments with bitcoin using
> > ECDSA and GPG, payswarm / webid etc using largely RSA
> >
> > Here's how to bring the two worlds together and enable bitcoins be sent
> > over webid or payswarm
> >
> >
> > Problem: Alice and Bob have RSA key pairs, but no public bitcoin
> > addresses. Alice wants to send 1 BTC to Bob.
> >
> > 1. Alice takes Bob's WebID and encrpyts it with her private key (to
> create
> > entropy) ...
> >
> > 2. Alice uses that message as the seed to produce btc address (as per
> > http://brainwallet.org ) with ECDSA key pair
> >
> > 3. Alice sends coins to this address
> >
> > 4. Alice and then encrypts the seed again with Bob's public key
> >
> > 5. Bob decrypts the seed using his private key
> >
> > 6. Bob can now use the seed to recreate the wallet and spend the coins
> >
> > Unless I've made an error, I believe this unites the web paradigm and
> > crypto currency paradigm into one potentially giant eco system ...
>
> >
> ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_apr
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e013d1d92df926a04db5845cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 April 2013 16:46, Craig B Agricola <span dir=3D"ltr"><<a h=
ref=3D"mailto:craig@theagricolas.org" target=3D"_blank">craig@theagricolas.=
org</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">Maybe I'm missing something crucial, but=
what benefit does this dance give over<br>
the slightly more obvious mechanism of simply:<br>
1) Alice generates a new address with her bitcoin client and sends the BTC =
to<br>
=A0 =A0this new address<br>
2) Alice exports the private key for that address (there is a well supporte=
d<br>
=A0 =A0format for that)<br>
3) Alice writes a nice email to Bob, including that exported private key<br=
>
4) Alice encrypts the email with Bob's public key using GPG and sends i=
t to him<br>
=A0 =A0by email<br>
5) Bob decrypts the email<br>
6) Bob imports the private key into his wallet<br></blockquote><div><br></d=
iv><div>Yes this works too.<br><br>However is it dependent on the bitcoin c=
lient address generation algorithm?<br><br></div><div>I think what I'm =
trying to describe is something more akin to the way a shared secret is gen=
erated by TLS.<br>
<br></div><div>Agree, that the wallet is also shared, ive not yet worked ou=
t a way to 'blind' one side of the wallet, but nor have a proved it=
's impossible, so still working onthat :)<br></div><div>=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
<br>
There's no need for sending a whole wallet; just the one key is needed.=
=A0Every<br>
bit of infrastructure needed above already exists. =A0And of course, the ab=
ove<br>
has the same issue as your proposal; this is a way for two trusting parties=
to<br>
send BTC without using the Bitcoin network, but it's not a payment mech=
anism.<br>
They now share control of an address; whoever spends that BTC first wins, s=
o<br>
until Bob uses the Bitcoin network to spend that BTC to another address tha=
t<br>
only he controls, it's still in joint custody. =A0And if ensuring that =
he has<br>
control of the BTC is the last (implicit) step in the procedure above, as w=
ell<br>
as yours, then they might as well have simply used the Bitcoin network to d=
o<br>
the transfer in the first place.<br>
<br>
Did I miss the point entirely?<br></blockquote><div><br></div><div>Perhaps =
I've not described the problem statement as clearly as I could, I'l=
l work on it.=A0 Essentially it's an automated way to bootstrap the RSA=
key community together with bitcoin.=A0 e.g. 99% of GPG users probably don=
t have a bitcion wallet or address or client.=A0 I think maybe a user story=
will help.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
=A0-Craig<br>
<br>
PS. Re-reading, I realize that the above might come off sounding snarky or<=
br>
=A0 =A0 dismissive; it's not intended that way. =A0I'm wondering if=
I'm missing the<br>
=A0 =A0 big picture.<br></blockquote><div><br></div><div>Not snarky at all!=
=A0 Appreciate the feedback...<br></div><div>=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div><div class=3D"h5"><br>
On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote:<br>
> So there's a slight world divide in digital payments with bitcoin =
using<br>
> ECDSA and GPG, payswarm / webid etc using largely RSA<br>
><br>
> Here's how to bring the two worlds together and enable bitcoins be=
sent<br>
> over webid or payswarm<br>
><br>
><br>
> Problem: Alice and Bob have RSA key pairs, but no public bitcoin<br>
> addresses. =A0Alice wants to send 1 BTC to Bob.<br>
><br>
> 1. Alice takes Bob's WebID and encrpyts it with her private key (t=
o create<br>
> entropy) ...<br>
><br>
> 2. Alice uses that message as the seed to produce btc address (as per<=
br>
> <a href=3D"http://brainwallet.org" target=3D"_blank">http://brainwalle=
t.org</a> ) with ECDSA key pair<br>
><br>
> 3. Alice sends coins to this address<br>
><br>
> 4. Alice and then encrypts the seed again with Bob's public key<br=
>
><br>
> 5. Bob decrypts the seed using his private key<br>
><br>
> 6. Bob can now use the seed to recreate the wallet and spend the coins=
<br>
><br>
> Unless I've made an error, I believe this unites the web paradigm =
and<br>
> crypto currency paradigm into one potentially giant eco system ...<br>
<br>
</div></div>> ----------------------------------------------------------=
--------------------<br>
> Try New Relic Now & We'll Send You this Cool Shirt<br>
> New Relic is the only SaaS-based application performance monitoring se=
rvice<br>
> that delivers powerful full stack analytics. Optimize and monitor your=
<br>
> browser, app, & servers with just a few lines of code. Try New Rel=
ic<br>
> and get this awesome Nerd Life shirt! <a href=3D"http://p.sf.net/sfu/n=
ewrelic_d2d_apr" target=3D"_blank">http://p.sf.net/sfu/newrelic_d2d_apr</a>=
<br>
<br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
</blockquote></div><br></div></div>
--089e013d1d92df926a04db5845cc--
|
