From: Alex Kotenko <alexykot@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Paper Currency
Date: Sun, 18 May 2014 12:47:11 +0100 [thread overview]
Message-ID: <CALDj+Bbsb6JiLabTBx21k02dDvnmZZDCXmJ2mnh7DngBon202w@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgS-Ewj3T0-d=h7ET9dCz3+NPPYVOLDWd7T7oYY95x-sUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3801 bytes --]
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 <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—
> 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=319146.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— The base58 encoding is fairly human unfriendly.
> 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
>
[-- Attachment #2: Type: text/html, Size: 6037 bytes --]
next prev parent reply other threads:[~2014-05-18 11:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-17 15:31 Jerry Felix
2014-05-17 15:45 ` Matt Whitlock
2014-05-17 16:07 ` Chris Pacia
2014-05-17 16:40 ` Gregory Maxwell
2014-05-18 11:47 ` Alex Kotenko [this message]
2014-05-18 12:14 ` Andreas Schildbach
2014-05-18 12:51 ` Alex Kotenko
2014-05-19 13:06 ` Brooks Boyd
2014-05-19 13:50 ` Alex Kotenko
2014-05-18 13:50 ` Natanael
2014-05-18 18:47 ` Alex Kotenko
2014-05-18 20:10 ` Natanael
2014-05-19 10:26 ` Alex Kotenko
2014-05-19 12:55 ` Sergio Lerner
2014-05-19 13:34 ` Martin Sip
2014-05-19 13:53 ` Alex Kotenko
2014-05-19 14:47 ` [Bitcoin-development] patents Adam Back
2014-05-19 15:09 ` Mike Hearn
2014-05-19 18:27 ` Peter Todd
2014-05-19 18:40 ` Mike Hearn
2014-05-19 18:43 ` Gregory Maxwell
2014-05-19 18:46 ` Peter Todd
2014-05-19 18:49 ` Mike Hearn
2014-05-19 22:15 ` Bernd Jendrissek
2014-05-20 10:30 ` Jeff Garzik
2014-05-18 13:50 ` [Bitcoin-development] Paper Currency Andreas Schildbach
2014-05-19 12:21 ` Mike Hearn
2014-05-19 18:20 ` Justus Ranvier
2014-05-19 18:39 ` Peter Todd
2014-05-18 19:54 Jerry Felix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDj+Bbsb6JiLabTBx21k02dDvnmZZDCXmJ2mnh7DngBon202w@mail.gmail.com \
--to=alexykot@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox