Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: zwierzak on August 20, 2011, 10:00:29 PM



Title: Multiwallet bitcoind
Post by: zwierzak on August 20, 2011, 10:00:29 PM
A few days ago I was thinking what we can do to make bitcoind safer for „banks” or exchange and than I came up with idea of multiwallet bitcoind.

To access to wallet by JSON RPC we must to predefine rpcuser and password. Also to secure wallet we must start bitcoind on separate server than web interface, moreover we must connect to it only by connection like VPN. In near future bitcoind will also have possibility to encrypt wallet by password known only to owner.

But what about accessing to bitcoind by JSON RPC in this way:
- rpcuser defines which wallet file to select (ex. for user “zwierzak” we select “wallet_zwierzak.dat”),
- password isn't written in any database, because verification of user is successful decryption of wallet.
In this way you can have bitcoind on the same server on which you have web interface (not recommended) and stole password for all users accounts would be much harder than stole 1 global user password or get access to separated server.

So advantages:
- every user is responsible of safety of his wallet file,
- we could allow user to download their wallets to hard disk if they want (every user have separate encrypted wallet) and insert it into bitcoin client
- easier to make sure that crackers can stole only part of bitcoins

We must take care about:
- make sure that user use hard password (libcrack)
- username can contain only some characters (regexp: “[A-Za-z0-9\-_]”) to not allow to write something like “../../../etc/passwd”

But this makes 2 new problems:
- if user lost his password then it will be our fault that he lost his savings, because he can't decrypt his wallet
- exchange will not be in realtime, because if you use only one wallet and 1 address per user you calculate balance on your own. Outgoing money you can sign from everyone private key in wallet. But if you separate wallets that after transaction on site you need to transfer coins from one account to another. But this take time to conform transaction.

What do you think about it and will you be interested in this modification of bitcoind? Also do you have any idea how to solve this 2 problems? Or maybe you think that problems are somewhere else?


Title: Re: Multiwallet bitcoind
Post by: 2112 on August 20, 2011, 10:45:07 PM
I think you have it backward. What is required is a wallet-less bitcoind: a program that takes care of participating in the P2P WAN network and maintains a local copy of blockchain that is quickly accessible. On the LAN side it should accept requests to inject transactions and make callbacks upon seeing interesting public keys mentioned over the WAN.

Anything else is just an job security for the C++/boost/wxWidgets programmers and prolonging the opportunities to the hackers who endeavor to exploit the weaknesses of the current organically-grown client (because it would be a mistake to call it "designed").


Title: Re: Multiwallet bitcoind
Post by: casascius on August 20, 2011, 10:46:02 PM
I think you have it backward. What is required is a wallet-less bitcoind: a program that takes care of participating in the P2P WAN network and maintains a local copy of blockchain that is quickly accessible. On the LAN side it should accept requests to inject transactions and make callbacks upon seeing interesting public keys mentioned over the WAN.

Anything else is just an job security for the C++/boost/wxWidgets programmers and prolonging the opportunities to the hackers who endeavor to exploit the weaknesses of the current organically-grown client (because it would be a mistake to call it "designed").

+1000 - I AGREE - Thank God someone else sees this the same way I do.  May this thread be renamed "walletless bitcoind"!

Bitcoind should be a platform independent daemon that never handles private keys... ever.  It simply provides the Bitcoin "client service" for everyone on the LAN, as well as speaks P2P to the other nodes.

And then the client of that service can be a UI, which has no support for mining or P2P comms or finding peers on IRC.  It manages wallets, signs transactions, lets users keep track of their money.  It depends on bitcoind to learn the balance of all the addresses it manages, and to forward signed transactions to the rest of the network.

With that separation of responsibilities, third party clients will be a much less monumental task, and Gavin's task of managing the bitcoind codebase and keeping it secure will become much simpler.

I was thinking if I made a 3rd party client, I would simply require bitcoind as a dependency, and modify bitcoind to add a couple important RPC function: a "getunspenttransactions" that takes a list of bitcoin addresses and returns a listing of which unspent transaction IDs are worth how many BTC.  And a "submittransaction" that took a signed transaction for validation and forwarding (bitcoind would treat this the same as if it came from a peer via p2p).

This would be all bitcoind needs to completely function and do everything I'd want so I could write a new UI app (e.g. native to Windows, or one that stores privkeys on a smartcard or Arduino or other gadget).  I don't want to re-implement all the code to do with mining and validating transactions in my UI app, bitcoind does this fine.

Because I believe bitcoind shouldn't handle wallets, I also believe the efforts toward wallet encryption are a waste of time.  Same opinion about "multi wallets".  Leave that to the client/UI.


Title: Re: Multiwallet bitcoind
Post by: zwierzak on August 21, 2011, 01:50:25 PM
Idea of no wallet bitcoind is stupid in a few ways:
- how to make it useful for bitcoin exchange or bitcoin bank? Coins should be on server side, not client, because we can't ensure that user that want sell 1000BTC realy have them!
- if it would came true in future there will be viruses that would stole money in this way.

And I was talking about my idea of multiwallet server and how to solve this 2 problems. Because there is no sense to start develop something that isn't possible to finish with full functionality. Discussion about no-wallet, or rather about light client, that don't have blockchain are taken in others topics.