Bitcoin Forum

Yes, provovative, but here is the problem.

The curent client is not only bad UI Wise, it also is unsafe and not controllable for an enterprise level application, and enterprise level is what you WANT and NEED. As in: you need to provide an infrastructure (or have one provided) that is programmed in a way to handle (a) million usd deposits with safety and (b) enterrise level authorization scenarios.

The following should be possible:

* Isolating a wallet level client and a node that works on transactions. More code = more attack surface, make my wallet smaller.
* separate authentication for outgoing payments.
* Read only access to wallet only after authorization, encrypt it yourself.
* Allow automatic distribution of wallet and keys between authenticated servers (to faciliate a key loss / wallet loss, which both are devastating scenarios).
* Provide an easy to use API to enter payment requests and get incoming funds. API should handle authentication and authorization.
* Provide automatic forwarding of funds to backup / store addresses. Money comes in,gets send to a separate address.
* Provide "accounts", not addresses. Addresses are arbitrary small. The software should be able to form logical accounts from those. Especially as addresses may be "one time use".
* Provide access to an external WORM space to handle keys. For example sending keys (private) over SERIAL CABLE (!) to another box. Point being: Serial cable is not network, so it is quite impossible to use as a standard attack vector, and the backup box would keep a log of all keys. Or... a printer ;) If every private key gets printed out, a computer crash can not harm them. Been there, implemented somehting along these lines for an online payment provider years ago (every transaction goes to an audit computer via serial + is printed for later scanning in case of a total computer attack).

The end problem is: if I have 100.000 BTC somewhere stored and am an enterprise (and large values have to be possible) then right now I run a high risk setup. None of the normal provisions are in place that my bank gives me. Unless you want this totally to be a bank service (and finding a bank doing this is hard - banks are HEAVILY regulated) this means that the BTC handling is very insecure. And burying it in a vault somewhere is not practical if it is your operating capital.

My bank gives me a lot of features, from nice account statements to an API and a 4 eye principle acount (one person enters transfer, other person has to approove them) to make sure money is not "diverted". Money loss is also a high risk and now way too technical - with a lot of manual intervention.

The end idea should be / would be to have a system that can be installed as a small harware applicane (in a cluster of x) that servves are wallet server. This can then be secured highly (physically) and provides an API that is enterprise level, so my secretary handling my transfers does not run with my money ;)

This, a separate node for processing (no ui needed) and at the end a friendly end user installable client are needed to get out of funny geeky space.

Don't count on services to take over - so far I know of not a single "exchange" adhering to minimal financial standards, and no virtual bank at all. And even then, at the end...  it sould have t operate with a pretty bad infrastructure.

Too much "should", "need", "we", too little "i've contributed", "come test my addition" etc.

Yes. Say that to all people needing something ;)

I try to get "this thing" into my financial infrastructure - which just happens to be a little more complicated than "typical miner in his basement". More complicated like "multiple levels of security and different workstations where you can move moeny at the press of a button".

What about: Willing to pay for a company level solution.

OP: If you think we should/need this then get to building it. If you can't do this yourself then put together a solid business plan, recruit people and issue shares. Who knows, I might even throw some BTC your way.

I like this idea, you should give more details about what exactly you want to do.

I'm thinking about writing a simple client whose purpose would be to help facilitate a large money storage area - a lock box. 

The concept is to take large quantities of Bitcoins and dump them offline where they can be stored onto (gasp) paper.  Paper has some benefits for wealth storage.  I don't have to worry about viruses.  It's not "easy" for someone remotely to steal a copy, etc.


The software would behave like this:

1) When you run it, the program creates a new wallet key pair.  Not 100 like the current client, but just one (or as few as necessary).
2) It creates a new wallet file, with a name different from wallet.dat, containing public and private keys.  Let's call it lockbox.dat.  The idea is that this is a MINIMAL file - as small as possible.
3) It connects to the bitcoin network like all other clients.
4) You can transfer funds to this wallet (or lockbox) using your normal client.
5) You can print out the contents of the lockbox file in Hex or other readable characters.
6) You can select a function named  "shred" or "destroy" - which, after confirmation that you really want to do this, overwrites your lockbox.dat file with random zeros and ones.  You now have only the printed copy of your lockbox file - no electronic version.
7) You can select "recreate", which allows you to type in your lockbox file to get your money into electronic form again.



