[Bitcoin-development] About the small number of bitcoin nodes
About the small number of bitcoin nodes: Hi, I read the message that Mike Hearn sent to this mailing list some days ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes. As an owner of two Bitcoin Nodes, one in my home computer and one in a dedicated server, I believe I can contribute with some of my thoughts and ideas: - Allow users to view the bandwith used by Bitcoin Core: This is available in the Bitcoin Core GUI (btw, when the computer is restarted the data gets reseted) but I cant find it in the bitcoind commandline, people that run nodes want to see the amount of GB that they have "donated" to the network. - Educate users about the correct setup of a bitcoin node: Add a page in the bitcoin.org website with a tutorial about running Bitcoin Core with the ports opened, about runing bitcoind, etc. This guide shoud not be for regular users but for advanced ones. - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first start: The first time the software should create a default config file with a random RCP password and username (user can change it later) and the config file should be commented so the user can know how to change configurations. This is very useful in setups without GUI, for example in Ubuntu Server. - bitcoind and Bitcoin Core should be in Linux repos: People want to type "yum install bitcoind" or "apt-get install bitcoind" and install bitcoin. No one wants to follow a tutorial made by somewho saying that you have to add external repos to install bitcoin in your server. For example Electrum has been added to Ubuntu software center recently. Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu Server repos. - Create a "grafical interface" for bitcoind on Linux servers: Create a command, for example "bitcoind show" that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say "grafical interface" I mean like "top" command, an interface made out of characters in ASCII. - Split Bitcoin Wallet from Bitcoin Node: I believe that this is planned, some people want to help the network and others want to keep a wallet, someones want both. With bitcoind you can use the option "disablewallet=1" that allows to save some memory. - Inform users if 8333 port is closed: That should be more visible, I dont mean an alert or warning but some icon. - Keep connections if bitcoind is restarted: I noticed that if I restart bitcoind (to apply new config) my reset to 0 and take some hours to rise up to ~40. I believe that my peers should notice that I am down for less than ~15 minutes and try to connect again faster. Thanks for reading -- "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
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" : > 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 : > >> 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" : >> >> > -- "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
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 -- "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
Re: [Bitcoin-development] Paper Currency
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 : > 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" : > > -- "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
[Bitcoin-development] About the small number of bitcoin nodes
About the small number of bitcoin nodes: Hi, I read the message that Mike Hearn sent to this mailing list some days ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes. As an owner of two Bitcoin Nodes, one in my home computer and one in a dedicated server, I believe I can contribute with some of my thoughts and ideas: - Allow users to view the bandwith used by Bitcoin Core: This is available in the Bitcoin Core GUI (btw, when the computer is restarted the data gets reseted) but I cant find it in the bitcoind commandline, people that run nodes want to see the amount of GB that they have "donated" to the network. - Educate users about the correct setup of a bitcoin node: Add a page in the bitcoin.org website with a tutorial about running Bitcoin Core with the ports opened, about runing bitcoind, etc. This guide shoud not be for regular users but for advanced ones. - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first start: The first time the software should create a default config file with a random RCP password and username (user can change it later) and the config file should be commented so the user can know how to change configurations. This is very useful in setups without GUI, for example in Ubuntu Server. - bitcoind and Bitcoin Core should be in Linux repos: People want to type "yum install bitcoind" or "apt-get install bitcoind" and install bitcoin. No one wants to follow a tutorial made by somewho saying that you have to add external repos to install bitcoin in your server. For example Electrum has been added to Ubuntu software center recently. Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu Server repos. - Create a "grafical interface" for bitcoind on Linux servers: Create a command, for example "bitcoind show" that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say "grafical interface" I mean like "top" command, an interface made out of characters in ASCII. - Split Bitcoin Wallet from Bitcoin Node: I believe that this is planned, some people want to help the network and others want to keep a wallet, someones want both. With bitcoind you can use the option "disablewallet=1" that allows to save some memory. - Inform users if 8333 port is closed: That should be more visible, I dont mean an alert or warning but some icon. - Keep connections if bitcoind is restarted: I noticed that if I restart bitcoind (to apply new config) my reset to 0 and take some hours to rise up to ~40. I believe that my peers should notice that I am down for less than ~15 minutes and try to connect again faster. -- "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] Bitcoin Protocol Specification
Suggestion: maybe you want to write and post here a paragraph summarizing the topic of your paper so people can know if they feel qualified and if they need to review it from their interests. Adam On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote: >Dear all, > >I'd like to kindly ask, those of you that have a bit of spare time, to >take a look at a Bitcoin protocol specification I've written. It is still >in development and, as some of you have already indicated, needs >improvement. I'd be very thankful if some of you could take the >time to review it. If there are any errors or suggestions from your >side, I'd gladly hear them. My e-mail can be found on the front page >of the document: > >http://enetium.com/resources/Bitcoin.pdf > >Warm greetings, >Chris > > >-- >"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
Re: [Bitcoin-development] Paper Currency
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 > -- "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
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" :
> I had a long discussion recently with somebody who wants and has resources
> to do exactly this - paper currency representing bitcoins. Yet we've been
> thinking mostly about a centralized solution, where one party is producing
> and maintaining paper currency, with bitcoins tied to each note verifiable
> via blockchain.
>
> The points we've ended up is that it needs to be:
> - reloadable
> - NFC based
> So anybody can verify any notes instantly by just touching it with his
> phone, and so merchants could redeem the notes at the moment of accepting
> it, convert it into fully online bitcoins and avoid costs of maintaining
> paper money turnover. Probably merchant would sell back redeemed
> empty notes to the issuer for a price of the note issue, and issuer will
> recharge it and put back into circulation.
>
> One problem we couldn't figure out here though - how to protect the notes
> from unauthorized redeem. Like if someone else tries to reach your wallet
> with his own NFC - how can we distinguish between deliberate redeem by
> owner and fraudulent redeem by anybody else with custom built long
> range NFC antenna? Any ideas?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-17 17:40 GMT+01:00 Gregory Maxwell :
>
>> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia wrote:
>> > I can't really just hand someone the note and walk away
>> > because they have to scan it to see if it is actually valid.
>>
>> Not just scan it, but they actually must successfully sweep it—
>> 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
>
>
--
[Bitcoin-development] Bitcoin Protocol Specification
Dear all, I'd like to kindly ask, those of you that have a bit of spare time, to take a look at a Bitcoin protocol specification I've written. It is still in development and, as some of you have already indicated, needs improvement. I'd be very thankful if some of you could take the time to review it. If there are any errors or suggestions from your side, I'd gladly hear them. My e-mail can be found on the front page of the document: http://enetium.com/resources/Bitcoin.pdf Warm greetings, Chris -- "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
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 : > > 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 > -- "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
> 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
Re: [Bitcoin-development] Paper Currency
I had a long discussion recently with somebody who wants and has resources
to do exactly this - paper currency representing bitcoins. Yet we've been
thinking mostly about a centralized solution, where one party is producing
and maintaining paper currency, with bitcoins tied to each note verifiable
via blockchain.
The points we've ended up is that it needs to be:
- reloadable
- NFC based
So anybody can verify any notes instantly by just touching it with his
phone, and so merchants could redeem the notes at the moment of accepting
it, convert it into fully online bitcoins and avoid costs of maintaining
paper money turnover. Probably merchant would sell back redeemed
empty notes to the issuer for a price of the note issue, and issuer will
recharge it and put back into circulation.
One problem we couldn't figure out here though - how to protect the notes
from unauthorized redeem. Like if someone else tries to reach your wallet
with his own NFC - how can we distinguish between deliberate redeem by
owner and fraudulent redeem by anybody else with custom built long
range NFC antenna? Any ideas?
Best regards,
Alex Kotenko
2014-05-17 17:40 GMT+01:00 Gregory Maxwell :
> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia wrote:
> > I can't really just hand someone the note and walk away
> > because they have to scan it to see if it is actually valid.
>
> Not just scan it, but they actually must successfully sweep it—
> 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
