summaryrefslogtreecommitdiff
path: root/36/c8c7aa022c16520ef80931e908ebb0130ad490
blob: 904f047e09ad82361939d4a4ed4d219a0575cef6 (plain)
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
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <natanael.l@gmail.com>) id 1Wm1Tl-00049Y-O4
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 May 2014 13:50:17 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.182 as permitted sender)
	client-ip=74.125.82.182; envelope-from=natanael.l@gmail.com;
	helo=mail-we0-f182.google.com; 
Received: from mail-we0-f182.google.com ([74.125.82.182])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wm1Tj-00015o-Dd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 May 2014 13:50:17 +0000
Received: by mail-we0-f182.google.com with SMTP id t60so4371704wes.41
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 18 May 2014 06:50:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.76.179 with SMTP id l19mr7829230wiw.43.1400421008910;
	Sun, 18 May 2014 06:50:08 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Sun, 18 May 2014 06:50:08 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Sun, 18 May 2014 06:50:08 -0700 (PDT)
In-Reply-To: <CALDj+Bbsb6JiLabTBx21k02dDvnmZZDCXmJ2mnh7DngBon202w@mail.gmail.com>
References: <BAY173-W1475F72C70BC089A82C20FCC300@phx.gbl>
	<5377892C.8080402@gmail.com>
	<CAAS2fgS-Ewj3T0-d=h7ET9dCz3+NPPYVOLDWd7T7oYY95x-sUA@mail.gmail.com>
	<CALDj+Bbsb6JiLabTBx21k02dDvnmZZDCXmJ2mnh7DngBon202w@mail.gmail.com>