Is there any value in this?   I think I can do it by modifying the current client to eliminate a lot of the current functionality, and add in a few simple functions listed above.

Any suggestions for improvement?  Should this be a feature of the current client, or a separate program?

Your logic is flawed.  Storing Bitcoins on paper doesn't prevent the software bugs that could wipe out your wallet and/or transactions.

The paper isn't good by itself.  It would have to be reloaded into the "flawed" software to get them back into the network.

QRCode.

Simple commercial equipment that most people already have are capable of importing/exporting.  Nearly nonexistent chance of decay/corruption if printed reasonably big.

Wallets could be stored like real-world savings bonds and cashed in from a paper document.  Any transfers made while the wallet was inactive will still apply.

Keep in mind that when people do backup what they really want is restore. Therefore it would be great if your program made a successful restore required to mark a backup successful.

How is my logic flawed? 
I am not saying it is a perfect system, but I am saying that it is far easier for me to be sure that there is no virus on a PC on just two occasions - once at the storage to the lockbox and once at the restore from the lockbox, than it is to assure that there is no virus on my PC EVER.

Do others agree that this is a flawed idea?



I believe that Bitcoins will be under attack by virus writers in the coming six months, and that will be a serious blow to their acceptance.  Considering how many zombie PC's are out there as part of botnets, if any one of them gets a wallet.dat file, it'll be stolen.  And, with zero-day vulnerabilities being discovered regularly, I am not willing to risk a large store of my wealth in one place online.

I know personally this is my biggest fear of having a sizable amount of Bitcoins in one place.  I don't fear that they will be worthless or that the crypto will be hacked external to my PC.  I don't worry that my file will get destroyed without a backup.  No, I worry that the PC will get a virus and the file will be copied.

Remember, Bitcoins are never gone from the network.   Even "lost coins" are still in the block chain.


Of course.  Silly of me not to think of that.  That's a much better solution, assuming the file can be small enough.  And a series of QR codes is a much better solution if it doesn't fit into a single one.

The easiest way I know of to print a QR code is to use the Google Graphs URL, but that would obviously introduce a security hole - passing the lockbox codes over the net to Google.  I'll have to check into open source QR code generators - looks like there are several on sourceforge.

I think paper can be a very good storage medium that doesn't suffer from that are specific to computer storage.
It's not a complete answer, but it has very interesting properties to store BTC.

Implementing a QR code output is pretty trivial.

I think that's crazy.  My opinion.  Paper is terribly suspect to all sorts of disasters that electronic documents are not.  If you're worried about your wallet.  Encrypt it, then store it on various USB drives, put them in lockboxes, and also store them in multiple cloud providers.  Printing the wallet on paper means that wherever you store that paper you have to ensure the entire physical environment.  That's why people have safety deposit boxes and fire safes.  To protect paper documents and even then there are massive losses to them.  I still have electronic documents from 30 years ago (and yes, I know there are paper documents preserved for hundreds, even thousands of years). 

Just make sure you're printing on acid-free, high-quallity paper and that it's stored in an environment to prevent decay, yellowing, and other environmental issues.  Because if just 1 tiny little block in the QR code becomes unreadable, or the ink/toner flakes off.  You've lost the whole thing.  Oh, and make sure you store the electronic software to read that code with it.  Because software updates, and if you don't update the codes with the software, you run the risk that the latest generation software cannot read your code.

Go back and try and open a PGP Encrypted Disk from 1998 (the commercial software, not the open source software).  The software to do it doesn't exist today, you have to have the original software you used back then.  Same thing with Tax record files you created with TurboTax 2000, TurboTax 2011 won't open them.

Print the key in plain text in multiple copies then, put it in a couple of sealed envelopes at a notary office

if the client had multi-wallet support and address balance differentiation, it would alleviate many of these problems.

And what does that buy you over just having multiple electronic copies?

