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 1WlzZO-0007Ge-DC for bitcoin-development@lists.sourceforge.net; Sun, 18 May 2014 11:47:58 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.181 as permitted sender) client-ip=209.85.128.181; envelope-from=alexy.kot.all@gmail.com; helo=mail-ve0-f181.google.com; Received: from mail-ve0-f181.google.com ([209.85.128.181]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WlzZN-0005z6-4n for bitcoin-development@lists.sourceforge.net; Sun, 18 May 2014 11:47:58 +0000 Received: by mail-ve0-f181.google.com with SMTP id pa12so5129559veb.40 for ; Sun, 18 May 2014 04:47:51 -0700 (PDT) X-Received: by 10.58.154.10 with SMTP id vk10mr25576006veb.18.1400413671400; Sun, 18 May 2014 04:47:51 -0700 (PDT) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.58.211.135 with HTTP; Sun, 18 May 2014 04:47:11 -0700 (PDT) In-Reply-To: References: <5377892C.8080402@gmail.com> From: Alex Kotenko Date: Sun, 18 May 2014 12:47:11 +0100 X-Google-Sender-Auth: 7PqmqiU3BuS06fEs0RrCAKfpiqc Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b5d84ef6c2d2304f9ab37b2 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: 1WlzZN-0005z6-4n Cc: Bitcoin Development 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 11:47:58 -0000 --047d7b5d84ef6c2d2304f9ab37b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had a long discussion recently with somebody who wants and has resources to do exactly this - paper currency representing bitcoins. Yet we've been thinking mostly about a centralized solution, where one party is producing and maintaining paper currency, with bitcoins tied to each note verifiable 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 : > On Sat, May 17, 2014 at 9:07 AM, Chris Pacia 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 unfrien= dly. > 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 > --047d7b5d84ef6c2d2304f9ab37b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had a long discussion recently= with somebody who wants and has resources to do exactly this - paper curre= ncy representing bitcoins. Yet we'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

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 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.

One problem w= e couldn'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?


Best regards,=C2=A0
Alex Kotenko


2014-05-17 17:40 GMT+01:00 Gregory Maxwe= ll <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<= br> it to me!").

Othercoin seems to have much better properties in the space of offline
transactions: https://bitcointalk.org/index.php?topic=3D319146.0<= br>
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 unfriendl= y.
It's fine for something being copy and pasted, but I've found typin= g
or reading it works poorly due to mixed case. =C2=A0I 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. =C2=A0I 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 =C2=A0etc. 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 availa= ble
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net= /sfu/SauceLabs
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7b5d84ef6c2d2304f9ab37b2--