Implementation and CONOPS for Convenient, Optimal-Security BTC Client

[etotheipi]

I'm working on my own implementation for this idea, but I'm sure others might like it and be inclined to incorporate it into their own clients.  I'd love to see it somehow implemented in the ref client.  

I think this idea is critical for BTC to be adopted by businesses and would also be quite useful for regular users.  I will use the small business as the target user here.

The basis for this concept is some solid crypto-magic for deterministic wallets with predictable public keys. I can describe the cryptography separately, if desired, but it is actually quite simple, secure, and has the following properties:

• Private keys are computed based on only two 256-bit numbers: a private-key-generator and a "chaincode".
• All publickeys/addresses can be computed with only the first public key and the chaincode.
• Wallets can be backed up once, forever, and an online computer can generate new addresses without needing any of the private keys!
• Without the chaincode, there is no verifiable link between any of these addresses.

   

My proposal is to implement a new mode in the Satoshi client, or a new client altogether this idea.  Here is the CONOPS for a small business using this technique to run an online store.  I will refer to them as the "vendor."

• Vendor buys a $200 netbook and puts it in the back corner of their office without an internet connection
• Vendor generates a new wallet on this offline computer based on this generator&chaincode technique
• Vendor clicks a button to generate two files:  
  FileA.priv ={PrivateKeyGen (256bits), ChainCode (256bits)}
  FileB.pub ={FirstPublicKey (512bits), ChainCode (256bits)}
• Vendor permanently backs up FileA.priv to paper/USBkey/floppydisk/CD/tattoo.  They would probably keep this in a safe-deposit box.
• Vendor copies FileB.pub to a USB key and copies it to their webserver that runs their online store.  They click a button to create a special WatchingOnlyWallet, select FileB.pub from the USB key.
• Vendor also creates a small online wallet for refunds.
• When customers purchase items they are given a new address by the server in one of two ways:
     --Generate a new public key based on the chaincode technique for the offline wallet
     --If the refunds account is low, generate a new address for that account
• Client watches the blockchain and can confirm that payment was received.  Waiting an hour for 6 confirmations is acceptable before shipping the products
• To move money to another account (or boost the refund account) they click a button on their online client to copy verified tx data to USB key (or the whole blockchain)
• The key is inserted into the offline computer and the client automatically detects and updates its own blockchain/database of transactions
• Vendor enters an amount and address to which he wants to move his money, computer saves a FileC.signedtx to the USB key
• Vendor inserts USB key into the online computer, clicks a "Broadcast Offline Tx" button, selects the FileC.signedtx
• Profit!

This mode of operation has a plethora of benefits to all users:
--Private keys for majority of savings never touches the internet -- optimal security!
--Has high level of convenience for the user/vendor, given the fact their private keys are offline.
--Maintains a small spending account for the user/vendor online for sending small amounts of money, immediately.  Refilling the small online wallet can be "automatic" by the address-selection method.
--User only needs to backup their online and offline wallets once, ever
--Encryption of wallet on offline computer easy to integrate/use, in case of stolen property

The one downside to this method is: if the chaincode is compromised, then someone can immediately associate all transactions processed by this wallet.  However, in most situations where the online computer is compromised, the compromised data would hold this information anyway (any wallet will contain all this data), so I don't see this as much more of a threat than the current wallets.  Plus, that's only a risk to privacy, but gives the attacker no way to spend the money.

Any thoughts on this process?  I think this, or something closely related should be a high-priority goal for BTC client development activities.
[/list]

[1715249391]

1715249391

[1715249391]

1715249391

[1715249391]

1715249391

[1715249391]

1715249391

[1715249391]

1715249391

[1715249391]

1715249391

[ElectricMucus]

Well assuming both computers run windows security of future transactions would be potentially compromised if the same usb key is used for more than one transaction.

[etotheipi]

Well assuming both computers run windows security of future transactions would be potentially compromised if the same usb key is used for more than one transaction.

This is a security-concern that the BTC developers have no control over.  It's up to the user to make sure their systems are patched and they're not vulnerable to malicious software, like hidden USB key viruses.  

Also, even the least tech-savvy would have no problem using Linux on the offline computer.  All modern Linux distributions have automatic USB mounting (without running anything on the key), and the user only needs to install/run a single program to use it.   I've heard there is even custom linux builds just for Bitcoin, which could have this client incorporated into it.  The user wouldn't have to do anything but insert their USB key and the computer would boot right into it.  I think it would be pretty damned tough to compromise this setup.

[2112]

OK, I'll bite again. Please don't take my reply as a personal insult.

I think you are nuts. "You" meaning "you plural", i.e. anyone who shares this idea.

"Satoshi bitcoin client" development speed had reached the stall speed. It is about to go tailspin anytime soon. Gavin is making heroic efforts to reject the patches/pulls that subtly change the behavior of the Bitcoin protocol, especially with respect to the chain reorganization.

What needs to be done is the following:

1) bitcoin needs to be refactored into two separate modules:
2) bitcoind which is a wallet-less daemon that handles the P2P network presence and caches the blockchain using some sort of general purpose database query language
3) bitcoinui which is block-chain-less wallet management utility that uses any one from the existing variety of security technologies. Some versions of it could handle people wallets in a really secure way (TPM, Sim-card, CONOPS, whatever else). Other versions wouldn't handle normal wallets but would be just interfaces to the existing mining pools.
4) the communication between the bitcoind & bitcoinui will require a known, well tested two-way communication protocol, e.g. FIX or QuickFIX FAST or anything else that gets some support in the existing securities industry and existing exchanges.

Trying to plow forward with JSON-RPC (or any other one-way protocol based on HTTP) or trying to reinvent and re-implement any of the well known in the securities industry methods of AAA (Authentication,Authorization&Accounting) is a form of slow-motion project strangulation.

Thank you for your (plural "your") attention.

[etotheipi]

I would absolutely love to have what you are proposing.  I believe that having a wallet-agnostic BTC engine that handles the networking and blockchain data with a communication interface for front-ends is critical to the future of BTC.  Having a single one-size-fits-all GUI stifles the overall potential of BTC, but countless developers have attempted to reimplement this in its entirety because what you propose doesn't exist; most have failed, and the remaining who are still plugging at it risk forking the blockchain when their client produces subtle differences on some kind of rare boundary-conditions. 

I've proposed your idea before (and I'm sure I'm not the only one), and Gavin himself responded that he would like to see this kind of architecture in the future.  Arguably, if Gavin was the only developer in existence, his efforts towards subtle protocol changes and handling blockchain reorganizations that secures the BTC network should probably be highest priority.  We're in agreement about that.   

But you missed two key components here: 
(1) I'm not talking about reinventing BTC networking/security protocols.  I'd love to have a robust, wallet-agnostic bitcoind to which I can connect my frontend and not worry about that stuff.
(2) My proposal is precisely the kind of application that fits into your concept here (bitcoinui).  It sits on top of bitcoind, it doesn't replace it.

This is a forum for technical discussion.  There's a lot of people here are working on other parts of the problem than just BTC protocol.  Even if all efforts could somehow be combined to help Gavin, we'd still be left with a boring (but extremely well-functioning) Bitcoin client that doesn't serve all the needs of all the users.  Just because things are not at the top of the priority list doesn't mean that no one should look at them until they become a priority.  And I believe one of the critical success factors for Bitcoin is having an intuitive, optimal-security, offline-wallet client that allows people and businesses to operate BTC accounts with maximum security and without need a master's degree in cryptography.   BTC protocol can be as rock-solid as Fort Knox, but if users can't figure out how to use it, it's going to fail.