Trojans can't read paper.
You can also combine both

So now we're back to having a computer, infected with a Trojan, that you're keeping your bitcoins safe by having them printed on paper.  So, do you figure out you have a trojan before reading them into your computer?  How?  You got the trojan, so obviously your method of detection is flawed, or else you could use it all the time.

I'll give you that you could build a new machine from scratch, not attached to the Internet, then read the coins into the "clean" machine, possibly even then use them without "fear".  However, once attached to the Internet you have all of the inherit problems you were trying to avoid in the first place, and are you really going to go to all of this trouble every time you wish to spend or save coins?

That's like keeping all of your money in a safe deposit box, in cash, and only spending cash for purchases.

Every method obviously has its flaws, it's up to you to pick what makes the most sense, paper has its own advantages that electronic storage does not have, end of story.

a new bitcoin client would certainly go a long way toward helping bitcoin itself.

for one we should have a loadable, savable, and deliberately encrypted wallet.dat files there is no reason not to encrypt them as it stands... i am pefectly capable of entering a password when wanting to send BTC or check my balance.

paper is handy for backups, and I agree that there should be a method.. be it QR codes, or making a plaintext version of the wallet.dat and printing it out.

no matter what anyone says about the durability of paper, there are very few mediums that have survived over 2000 years, most digital variants never will. Burned CDs are only good up to 10 years usually, tape even less unless very well kept, flash chips are even worse for long term storage. (sorry USB stick lovers!)

The mining focus is bad: we need a better infographic!

Flat out false.  QR Codes have redundancy in them.  Level H codes can recover from errors up to 30%. (http://en.wikipedia.org/wiki/QR_code#Storage)



You need to be considering the case of people who have substantial amounts of wealth in Bitcoins.  Say I have $100,000 worth of Bitcoins.  What you are suggesting is that I make a $100,000 wager that I can keep my computer free of zero-day viruses, FOR LIFE.  I am not willing to make that bet.  It is, after all, a Windows machine.

Making backup wallets and storing them for years makes a lot of sense.  Paper is far more durable than any electronic medium.  What medium would you suggest that is going to last 100 years?  Floppy?

quote author=pickerin link=topic=12271.msg193197#msg193197 date=1307658904]
That's like keeping all of your money in a safe deposit box, in cash, and only spending cash for purchases.
[/quote]

You need to be considering the case of people who have substantial amounts of wealth in Bitcoins.  Say I have $100,000 worth of Bitcoins.  What you are suggesting is that I make a $100,000 wager that I can keep my computer free of zero-day viruses, FOR LIFE.  I am not willing to make that bet.  It is, after all, a Windows machine.

Making backup wallets and storing them for years makes a lot of sense.  Paper is far more durable than any electronic medium.  What medium would you suggest that is going to last 100 years?  Floppy?
[/quote]

Any single media?  None.  However, I have electronic documents that I've kept around for 25+ years.  How?  I keep the media they are stored on current.  When I upgrade my laptop, the documents get moved to a new one.  That laptop is then backed up in 3 different places.  So, I have four copies in different locations.

You're comparing a medium that has been around for thousands of years, to a medium that has been around for less than 100.  You have no idea which will prove better in the long run.

If you wish to backup your life savings in Bitcoins to a paper document, knock yourself out.  I'll be backing mine up electronically.

My argument wasn't which was better as a backup medium (go back to the first page), it was an argument against paper as a way of safeguarding bitcoins against errors in coding and/or viruses.  I'm not saying paper won't work.  I'm saying if you're putting it on paper to avoid problems in the electronic environment, you're kidding yourself, because in order to use the paper, you have to make it electronic again, and at that point, you have all of the detriments of it being electronic again.

actually they have proven the viability dates on most of the modern media.. its atrocious.

the best CDs, glass with pure metal film sandwiched between.. can go for maybe 100 or 200 years they guess.. but outside that, your best bet is actually microfilm stored in a dark dark place, or paper.

And once again, I'll repeat that there's a substantial difference between betting that you don't have a virus twice - once at storage time and once at retrieval time - and betting that you won't EVER have a virus between today and the date the funds are needed.