From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Wm68P-0003Lu-CA for bitcoin-development@lists.sourceforge.net; Sun, 18 May 2014 18:48:33 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.180 as permitted sender) client-ip=209.85.220.180; envelope-from=alexy.kot.all@gmail.com; helo=mail-vc0-f180.google.com; Received: from mail-vc0-f180.google.com ([209.85.220.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wm68O-0001ld-D0 for bitcoin-development@lists.sourceforge.net; Sun, 18 May 2014 18:48:33 +0000 Received: by mail-vc0-f180.google.com with SMTP id hy4so8485647vcb.39 for ; Sun, 18 May 2014 11:48:26 -0700 (PDT) X-Received: by 10.52.185.72 with SMTP id fa8mr8509986vdc.12.1400438906639; Sun, 18 May 2014 11:48:26 -0700 (PDT) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.58.211.135 with HTTP; Sun, 18 May 2014 11:47:46 -0700 (PDT) In-Reply-To: References: <5377892C.8080402@gmail.com> From: Alex Kotenko Date: Sun, 18 May 2014 19:47:46 +0100 X-Google-Sender-Auth: m0-QMygrUmZQGwAsJvqqp0x1PW4 Message-ID: To: Natanael Content-Type: multipart/alternative; boundary=bcaec548a66d8f5b9d04f9b117ad 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: 1Wm68O-0001ld-D0 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Paper Currency X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 18:48:33 -0000 --bcaec548a66d8f5b9d04f9b117ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Erm, few things here. =E2=80=8B- I can't see really how to embed electronics capable to run an SP= V cli=E2=80=8Bent into printed paper. I know that passive NFC tags can be pri= nted 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 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. =E2=80=8BSo really I see =E2=80=8Bonly issues of technical security in here= , and this is the problem I'm seeking solutions for. Best regards, Alex Kotenko 2014-05-18 14:50 GMT+01:00 Natanael : > 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" : > =E2=80=8B > --bcaec548a66d8f5b9d04f9b117ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Erm, few things here.=C2=A0
=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.
- 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.

=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>
Best regards,=C2=A0
Alex Kotenko


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

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.

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

- Sent from my phone

Den 18 maj 2014 13:52 skrev "Alex Kotenko&q= uot; <alexykot@g= mail.com>:
=E2=80=8B
--bcaec548a66d8f5b9d04f9b117ad--