|
Steve (OP)
|
 |
September 30, 2011, 01:21:59 PM |
|
One thing that would make the bitcoin client far more useful for me is if the wallet and the client were split. I don't keep bitcoin running continuously and hence when I restart it, I have to wait a while the client catches up with the latest blocks. I also have multiple wallets and keeping a separate block chain for each of them is wasteful. I want to keep a bitcoin p2p client running somewhere continuously and have my wallets connect through it to the bitcoin network. I imagine two executables:
- bitcoinWallet
- bitcoinClient
The bitcoinWallet would be the familiar GUI front end to a wallet. It would work just as it works today (although, I'd like a "File" menu that lets you choose which wallet.dat to open and use).
The bitcoinClient would be a headless process that could easily be turned into a service or daemon. It connects to the p2p network, validates blocks and transactions, and keeps its own local copy of the block chain.
By default, the bitcoinWallet would attempt to connect to a locally running bitcoinClient on a well known port. A command line option would let you specify an alternate host:port where the client can be found. A setting in the GUI could also let you specific a client to connect to (and the setting could be remembered in some config file).
I realize that there are ways some of these issues can be addressed with the current distribution, but I think a more user friendly solution is needed. Mainly what it comes down to is the ability to fire up the wallet that may have not been running for a day or two and have it be instantly usable (without having to wait for it to catch up). Having it startup instantly (rather than take several minutes for the GUI to appear) would be good too. Also, if there is still a need for the wallet to sync with the block chain (getting the very most recent transactions that are relevant to the wallet) and it takes more than a couple seconds, some visual indication that the client is syncing and not ready for use would be good.
|
|
|
|
|
|
|
|
|
|
|
|
|
According to NIST and ECRYPT II, the cryptographic algorithms used in
Bitcoin are expected to be strong until at least 2030. (After that, it
will not be too difficult to transition to different algorithms.)
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
 Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
September 30, 2011, 01:23:42 PM |
|
+1
Bitcoin already comes as a headless daemon (just compile bitcoind).
With a few RPC commands added to support the queries a wallet app would need, it would almost be all the way. I'm working to get those commands added, partly by offering bounties for baby steps to get us there.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
|
Steve (OP)
|
|
September 30, 2011, 02:36:00 PM |
|
Yes, I think the simplest think that could possibly make this work is the best way to go. There has been a lot of talk about factoring the code to enable things like this, but doing the simplest thing instead of a grand refactoring makes a lot of sense (and I think it would go a long way toward encouraging alternate implementations of a wallet UI as it removes the need for the wallet implementation to speak the bitcoin protocol directly or manage a local block chain).
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1024
|
|
September 30, 2011, 02:45:06 PM |
|
Things seem to be drifting very slowly in this direction. The problem is that nodes and wallets are much more tightly coupled than you'd expect. But we'll get there eventually.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2216
Chief Scientist
|
|
September 30, 2011, 03:00:21 PM |
|
Honestly, I don't think the future of bitcoin is running "heavy" nodes on our personal computers.
I think the vast majority of people will be using bitcoin through web or mobile apps in the not-too-distant future. So I'm not personally inclined to put a lot of effort into splitting the node and wallet, unless that makes creating lightweight web and mobile apps easier.
That said, the new QT gui does a much, much better job of letting you know what bitcoin is doing, both during initial startup and initial blockchain download.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
|
Steve (OP)
|
|
September 30, 2011, 03:01:42 PM |
|
Things seem to be drifting very slowly in this direction. The problem is that nodes and wallets are much more tightly coupled than you'd expect. But we'll get there eventually.
This doesn't surprise me at all (having done a complete refactoring of the code back in Feb). So, I think if I were working on this, I'd start with the goal of running a bitcoin instance without a local block chain available and make it communicate with another instance of bitcoin whenever portions of the block chain were needed. The wallet.dat file would be the only thing persisted, everything else would be pulled from the other bitcoin instance as necessary (local caching of transactions could be added later if this proves to be too chatty to be very useful for some remote connectivity situations). Once this works, you've resolved at least one significant usability issue with bitcoin. |
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1024
|
|
September 30, 2011, 03:28:20 PM |
|
So, I think if I were working on this, I'd start with the goal of running a bitcoin instance without a local block chain available and make it communicate with another instance of bitcoin whenever portions of the block chain were needed.
See the todo link in my sig. |
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
|
Steve (OP)
|
|
September 30, 2011, 03:46:27 PM |
|
Honestly, I don't think the future of bitcoin is running "heavy" nodes on our personal computers.
I think the vast majority of people will be using bitcoin through web or mobile apps in the not-too-distant future. So I'm not personally inclined to put a lot of effort into splitting the node and wallet, unless that makes creating lightweight web and mobile apps easier.
That said, the new QT gui does a much, much better job of letting you know what bitcoin is doing, both during initial startup and initial blockchain download.
I do think it would make creating lightweight web and mobile apps much easier. Wallet apps, whether desktop or mobile, wouldn't need to deal with connecting directly to the p2p network or with managing the block chain. They could use the proven c++ codebase for that. There are problems with using the current wallet for the implementation of web based, hosted wallets (chief among them is the inability to handle key creation and transaction signing outside of the bitcoin process). By separating the wallet and client, you could decouple their evolution with some people focusing on making a really good p2p client and others working on the wallet code. The wallet side could itself evolve into a daemon that supported both desktop and web based UIs. And other projects building wallets could benefit from being able to use the proven c++ client for the interface to the block chain and p2p network. I also foresee the need to have substantially different types of wallet implementations (imagine a company needing to manage its funds...the wallet UI for those users may need to be completely different...allowing for a workflow where multiple signatures are required to spend funds and such). |
|
|
|
|
