path: root/4d/dfda170ee9428b8f9c83b614df0ca3de28163e

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 <alexy.kot.all@gmail.com>) id 1WmKmx-0007od-Bi
	for bitcoin-development@lists.sourceforge.net;
	Mon, 19 May 2014 10:27:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.179 as permitted sender)
	client-ip=209.85.128.179; envelope-from=alexy.kot.all@gmail.com;
	helo=mail-ve0-f179.google.com; 
Received: from mail-ve0-f179.google.com ([209.85.128.179])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WmKmv-0005Q2-Kq
	for bitcoin-development@lists.sourceforge.net;
	Mon, 19 May 2014 10:27:23 +0000
Received: by mail-ve0-f179.google.com with SMTP id oy12so6234206veb.10
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 19 May 2014 03:27:16 -0700 (PDT)
X-Received: by 10.220.167.198 with SMTP id r6mr969862vcy.36.1400495235969;
	Mon, 19 May 2014 03:27:15 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.58.211.135 with HTTP; Mon, 19 May 2014 03:26:35 -0700 (PDT)
In-Reply-To: <CAAt2M19cBL2W+PxcQCE7XkjJ0C=9Zshu9SfsT-CBPk9C6EN5Zg@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>
	<CAAt2M19cBL2W+PxcQCE7XkjJ0C=9Zshu9SfsT-CBPk9C6EN5Zg@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Mon, 19 May 2014 11:26:35 +0100
X-Google-Sender-Auth: wJz4mVss6nD6Qn3tqFBPllyF23Q
Message-ID: <CALDj+Bbc_G1djYx-F-QpRPKMY7WBznemEd0pd0Yt2UE4rg6QiQ@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2a6080cba7704f9be3558
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
	(alexy.kot.all[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: 1WmKmv-0005Q2-Kq
Cc: Bitcoin Dev <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: Mon, 19 May 2014 10:27:23 -0000

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

Practically I would approach it from a different angle. We need to make
sure that notes we're accepting are still loaded, but assuming it's NFC
enabled this is still quite easy for the user and is an acceptable
usability drawback.
Then what we need to make sure is that when someone is redeeming the notes
- he has control over physical object itself, ideally for a period of time.

=E2=80=8BWith some active powered electronics in place it would be easy, bu=
t how do
we do it without anything active in place? =E2=80=8B


Best regards,
Alex Kotenko


2014-05-18 21:10 GMT+01:00 Natanael <natanael.l@gmail.com>:

> The problem with not involving any electronics is that somebody needs to
> generate a recoverable private key that we have to trust haven't recovere=
d
> 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 i=
f
> 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 =
printed on
>> paper, but not actual chips and/or power modules. So we are talking abou=
t 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 verificati=
on,
>> 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 pho=
ne
>> manufacturer when you're putting your bitcoin wallet on it.
>>
>> =E2=80=8BSo really I see =E2=80=8Bonly issues of technical security in h=
ere, 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 t=
he
>>> 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 t=
he
>>> 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 yo=
u
>>> 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
>>>
>>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;color:#003300">Practically I would approach it from a differe=
nt angle. We need to make sure that notes we&#39;re accepting are still loa=
ded, but assuming it&#39;s NFC enabled this is still quite easy for the use=
r and is an acceptable usability drawback.</div>


<div class=3D"gmail_default" style=3D"font-family:courier new,monospace;col=
or:#003300">Then what we need to make sure is that when someone is redeemin=
g the notes - he has control over physical object itself, ideally for a per=
iod of time.</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospace;col=
or:rgb(0,51,0)">=E2=80=8BWith some active powered electronics in place it w=
ould be easy, but how do we do it without anything active in place? =E2=80=
=8B</div>

<br></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr=
"><span style=3D"color:rgb(0,51,0);font-family:&#39;courier new&#39;,monosp=
ace">Best regards,=C2=A0</span><div>
<div><div style=3D"text-align:left"><font color=3D"#003300" face=3D"&#39;co=
urier new&#39;, 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 21:10 GMT+01:00 Natanael <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank"=
>natanael.l@gmail.com</a>&gt;</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">The problem with not involving any electronics is that someb=
ody needs to generate a recoverable private key that we have to trust haven=
&#39;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&#39;t=
 know if all the private keys are recoverable to you (failed print?).</p>


<div>

<p dir=3D"ltr">- Sent from my phone</p>
</div><div class=3D"gmail_quote">Den 18 maj 2014 20:48 skrev &quot;Alex Kot=
enko&quot; &lt;<a href=3D"mailto:alexykot@gmail.com" target=3D"_blank">alex=
ykot@gmail.com</a>&gt;:<div><div><br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">



<div dir=3D"ltr"><div style=3D"font-family:courier new,monospace;color:#003=
300">Erm, few things here.=C2=A0</div><div class=3D"gmail_extra"><div style=
=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">


=E2=80=8B- I can&#39;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 style=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)=
">- even with paper notes printed proprietarily by some business the notes =
itself still can have routes for independent blockchain-based verification,=
 and you won&#39;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&#39;re putting your bitcoin wallet on it.</div>





<br></div><div class=3D"gmail_extra"><div style=3D"font-family:&#39;courier=
 new&#39;,monospace;color:rgb(0,51,0)">=E2=80=8BSo really I see =E2=80=8Bon=
ly issues of technical security in here, and this is the problem I&#39;m se=
eking 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:&#39;cour=
ier new&#39;,monospace">Best regards,=C2=A0</span><div><div><div style=3D"t=
ext-align:left">





<font color=3D"#003300" face=3D"&#39;courier new&#39;, 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">&lt;<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank"=
>natanael.l@gmail.com</a>&gt;</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&#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" target=3D"_blank">alexykot@g=
mail.com</a>&gt;:<div><div><div style=3D"font-family:&#39;courier new&#39;,=
monospace;color:rgb(0,51,0)">





=E2=80=8B</div></div></div></div></blockquote></div></div></div>
</blockquote></div></div></div>
</blockquote></div><br></div></div>

--001a11c2a6080cba7704f9be3558--