Paper Currency
30 messages, 17 to 20 May 2014. Started by Jerry Felix.
Alex Kotenko (6), Mike Hearn (4), Peter Todd (3), Jerry Felix (2), Greg Maxwell (2), Andreas Schildbach (2), Natanael (2), Matt Whitlock, +8 more
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
On Saturday, 17 May 2014, at 11:31 am, Jerry Felix wrote:
Quoted text (1 line)
> I picked some BIP numbers myself that seem to be available.
I'm quite certain you're explicitly *NOT* supposed to do this.
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:
Quoted text (34 lines)
> 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
On Sat, May 17, 2014 at 9:07 AM, Chris Pacia <ctpacia@gmail•com> wrote:
Quoted text (2 lines)
> 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.)
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>:
Quoted text (48 lines)
> 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
>Quoted text (5 lines)
> 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.
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>:
Quoted text (24 lines)
> > 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 >
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>:
Quoted text (93 lines)
> 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
>
>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:
Quoted text (36 lines)
> 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 >
Erm, few things here. - I can't see really how to embed electronics capable to run an SPV client 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>:
Quoted text (13 lines)
> 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>: > >
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
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>:
Quoted text (35 lines)
> Erm, few things here. > - I can't see really how to embed electronics capable to run an SPV > client 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>: >> >> >
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>:
Quoted text (47 lines)
> 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 >> client 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>: >>> >>> >>
Quoted text (2 lines)
> 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.
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:
Quoted text (9 lines)
> > > 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
Quoted text (16 lines)
>> 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
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
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>:
Quoted text (49 lines)
> >> 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 >
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>:
Quoted text (28 lines)
> 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 >
someone recently wrote (not pointing fingers, nor demanding a spirited defense from that person, its a generic comment):
Quoted text (1 line)
> 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
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.
On 05/19/2014 02:21 PM, Mike Hearn wrote:
Quoted text (10 lines)
>> 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?
On 19 May 2014 17:09:07 CEST, Mike Hearn <mike@plan99•net> wrote:
Quoted text (19 lines)
>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.
On 19 May 2014 20:20:40 CEST, Justus Ranvier <justusranvier@gmail•com> wrote:
Quoted text (8 lines)
>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.
Quoted text (4 lines)
> > 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.
Quoted text (4 lines)
> 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.
On Mon, May 19, 2014 at 8:09 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (3 lines)
> 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.
On 19 May 2014 20:43:15 CEST, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (8 lines)
>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?
Quoted text (4 lines)
> > 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.
On Mon, May 19, 2014 at 5:09 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (2 lines)
> 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.)
On Mon, May 19, 2014 at 10:47 AM, Adam Back <adam@cypherspace•org> wrote:
Quoted text (3 lines)
> 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