Re: [Bitcoin-development] Paper Currency

Re: [Bitcoin-development] Paper Currency

[Jerry Felix]

[-- Attachment #1: Type: text/plain, Size: 4559 bytes --]

Thanks for all the feedback, and for everyone who read through the docs.  

My BIP numbering was a blunder, and I have revised the numbering to be PCP-0 (Paper Currency Proposal Number 0) through PCP-4.   I think I was brain-dead on that, sorry, and I am now on PCP.



Please allow me to walk you through my thought process on Paper Currency, if you aren't sold that there's merit.

At present time, paper currency undeniably serves a major purpose in society and has a huge value.  Whether all-digital transfers can totally replace paper is still unknown.

And we citizens currently pay a lot to create paper money that is hard to counterfeit.  That too has tons of value, and it can be measured by looking at how much is spent to design, print, and protect fiat currencies from counterfeiting.  And you can add to that cost the societal costs of successful counterfeiting.  US Numbers exceed $800M annually, and are a fraction of the worldwide numbers.

And travelers routinely pay currency exchange fees, to acquire paper currency that is accepted in particular locales.  So a single internationally accepted, border-less paper currency would have high value, as it could potentially eliminate exchange fees for travelers.

Add all the above costs together, and you can see that this is a multi-billion dollar market that Bitcoin could disrupt.   We could actually eliminate all of those costs, while at the same time put Bitcoins into the hands of people in a form that is more familiar.

That's why this feels like a huge need that can be satisfied by creating a single standard for hard-to-counterfeit, cheap to print, paper currency.    I think the key is a "single standard" that the public recognizes.



I think that there are things that you can do with paper now that can't be done with all-digital transfers.  Maybe my perspective is too US-centric due to tipping customs, but it seems much easier to rapidly leave money for someone without their involvement via paper than digital transfers ever will be.   

A recent video showed a stripper/dancer stop dancing and pose to have her QR Tattoo scanned for payment.  (Not that this is all about strippers and PCP, but...) paper would be a much more practical medium than digital transfer in a lot of scenarios.  
http://blogs-images.forbes.com/kashmirhill/files/2014/05/Bitcoin-stripper-QR-code.jpg 
If you think about it, whether you slipped her a Bitcoin Paper note or digitally transferred payment to her QR code, in neither case is she able to verify receipt of payment until she steps off stage.  But remember, we're typically talking about a buck or ten or twenty, not 3 bitcoins as shown in the video!



I saw a Reddit or bitcointalk comment, I believe credited to Mike Caldwell, saying that the author envisioned transactions where the buyer simply handed over private keys (paper wallets), and the merchant had all the electronics.  Reducing the electronics necessary for transfers seems to be desirable.  Should I have to carry a $300 cell phone to be able to carry and spend $20?  This would be moot if 100% of people had their electronic devices with them 100% of the time they need to spend money, and the device is 100% reliable.  I know for me that's not the case.

So, if the currency medium of paper has value, and Bitcoin can make paper currency more counterfeit-proof, and Bitcoin can eliminate costs, and it's a huge market, and the public is familiar with the paper paradigm, all that's left is for the community to come up with a standard.  That's why I took a crack at it, but I certainly welcome improvements!

Questions: 
1)  Is paper a valuable medium for currency?  I contend yes.  
2)  What's the proper tradeoff between convenience and security for paper Bitcoin Notes?  I opted for splitting the private key over two QR codes on opposite sides of the page, as opposed to BIP-38, and I explained my rationale in the documents.

The rest of the technical details (the splitting algorithm, for instance) need to be resolved.  But I took a crack at it.
And the marketing details (note size, shape, color, layout, text, do we call them "Bits", etc.) all need to be resolved.  again, I gave it my best effort, but I'm quite certain the community can do better than me!


First step, though, is to determine whether there's consensus to define a standard for paper bitcoin currency.



Thanks for hearing me out! 
Docs are here:   
https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki 



 		 	   		  

