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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1Wm7PO-0000hT-LC
for bitcoin-development@lists.sourceforge.net;
Sun, 18 May 2014 20:10:10 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wm7PN-0003du-DW
for bitcoin-development@lists.sourceforge.net;
Sun, 18 May 2014 20:10:10 +0000
Received: by mail-wg0-f41.google.com with SMTP id z12so7082240wgg.12
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 May 2014 13:10:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.76.179 with SMTP id l19mr9146667wiw.43.1400443803162;
Sun, 18 May 2014 13:10:03 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Sun, 18 May 2014 13:10:03 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Sun, 18 May 2014 13:10:03 -0700 (PDT)
In-Reply-To: <CALDj+BbEY8+3feH8WQOr2f-VW1xZfq_WPgi3DmMAfOkZwJ2oJQ@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>
<CAAt2M19KJTysuaFfT8rthsMk07UhQL3owBF4Q0Cc4SoKg3UBqw@mail.gmail.com>
<CALDj+BbEY8+3feH8WQOr2f-VW1xZfq_WPgi3DmMAfOkZwJ2oJQ@mail.gmail.com>
Date: Sun, 18 May 2014 22:10:03 +0200
Message-ID: <CAAt2M19cBL2W+PxcQCE7XkjJ0C=9Zshu9SfsT-CBPk9C6EN5Zg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Alex Kotenko <alexykot@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0438938b6a60c304f9b23bd0
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: 1Wm7PN-0003du-DW
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 20:10:10 -0000
--f46d0438938b6a60c304f9b23bd0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The problem with not involving any electronics is that somebody needs to
generate a recoverable private key that we have to trust haven't recovered
the private key.
The only plausible solution is multisignature P2SH addresses where you
trust several independent entities to not collude instead, where you
combine their paper notes into one piece. And then you still don't know if
all the private keys are recoverable to you (failed print?).
- Sent from my phone
Den 18 maj 2014 20:48 skrev "Alex Kotenko" <alexykot@gmail.com>:
> Erm, few things here.
> =E2=80=8B- I can't see really how to embed electronics capable to run an =
SPV
> cli=E2=80=8Bent into printed paper. I know that passive NFC tags can be p=
rinted on
> paper, but not actual chips and/or power modules. So we are talking about=
a
> completely different things here.
> - even with paper notes printed proprietarily by some business the notes
> itself still can have routes for independent blockchain-based verificatio=
n,
> and you won't need to trust anybody to test it. You will have to trust
> security of the notes itself, but this is same as when you trust the phon=
e
> manufacturer when you're putting your bitcoin wallet on it.
>
> =E2=80=8BSo really I see =E2=80=8Bonly issues of technical security in he=
re, and this is
> the problem I'm seeking solutions for.
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-18 14:50 GMT+01:00 Natanael <natanael.l@gmail.com>:
>
>> Now you are talking about Trusted Platform Modules. Like smartcards,
>> actually. Devices that won't leak their keys but let the holder spend th=
e
>> 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 th=
e
>> 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>:
>> =E2=80=8B
>>
>
--f46d0438938b6a60c304f9b23bd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">The problem with not involving any electronics is that someb=
ody needs to generate a recoverable private key that we have to trust haven=
't recovered the private key. </p>
<p dir=3D"ltr">The only plausible solution is multisignature P2SH addresses=
where you trust several independent entities to not collude instead, where=
you combine their paper notes into one piece. And then you still don't=
know if all the private keys are recoverable to you (failed print?).</p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 18 maj 2014 20:48 skrev "Alex Kotenko&q=
uot; <<a href=3D"mailto:alexykot@gmail.com">alexykot@gmail.com</a>>:<=
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:courier =
new,monospace;color:#003300">Erm, few things here.=C2=A0</div><div class=3D=
"gmail_extra"><div class=3D"gmail_default" style=3D"font-family:'courie=
r new',monospace;color:rgb(0,51,0)">
=E2=80=8B- I can't see really how to embed electronics capable to run a=
n SPV cli=E2=80=8Bent into printed paper. I know that passive NFC tags can =
be printed on paper, but not actual chips and/or power modules. So we are t=
alking about a completely different things here.</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">- even with paper notes printed proprietarily by =
some business the notes itself still can have routes for independent blockc=
hain-based verification, and you won't need to trust anybody to test it=
. You will have to trust security of the notes itself, but this is same as =
when you trust the phone manufacturer when you're putting your bitcoin =
wallet on it.</div>
<br></div><div class=3D"gmail_extra"><div class=3D"gmail_default" style=3D"=
font-family:'courier new',monospace;color:rgb(0,51,0)">=E2=80=8BSo =
really I see =E2=80=8Bonly issues of technical security in here, and this i=
s the problem I'm seeking solutions for.</div>
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
div><div dir=3D"ltr"><span style=3D"color:rgb(0,51,0);font-family:'cour=
ier new',monospace">Best regards,=C2=A0</span><div><div><div style=3D"t=
ext-align:left">
<font color=3D"#003300" face=3D"'courier new', monospace" style=3D"=
text-align:-webkit-auto">Alex Kotenko</font></div></div></div></div></div>
<br><br><div class=3D"gmail_quote">2014-05-18 14:50 GMT+01:00 Natanael <spa=
n dir=3D"ltr"><<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank"=
>natanael.l@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">Now you are talking about Trusted Platform Modules. Like sma=
rtcards, actually. Devices that won't leak their keys but let the holde=
r 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 p=
rovided by the TPM to prove the software it'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 "Alex Kotenko&q=
uot; <<a href=3D"mailto:alexykot@gmail.com" target=3D"_blank">alexykot@g=
mail.com</a>>:<div><div><div class=3D"gmail_default" style=3D"font-famil=
y:'courier new',monospace;color:rgb(0,51,0)">
=E2=80=8B</div></div></div></div></blockquote></div></div></div>
</blockquote></div>
--f46d0438938b6a60c304f9b23bd0--
|
