[Bitcoin-development] Paper Currency

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

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.

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

[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

[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

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

[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

[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

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

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

[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

[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

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

[Bitcoin-development] patents...

[Adam Back]

someone recently wrote (not pointing fingers, nor demanding a spirited
defense from that person, its a generic comment):
>   PS: the device has patents pending

btw about patents, I wonder if people who feel the need to do that, would
you consider putting those patents into like a linux foundation defensive
pool?

I imagine a number of other bitcoin companies have patented things, but if
you think ahead a little bit, or look at prior ecash history, patents held
by individuals or companies can be outright dangerous.  

We saw this in the past eg the digicash patents after the company went
bankrupt were sold by the investor to some random large company that parked
it in its huge pile of patents, didnt use it, and prevented anyone else from
using it - stalling Chaum dependent payment innovation for perhaps 5 years
until the thing expired, and a Chaum patent expiry party was held.

Just some food for thought.

hmm Yes and this topic now is more than a bit non dev related.  Sorry about
that.  There seems to be no convenient mailing list format for non-dev stuff
or I would Cc and set Reply-To for example?  (Web forums somewhat suck IMO). 

Adam

Re: [Bitcoin-development] patents...

[Mike Hearn]

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

IMO this list is fine for discussing such topics.

Here are some thoughts. I had to deal with patents at Google (my name is on
a few, not my choice unfortunately). Many aspects of patent law are deeply
unintuitive, so here's the crash course as I was given it.



The first rule of patents is *you do not go looking for patents*. US law is
written in a really stupid way, such that if you knowingly infringe,
damages triple. Because America uses the patent office as a revenue source,
basically everything you can possibly imagine is covered by some ridiculous
patent so if you go looking you will always find applicable patents on
every idea and then you end up potentially much worse off.

Most companies (Google certainly included) have therefore banned their
staff from reading patents, thus ensuring that the whole point of them, the
sharing of knowledge, doesn't actually function! And it's much better I
think if we follow the same policy. So *please do not ever mention that
suchandsuch is patented on this list*! When it comes to patent law,
ignorance is bliss. Patents are written in a heavily obfuscated manner such
that actually trying to learn from them is hard work anyway.


One reason I wrote up the contracts stuff when I did is to get it out there
into the public domain, so people couldn't patent the basics of the Bitcoin
protocol. It'll be much better for everyone if new ideas are just put right
out into the public domain. *Please do not patent Bitcoin related research
you do*, even if you think it's for the best:

1) Defensive patenting doesn't work. The whole idea was mutually assured
destruction, you hit me I'll hit you type of logic, but the prevalence of
shell/troll companies killed off that idea. Plus it turns out that big
companies are quite willing to sue each other into oblivion anyway. Once a
patent exists, it'll be used as a weapon by someone eventually, and
attempting to "fight back" is probably not a workable strategy. Far better
to ensure the material is simply unpatentable by anyone.

2) Patenting with the intention to sue people using Bitcoin in the same
way: well, if you plan to do this, there's not much to talk about .... you
won't make any friends this way.

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

Re: [Bitcoin-development] patents...

[Peter Todd]

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



On 19 May 2014 17:09:07 CEST, Mike Hearn <mike@plan99.net> wrote:

>The first rule of patents is *you do not go looking for patents*. US
>law is
>written in a really stupid way, such that if you knowingly infringe,
>damages triple. Because America uses the patent office as a revenue
>source,
>basically everything you can possibly imagine is covered by some
>ridiculous
>patent so if you go looking you will always find applicable patents on
>every idea and then you end up potentially much worse off.
>
>Most companies (Google certainly included) have therefore banned their
>staff from reading patents, thus ensuring that the whole point of them,
>the
>sharing of knowledge, doesn't actually function! And it's much better I
>think if we follow the same policy. So *please do not ever mention that
>suchandsuch is patented on this list*! When it comes to patent law,
>ignorance is bliss. Patents are written in a heavily obfuscated manner
>such
>that actually trying to learn from them is hard work anyway.

Meh. The world is much bigger than the USA. Secondly that rule makes it difficult to educate people about why patents are as bad as they are.

Feel free to continue censoring your own discussion within closed corporate environments. But to say keeping patent discussion off mailing lists is appropriate or wise when the tech news is full of such discussion is silly.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJTekz8MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhX0TB/wNZoi5sWj6n3fM7O7T
emVbrVpuBwOvUEJAFYGmXgb2KXGdheVRhXfcwteQybLG+M+Ra/HAqLq+1YrPmopE
QeldiSc31KAkVLYXQMIfD6QO1PBlvKP7qPLqBEpCc9ocd8XLppTPQ2K8o5soV8VF
z6Jt/Hh74xhkhhb/kEzsQ8YKkg+m26WY9Yggu0Qxtb0OTjL86IhEKpH9ijr08jvV
TKs+PHwou5rt0dT3vqLd8ogb7xihTPx/7tciaXHCOfvxGsEgtqdTsjdHlCJ6cR9a
DrZcrIQnX+s1+YbHs3P4kyBfzNHBwwVuwaf5W5pU6vFp276jhsgT/65J7PqoRmxK
AkXg
=dk4R
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] patents...

[Mike Hearn]

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

>
> Meh. The world is much bigger than the USA. Secondly that rule makes it
> difficult to educate people about why patents are as bad as they are.
>

You can easily find examples that are not relevant to Bitcoin if you want
to discuss the patent system in general.


> Feel free to continue censoring your own discussion within closed
> corporate environments. But to say keeping patent discussion off mailing
> lists is appropriate or wise when the tech news is full of such discussion
> is silly.


It is both appropriate and wise. Please keep discussion of Bitcoin-relevant
patents elsewhere.

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

Re: [Bitcoin-development] patents...

[Gregory Maxwell]

On Mon, May 19, 2014 at 8:09 AM, Mike Hearn <mike@plan99.net> wrote:
> The first rule of patents is you do not go looking for patents. US law is
> written in a really stupid way, such that if you knowingly infringe, damages
> triple. Because America uses the patent office as a revenue source,

You have received outdated advice on this point. In Re Seagate
(http://patentlyo.com/patent/2007/08/in-re-seagate-t.html) this
precident was over-turned (and has subsequently been upheld in other
cases). Avoiding willfull infringement no longer requires paying off a
patent attorney to get a freedom to operate review.  This isn't to say
that reading patents is always productive now:  They're often nearly
inscrutable (especially to people without substantial patent reading
experience), and you may discover potential infringement that creates
more work for you to sort out (especially since people without patent
experience tend to read patents much more broadly than they actually
are).

There are other defensive approaches which are interesting than hoping
to use patents as a counter attack: For one— filing a patent gets the
work entered in the only database that USPTO examiners are
_guaranteed_ to consult when doing a prior art search, so it may have
a fighting chance of precluding someone else patenting the same
material later (they may also search the internet and use other
resources, but they're guaranteed to consult the existing patents and
applications). Patents can also be used defensively as leverage in a
licensing negotiation: Without your own patents you don't get invited
to the negotiating table at all with someone else who may hold patents
in a space that you're working on.  These are somewhat thin advantages
so great care is required to make sure that things are setup so that
badness cannot happen later when inevitable changes of ownership
happen.

Re: [Bitcoin-development] patents...

[Peter Todd]

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



On 19 May 2014 20:43:15 CEST, Gregory Maxwell <gmaxwell@gmail.com> wrote:

>There are other defensive approaches which are interesting than hoping
>to use patents as a counter attack: For one— filing a patent gets the
>work entered in the only database that USPTO examiners are
>_guaranteed_ to consult when doing a prior art search, so it may have
>a fighting chance of precluding someone else patenting the same
>material later (they may also search the internet and use other
>resources, but they're guaranteed to consult the existing patents and
>applications).

Interesting. Is that to say a viable strategy would be to apply for patents and let the application lapse?
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJTelGCMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQPlCACjJgJEyMYMtF+/dJJh
TgWfVuE7E7QmwgWoQMBo7/5LgO1W5PQt9d3jfQ7gkrdCqTWs4HtA3lcgjdeEQ6ZW
QvMFG5/xITVi85v2zlE9CteQZXLBTSI+J7VlkjqnJeftQkklvGjiDtNfaDDsTacV
ZNem06V4fmBxNgzqmit2Roilp+NMQb2iM9Ofkr5FbI0cT/kzD/IJd2+Crqsu/uDU
8r2YQY0bbEf2wqxVdq5TSf1rFqqnWKHB3lD1GGRJ8n5BciBmysZL43jct8YABSgi
BHFpJP2ii7gz076mRiBb+KwCo+1xKUYNpsJk1m7HND7PjqkXps+JHiNaWdr9vAxx
raFO
=L1oX
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] patents...

[Mike Hearn]

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

>
> Avoiding willfull infringement no longer requires paying off a
> patent attorney to get a freedom to operate review.  This isn't to say
> that reading patents is always productive


That case raised the bar a bit, but the core problem remains - if you learn
about a patent you definitely violate (and there is very likely to be at
least one and possibly many), via whatever means, then by continuing
business you become a wilful violator. Which makes sense: how could it be
any other way?

It still never makes sense to read patents. You can only lose.

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

Re: [Bitcoin-development] patents...

[Bernd Jendrissek]

On Mon, May 19, 2014 at 5:09 PM, Mike Hearn <mike@plan99.net> wrote:
> Most companies (Google certainly included) have therefore banned their staff
> from reading patents,

Bitcoin is not Google though, and applying the same patent protocols
to Bitcoin as in Google is drawing a false equivalence between the
two. Google can survive single or triple damages, so it makes sense to
hope that of those patents you necessarily violate due to the size of
your operations, they attract only single damages. Google has so many
fingers in so many pies that violating some patents is a question of
when, not if. Bitcoin has a far narrower scope than trying to take
over the world (and moon).

Happy reading: http://endsoftpatents.org/2010/03/transcript-tridgell-patents/

TL;DR: If even single damages result in commercial death, you better
pay attention to patents, to reduce the chances of accidentally
running into one.

(But Bitcoin is not ccache either - it's all about money and it isn't
inconceivable that a patent infringement suit might not result in
commercial death. The right answer here isn't as obvious as you make
it out to be.)

Re: [Bitcoin-development] patents...

[Jeff Garzik]

On Mon, May 19, 2014 at 10:47 AM, Adam Back <adam@cypherspace.org> wrote:
> hmm Yes and this topic now is more than a bit non dev related.  Sorry about
> that.  There seems to be no convenient mailing list format for non-dev stuff
> or I would Cc and set Reply-To for example?  (Web forums somewhat suck IMO).

There is the little-used "bitcoin-list" on SourceForge that claims a
rubric of "general discussion":
https://sourceforge.net/p/bitcoin/mailman/?source=navbar

I just subscribed there.

We can "reboot" that list with a couple new rules such as
a) be good to each other.  consistent rude behavior gets the boot.
b) anything related to decentralization, consensus, proven data
structures or crypto is on-topic

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

[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

[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

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