[-- Attachment #2: Type: text/html, Size: 5272 bytes --]

Re: [Bitcoin-development] Paper Currency

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 19 May 2014 20:20:40 CEST, Justus Ranvier <justusranvier@gmail.com> wrote:

>You and Gavin could do a lot better by working on a Bitcoin social
>contract - a promise of what features will *never* be added (or taken
>away) from Bitcoin, because despite what you say it's not acceptable
>to propose anything at all.
>
>Maybe start with things like how the Bitcoin protocol will never be
>changed to allow for confiscation of funds, regardless of who might
>demand such a feature.

Might be worth looking into the recent RFC 7258: Pervasive Monitoring Is an Attack for some guidance on how to write such a social contract.

Re: Gavin, note the language in the foundation bylaws:

Section 2.2 The Corporation shall promote and protect both the decentralized, distributed and private nature of the Bitcoin distributed-digital currency and transaction system as well as individual choice, participation and financial privacy when using such systems.

You might want to do a pull-req to add fungibility and rejection of blacklists to that list; note Adam Back's comments on how fungibility and privacy are inherently linked.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJTek/ZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYPIB/9/mhDOei8uMGHmzK41
YdL2ezs4LMPLyCRbo9Eu7MDJAMBaMH4VUbomR0tJVPRS191ifa2F/xGYnbDvk/PG
rLX86uPPMBxZqnVMgZLeKJkUHm3Zlkm1Ti58bMR8VVQuPazBBpkYtsvk+0+8j9su
ke7Xq+OqUGOC03bM4bxtKyBCy1FrCJuFgZEywKhOjr6boANLctDRBZerPqQ4AcjP
tHSAAImcesMhjc/N9LJ4MeygszzblYpdsQeiw8jvvyZI7vCSHuKb+hur+kCszYjD
ygfY9QmoNye2yc0GLZd+kXSMwY6gLIvaAFhv2ElMTMiJ7btHtJJfyEaA9Ub4zEEY
JKeO
=DSjZ
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Paper Currency

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/2014 02:21 PM, Mike Hearn wrote:
>> Submitted with humility and some fear of getting laughed out of
>> here...
>> 
> 
> Off topic aside, a bunch of us have lately started to think about
> the atmosphere on this list and how to improve it. Nobody should
> have to fear getting flamed or laughed at for proposing ideas, even
> if they turn out to be silly ones. Gavin talked about this in his
> Bitcoin 2014 keynote and asked for someone to solve the forum
> trolling problem.

You and Gavin could do a lot better by working on a Bitcoin social
contract - a promise of what features will *never* be added (or taken
away) from Bitcoin, because despite what you say it's not acceptable
to propose anything at all.

Maybe start with things like how the Bitcoin protocol will never be
changed to allow for confiscation of funds, regardless of who might
demand such a feature.

You are willing to promise all users of Bitcoin that you'll never
propose to steal their coins, aren't you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTekt4AAoJEMP3uyY4RQ214QgIAM3DdtAUTG63FG/r9Yg4dWb+
TXWoXRd9AYDg/SAirF6qV+r6K0vohMv8UJhCpX0OnNSOfxKcgVt2CnG8i3iWBRu1
V+LRFmaHkJ+vJLaR2lEdFKMc2DVuZUIXGH6jEgVo/dzFJGZ/GcoUwTBrZztjCHDy
WbpuuIfV2ya1bqkhMOn78pDgkDfXBD7qWQsz0MTzSkPitT0AnUEPxCl3KBWizkdH
shGwE4YNhRSX+yTBaFHVMqFb9LzExEWgIgkgghddKfJzj9REcw6wiotD3DvYaDl7
LPegCttg0vdG4YTVlTH0iMwFYC3qrw/Ab43uqLjTy7aWyFjhsPtKceTE3KpGDrk=
=dRhy
-----END PGP SIGNATURE-----

[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 13290 bytes --]

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hmm, this is firmcoin thing looks like what I mean. They don't have a
solution yet, and prices they quote smartcards are unacceptable, but if
they will manage to get down in selfcost - that may work. Ok, I'll follow
them and see what it will come to.


Best regards,
Alex Kotenko


2014-05-19 13:55 GMT+01:00 Sergio Lerner <sergiolerner@certimix.com>:

>  Alex,
>
>     I think that what you are talking about more or less something like
> the Firmcoin
>
>     Check: http://firmcoin.com/?p=92
>
>
>
> On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
>
>
>
>  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?
>
>
>   The firmcoin has two capacitive buttons that you have to press in
> sequence to redeem to coins. No long range antenna can do that.
>
> Best regards,
>  Sergio.
>
> PS:   the device has patents pending
>

[-- Attachment #2: Type: text/html, Size: 2450 bytes --]

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

Asking random ignorant stranger to care to protect themselves never works.
We need solution that requires strictly zero effort.


Best regards,
Alex Kotenko


2014-05-19 14:06 GMT+01:00 Brooks Boyd <boydb@midnightdesign.ws>:

> >> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:
> >> 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?
> >>
> >> I think you'd need multiple factors to protect against that attack. Like
> >> encrypting with a key that is printed on the note as an QR code.
> >
> >On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko <alexykot@gmail.com> wrote:
> >
> > Yes, but it must not sacrifice usability. It's paper money, people are
> used to it and they have rather high standard of expectations in this area.
> Any usbility sacrifices in this area result into failure of the whole thing.
> >
> > Best regards,
> > Alex Kotenko
>
> One thought I had reading through this exchange: I think the general
> public is becoming more aware of the "hacker with a long range
> antenna" sort of attack, since credit cards are getting microchips
> that can be scanned. There's a few videos I've seen of white hat
> hackers demonstrating how a suitcase-sized apparatus carried by
> someone walking down the street can scan and make charges on cards in
> people's pockets as the attacker brushes past. Hence RFID-blocking
> sleeves/wallets are on the market, such that your smart credit card
> can't make a purchase while its in your wallet. Is a RFID-blocking
> wallet also NFC-blocking? Irregardless of whatever "future cash" you
> choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
> its the wallet/purse that needs an upgrade, to ensure your money
> doesn't spend itself while its in your pocket, but you can easily
> remove it and spend it conveniently?
>
> Brooks
>
>
> ------------------------------------------------------------------------------
> "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: 4153 bytes --]

Re: [Bitcoin-development] Paper Currency

[Martin Sip]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Alex,

I think the problem of making paper bitcoins is equivalent to the idea of
creating paper implementation of bitcoin sidechain. Hard one in my mind. If
we could resolve this one in secure and decentralized way it would be the
same breakthrough as bitcoin itself is.

Martin Sip

 

 

On 18/05/2014 08:47 a.m., Alex Kotenko wrote:

 

 

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?

 

 

The firmcoin has two capacitive buttons that you have to press in sequence
to redeem to coins. No long range antenna can do that.

Best regards,
 Sergio.

PS:   the device has patents pending 


[-- Attachment #2: Type: text/html, Size: 3926 bytes --]

Re: [Bitcoin-development] Paper Currency

[Brooks Boyd]

>> 2014-05-18 13:14 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:
>> 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?
>>
>> I think you'd need multiple factors to protect against that attack. Like
>> encrypting with a key that is printed on the note as an QR code.
>
>On Sun, May 18, 2014 at 7:51 AM, Alex Kotenko <alexykot@gmail.com> wrote:
>
> Yes, but it must not sacrifice usability. It's paper money, people are used to it and they have rather high standard of expectations in this area. Any usbility sacrifices in this area result into failure of the whole thing.
>
> Best regards,
> Alex Kotenko

One thought I had reading through this exchange: I think the general
public is becoming more aware of the "hacker with a long range
antenna" sort of attack, since credit cards are getting microchips
that can be scanned. There's a few videos I've seen of white hat
hackers demonstrating how a suitcase-sized apparatus carried by
someone walking down the street can scan and make charges on cards in
people's pockets as the attacker brushes past. Hence RFID-blocking
sleeves/wallets are on the market, such that your smart credit card
can't make a purchase while its in your wallet. Is a RFID-blocking
wallet also NFC-blocking? Irregardless of whatever "future cash" you
choose to carry (be it credit card or bitcoin card/coin/cash), perhaps
its the wallet/purse that needs an upgrade, to ensure your money
doesn't spend itself while its in your pocket, but you can easily
remove it and spend it conveniently?

Brooks

Re: [Bitcoin-development] Paper Currency

[Sergio Lerner]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Alex,

    I think that what you are talking about more or less something like
the Firmcoin

    Check: http://firmcoin.com/?p=92


On 18/05/2014 08:47 a.m., Alex Kotenko wrote:
>
>
> 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?
>
>
The firmcoin has two capacitive buttons that you have to press in
sequence to redeem to coins. No long range antenna can do that.

Best regards,
 Sergio.

PS:   the device has patents pending

[-- Attachment #2: Type: text/html, Size: 1974 bytes --]

Re: [Bitcoin-development] Paper Currency

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

> Submitted with humility and some fear of getting laughed out of here...
>

Off topic aside, a bunch of us have lately started to think about the
atmosphere on this list and how to improve it. Nobody should have to fear
getting flamed or laughed at for proposing ideas, even if they turn out to
be silly ones. Gavin talked about this in his Bitcoin 2014 keynote and
asked for someone to solve the forum trolling problem.

I don't know if there are any silver bullets per se, but:

1) Please do keep ideas coming. It's easy to mute threads in any good mail
client for people who don't care. If anyone gets too aggressive, the rest
of us will remind them that this is unacceptable.

2) If you're willing to become a list moderator, please get in touch. Gavin
and I are looking for neutral people who are willing to keep up with this
list and help ensure the debate is civilised. Ideally moderation is not
necessary, but that's what we tried so far and we keep getting consistent
feedback from lots of people that it's not working.

[-- Attachment #2: Type: text/html, Size: 1432 bytes --]

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]

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.

​With some active powered electronics in place it would be easy, but how do
we do it without anything active in place? ​


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 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.
>> ​- I can't see really how to embed electronics capable to run an SPV
>> cli​ent 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 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.
>>
>> ​So really I see ​only 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 <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 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" <alexykot@gmail.com>:
>>> ​
>>>
>>

[-- Attachment #2: Type: text/html, Size: 5222 bytes --]

Re: [Bitcoin-development] Paper Currency

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

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.
> ​- I can't see really how to embed electronics capable to run an SPV
> cli​ent 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 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.
>
> ​So really I see ​only 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 <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 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" <alexykot@gmail.com>:
>> ​
>>
>

[-- Attachment #2: Type: text/html, Size: 3662 bytes --]

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Erm, few things here.
​- I can't see really how to embed electronics capable to run an SPV
cli​ent 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 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.

​So really I see ​only 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 <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 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" <alexykot@gmail.com>:
> ​
>

[-- Attachment #2: Type: text/html, Size: 2837 bytes --]

Re: [Bitcoin-development] Paper Currency

[Andreas Schildbach]

Jerry, some feedback on generating space-efficient QR codes. QR codes
have 4 possible encodings, see "Storage":
http://en.wikipedia.org/wiki/QR_code

The encoding you're proposing in BIP81 switches you to binary mode
without actually using all the bits. So you'll end up with bloaty QR
codes. One fix would be of course use all the available bits.

However, binary QR codes cannot be used to auto-dispatch to apps on
Android. If you want a wallet app to automatically open upon scan, you
need to encode your data as an URI. That pretty much locks you into
using alphanumeric mode QR codes.

I've implemented that in Bitcoin Wallet for efficiently encoding
transactions and BIP70 payment requests into QR codes. Since the allowed
alphabet is 43 chars, I've named the encoding Base43 (it uses the same
algorithm as Base58 or Base64). Tell me if you're interested in the details.


On 05/17/2014 05:31 PM, Jerry Felix wrote:
> It seems to me that there's a huge need for a paper currency that is
> counterfeit-resistant, inexpensive to print, internationally recognized
> (border-less), fits in a wallet, and machine readable.
> 
> I pitched this idea at the Cincinnati Bitcoin meetup last week, and I
> didn't get thrown out, so I took the time to document a proposed
> standard to accomplish this.  I've put my ideas into BIP format, so that
> you can see what I have in mind, although I picked some
> BIP numbers myself that seem to be available.  Call them "proposed
> proposals", or "provisional BIPs".  I've numbered them provisionally
> BIP-80 to BIP-84.
> 
> If you guys think that this idea has some merit, let's discuss.
> 
> https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki
> 
> Submitted with humility and some fear of getting laughed out of here...
> - Jerry
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> "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
> 

Re: [Bitcoin-development] Paper Currency

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 5101 bytes --]

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" <alexykot@gmail.com>:

> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> "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: 7778 bytes --]

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

Yes, but it must not sacrifice usability. It's paper money, people are used
to it and they have rather high standard of expectations in this area. Any
usbility sacrifices in this area result into failure of the whole thing.

Best regards,
Alex Kotenko


2014-05-18 13:14 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:

> > 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?
>
> I think you'd need multiple factors to protect against that attack. Like
> encrypting with a key that is printed on the note as an QR code.
>
>
>
>
> ------------------------------------------------------------------------------
> "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: 2486 bytes --]

Re: [Bitcoin-development] Paper Currency

[Andreas Schildbach]

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

I think you'd need multiple factors to protect against that attack. Like
encrypting with a key that is printed on the note as an QR code.

Re: [Bitcoin-development] Paper Currency

[Alex Kotenko]

[-- 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 --]

Re: [Bitcoin-development] Paper Currency

[Gregory Maxwell]

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

Re: [Bitcoin-development] Paper Currency

[Chris Pacia]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Since these notes have to be redeemed immediately the number of use
cases seems limited. 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.
Otherwise someone could just pass fake notes if they felt the recipient
wouldn't redeem them on the spot. This doesn't seem like an improvement
over just sending the coins via phone.

The use case with poor internet connection wouldn't work as well since,
presumably, the recipient would also have poor reception and couldn't
verify the note was actually loaded with bitcoins.

Also, I REALLY don't like the name bit reserve.

-Chris

On 05/17/2014 11:31 AM, Jerry Felix wrote:
> It seems to me that there's a huge need for a paper currency that is
> counterfeit-resistant, inexpensive to print, internationally
> recognized (border-less), fits in a wallet, and machine readable.
>
> I pitched this idea at the Cincinnati Bitcoin meetup last week, and I
> didn't get thrown out, so I took the time to document a proposed
> standard to accomplish this.  I've put my ideas into BIP format, so
> that you can see what I have in mind, although I picked some
> BIP numbers myself that seem to be available.  Call them "proposed
> proposals", or "provisional BIPs".  I've numbered them provisionally
> BIP-80 to BIP-84.
>
> If you guys think that this idea has some merit, let's discuss.
>
> https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki
>
> Submitted with humility and some fear of getting laughed out of here...
> - Jerry
>
>
>
>
> ------------------------------------------------------------------------------
> "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: 3534 bytes --]

Re: [Bitcoin-development] Paper Currency

[Matt Whitlock]

On Saturday, 17 May 2014, at 11:31 am, Jerry Felix wrote:
> I picked some BIP numbers myself that seem to be available.

I'm quite certain you're explicitly *NOT* supposed to do this.

[Bitcoin-development] Paper Currency

[Jerry Felix]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

It seems to me that there's a huge need for a paper currency that is counterfeit-resistant, inexpensive to print, internationally recognized (border-less), fits in a wallet, and machine readable.

I pitched this idea at the Cincinnati Bitcoin meetup last week, and I didn't get thrown out, so I took the time to document a proposed standard to accomplish this.  I've put my ideas into BIP format, so that you can see what I have in mind, although I picked some 
BIP numbers myself that seem to be available.  Call them "proposed proposals", or "provisional BIPs".  I've numbered them provisionally BIP-80 to BIP-84.

If you guys think that this idea has some merit, let's discuss.

https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki

Submitted with humility and some fear of getting laughed out of here...
- Jerry


 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1122 bytes --]