Date: Sun, 18 May 2014 15:50:08 +0200
Message-ID: <CAAt2M19KJTysuaFfT8rthsMk07UhQL3owBF4Q0Cc4SoKg3UBqw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Alex Kotenko <alexykot@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0438938bc6224404f9acece8
X-Spam-Score: -0.3 (/)
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
	(natanael.l[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.3 HTML_FONT_FACE_BAD     BODY: HTML font face is not a word
	-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: 1Wm1Tj-00015o-Dd
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Paper Currency
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: Sun, 18 May 2014 13:50:17 -0000

--f46d0438938bc6224404f9acece8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Now you are talking about Trusted Platform Modules. Like smartcards,
actually. Devices that won't leak their keys but let the holder spend the
coins. It could even have it's own simple SPV wallet client to make it
easier to handle. And they'd use the attestation features provided by the
TPM to prove the software it's unmodified top the current holder.

But then you still have to trust the manufacturer of the device, and you
have to trust it has no exploitable side channels.

- Sent from my phone
Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot@gmail.com>:

> I had a long discussion recently with somebody who wants and has resource=
s
> to do exactly this - paper currency representing bitcoins. Yet we've been
> thinking mostly about a centralized solution, where one party is producin=
g
> and maintaining paper currency, with bitcoins tied to each note verifiabl=
e
> via blockchain.
>
> The points we've ended up is that it needs to be:
> - reloadable
> - NFC based
> So anybody can verify any notes instantly by just touching it with his
> phone, and so merchants could redeem the notes at the moment of accepting
> it, convert it into fully online bitcoins and avoid costs of maintaining
> paper money turnover. Probably merchant would sell back redeemed
> empty notes to the issuer for a price of the note issue, and issuer will
> recharge it and put back into circulation.
>
> One problem we couldn't figure out here though - how to protect the notes
> from unauthorized redeem. Like if someone else tries to reach your wallet
> with his own NFC - how can we distinguish between deliberate redeem by
> owner and fraudulent redeem by anybody else with custom built long
> range NFC antenna? Any ideas?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-17 17:40 GMT+01:00 Gregory Maxwell <gmaxwell@gmail.com>:
>
>> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia <ctpacia@gmail.com> wrote:
>> > I can't really just hand someone the note and walk away
>> > because they have to scan it to see if it is actually valid.
>>
>> Not just scan it, but they actually must successfully sweep it=E2=80=94
>> otherwise they can be trivially double spent. This is especially bad
>> since any prior bearer can perform such an attack. E.g. record the
>> private key of everyone that passes through your hands and then
>> doublespend race any redemption that happens >24 hours after you spend
>> them. The wrong person would likely be blamed and even if you were
>> blamed you could plausibly deny it ("Must have been the guy that gave
>> it to me!").
>>
>> Othercoin seems to have much better properties in the space of offline
>> transactions: https://bitcointalk.org/index.php?topic=3D319146.0
>>
>> Separately, Cassius also ran into some regulatory issues selling
>> physical bitcoin artifacts. Especially printing things that seem to be
>> redeemable for a named USD value sounds especially problematic.
>>
>> Some random comments=E2=80=94 The base58 encoding is fairly human unfrie=
ndly.
>> It's fine for something being copy and pasted, but I've found typing
>> or reading it works poorly due to mixed case.  I expect the A/B side
>> to be difficult to educate users about. "This side is private" is more
>> easily understood, you could just pick one of your sides and call it
>> private.  I find it kind of odd that this design seems to have no
>> facility for checking its txouts without recovering the private key,
>> though considering no one should rely on such a measurement without
>> sweeping perhaps thats for the best.
>>
>> (As far as the numbering goes, I think you should be calling these
>> draft-felix-paper-currency  etc. As a matter of hygienic practice I
>> will not assign a matching bip number for something that went public
>> with a number outside of the assignment.)
>>
>>
>> ------------------------------------------------------------------------=
------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> -------------------------------------------------------------------------=
-----
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--f46d0438938bc6224404f9acece8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Now you are talking about Trusted Platform Modules. Like sma=
rtcards, actually. Devices that won&#39;t leak their keys but let the holde=
r spend the coins. It could even have it&#39;s own simple SPV wallet client=
 to make it easier to handle. And they&#39;d use the attestation features p=
rovided by the TPM to prove the software it&#39;s unmodified top the curren=
t holder.</p>

<p dir=3D"ltr">But then you still have to trust the manufacturer of the dev=
ice, and you have to trust it has no exploitable side channels.</p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 18 maj 2014 13:52 skrev &quot;Alex Kotenko&q=
uot; &lt;<a href=3D"mailto:alexykot@gmail.com">alexykot@gmail.com</a>&gt;:<=
br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;cou=
rier new&#39;,monospace;color:rgb(0,51,0)">I had a long discussion recently=
 with somebody who wants and has resources to do exactly this - paper curre=
ncy representing bitcoins. Yet we&#39;ve been thinking mostly about a centr=
alized solution, where one party is producing and maintaining paper currenc=
y, with bitcoins tied to each note verifiable via blockchain.=C2=A0</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">The points we=
&#39;ve ended up is that it needs to be:</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">- reloadable</div><div class=3D"gmail_default" st=
yle=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">- NFC=
 based</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">So anybody can verify any notes instantly by just=
 touching it with his phone, and so merchants could redeem the notes at the=
 moment of accepting it, convert it into fully online bitcoins and avoid co=
sts of maintaining paper money turnover. Probably merchant would sell back=
=C2=A0redeemed empty=C2=A0notes to the issuer for a price of the note=C2=A0=
issue, and issuer will recharge it and put back into circulation.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">One problem w=
e couldn&#39;t figure out here though - how to protect the notes from unaut=
horized=C2=A0redeem. Like if someone else tries to reach your wallet with h=
is own NFC - how can we distinguish between deliberate redeem by owner and =
fraudulent redeem by anybody else with custom built long range=C2=A0NFC ant=
enna? Any ideas?</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)"><br></div><di=
v class=3D"gmail_extra">


<div><div dir=3D"ltr"><span style=3D"color:rgb(0,51,0);font-family:&#39;cou=
rier new&#39;,monospace">Best regards,=C2=A0</span><div><div><div style=3D"=
text-align:left"><font color=3D"#003300" face=3D"&#39;courier new&#39;, mon=
ospace" style=3D"text-align:-webkit-auto">Alex Kotenko</font></div>


</div></div></div></div>
<br><br><div class=3D"gmail_quote">2014-05-17 17:40 GMT+01:00 Gregory Maxwe=
ll <span dir=3D"ltr">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_b=
lank">gmaxwell@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div>On Sat, May 17, 2014 at 9:07 AM, Chris Pacia &lt;<a href=3D"mailto:ctp=
acia@gmail.com" target=3D"_blank">ctpacia@gmail.com</a>&gt; wrote:<br>
&gt; I can&#39;t really just hand someone the note and walk away<br>
&gt; because they have to scan it to see if it is actually valid.<br>
<br>
</div>Not just scan it, but they actually must successfully sweep it=E2=80=
=94<br>
otherwise they can be trivially double spent. This is especially bad<br>
since any prior bearer can perform such an attack. E.g. record the<br>
private key of everyone that passes through your hands and then<br>
doublespend race any redemption that happens &gt;24 hours after you spend<b=
r>
them. The wrong person would likely be blamed and even if you were<br>
blamed you could plausibly deny it (&quot;Must have been the guy that gave<=
br>
it to me!&quot;).<br>
<br>
Othercoin seems to have much better properties in the space of offline<br>
transactions: <a href=3D"https://bitcointalk.org/index.php?topic=3D319146.0=
" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D319146.0</a><=
br>
<br>
Separately, Cassius also ran into some regulatory issues selling<br>
physical bitcoin artifacts. Especially printing things that seem to be<br>
redeemable for a named USD value sounds especially problematic.<br>
<br>
Some random comments=E2=80=94 The base58 encoding is fairly human unfriendl=
y.<br>
It&#39;s fine for something being copy and pasted, but I&#39;ve found typin=
g<br>
or reading it works poorly due to mixed case. =C2=A0I expect the A/B side<b=
r>
to be difficult to educate users about. &quot;This side is private&quot; is=
 more<br>
easily understood, you could just pick one of your sides and call it<br>
private. =C2=A0I find it kind of odd that this design seems to have no<br>
facility for checking its txouts without recovering the private key,<br>
though considering no one should rely on such a measurement without<br>
sweeping perhaps thats for the best.<br>
<br>
(As far as the numbering goes, I think you should be calling these<br>
draft-felix-paper-currency =C2=A0etc. As a matter of hygienic practice I<br=
>
will not assign a matching bip number for something that went public<br>
with a number outside of the assignment.)<br>
<div><div><br>
---------------------------------------------------------------------------=
---<br>
&quot;Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE=
<br>
Instantly run your Selenium tests across 300+ browser/OS combos.<br>
Get unparalleled scalability from the best Selenium testing platform availa=
ble<br>
Simple to use. Nothing to install. Get started now for free.&quot;<br>
<a href=3D"http://p.sf.net/sfu/SauceLabs" target=3D"_blank">http://p.sf.net=
/sfu/SauceLabs</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
</div></div></blockquote></div><br></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
&quot;Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE=
<br>
Instantly run your Selenium tests across 300+ browser/OS combos.<br>
Get unparalleled scalability from the best Selenium testing platform availa=
ble<br>
Simple to use. Nothing to install. Get started now for free.&quot;<br>
<a href=3D"http://p.sf.net/sfu/SauceLabs" target=3D"_blank">http://p.sf.net=
/sfu/SauceLabs</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>
<br></blockquote></div>

--f46d0438938bc6224404f9acece8--