Looks like Electrum is what you are after !
If you have an Android phone there is also an Electrum for Android you can install to use the same wallet with.
Topic: Bitcoin's problems (rant warning) (Read 1606 times)
I'm aware that my attitude towards Java is purely personal. It's based on numerous bad experiences with it in the past which in turn made me ban it from all systems I administrate. Plus, I hate Oracle 
If you really do not want any Java on your machine then you are correct: Electrum is probably your best choice though Armory is maturing nicely.
Bitcoinj is pretty mature now - it has been 'alive' for well over a year and constantly improves. It is the workhorse behind various Bitcoin implementations such as Android Wallet, BitcoinSpinner, SatoshiDice etc.
You are correct that MultiBit is Java based but other than having to install the Java Runtime Environment (JRE) you wouldn't really notice what it is written in. When you install it and run it it looks pretty much like any other application. It is deliberately fairly conventional (as bitcoin is enough of a step for most people).
If you want to try it out but do not want to have a JRE on your machine, you can always put both the JRE and MultiBit onto a USB drive.
I recommend wearing rubber gloves and a facemask whilst handling the USB drive with the JRE and MultiBit on to be sure of zero-Java-contamination. Spray a strong disinfectant (sodium hypochlorite works well) into the USB socket after you remove the USB drive to wash away any residual traces of Java from your machine.
Bitcoinj is pretty mature now - it has been 'alive' for well over a year and constantly improves. It is the workhorse behind various Bitcoin implementations such as Android Wallet, BitcoinSpinner, SatoshiDice etc.
You are correct that MultiBit is Java based but other than having to install the Java Runtime Environment (JRE) you wouldn't really notice what it is written in. When you install it and run it it looks pretty much like any other application. It is deliberately fairly conventional (as bitcoin is enough of a step for most people).
If you want to try it out but do not want to have a JRE on your machine, you can always put both the JRE and MultiBit onto a USB drive.
All of these issues are or can be addressed by alternative clients.
I took a look at the alt clients listed in the wiki, and that's what I came up with (left out those for mobile devices only):Armory: Alpha-level stage. Very resource-intensive and thus will not be usable by everyone.
BitCoinJ: Java. Early development stage. Not safe to use with any serious quantity of money on the production network
Bitdollar: Beta version and may be very unstable
Electrum: Looks promising
Freecoin: Looks dead
MultiBit: Java
Pycoin: Looks dead
QBitcoin: Looks dead
Ufasoft Coin: Closed source
With Java being on the top of my "do not want" list, that only leaves Electrum as an alternative to test.
Technology will keep up with blockchain expansion easily. It was only a few years ago when all programs were measured in kb.
Storage itself might keep up, but don't forget non-tech related problems, like bandwidth caps or slow networks (https://bitcointalksearch.org/topic/m.927811).
lol I have a 60GB SSD in my laptop, I had better upgrade that soon because I think the blockchain is going to eat it up in a year's time!
I'm going to plug my proposal on how to drastically shrink the blockchain:
https://bitcointalksearch.org/topic/proposal-a-second-chain-for-scalability-83645
https://bitcointalksearch.org/topic/proposal-a-second-chain-for-scalability-83645
Technology will keep up with blockchain expansion easily. It was only a few years ago when all programs were measured in kb.
On a side note, I got the client to continue updating again. I restarted the stuck backup and for now it's updating again.
Not sure if it was a coincidence that I shut it down the moment it was maybe done with the block, or if the restart made it skip the block in question.
A few blocks took several minutes (like 181917) but eventually completed. 130 blocks left right now.
Not sure if it was a coincidence that I shut it down the moment it was maybe done with the block, or if the restart made it skip the block in question.
A few blocks took several minutes (like 181917) but eventually completed. 130 blocks left right now.
As others have pointed out the issues you describe are related to a single full node client. Over time less "casual users" will use full nodes and even less the reference Satoshi client. 512MB is a little light for system resources.
All of these are "problems" with the Satoshi client specifically, not Bitcoin itself, except for 1 and 2, which are a necessary evil of running a full node (which is not something that ordinary users are required (or even recommended) to do). The Satoshi client has these issues because it implements everything that is required for the Bitcoin network to operate (including things that ordinary users don't want or need) and does not implement certain things that many people want but are not strictly necessary for Bitcoin to function. All of these issues are or can be addressed by alternative clients.
I don't want to accuse the devs of the alternative clients of anything, but when it comes to money-related things I prefer sticking to the original; probably others think in a similar way. Maybe it would a good idea to release the original client "optimized" (thin client) for the ordinary users and add the options to switch to a "full" node in the options tab.Your exponential growth figures are incompatible with the current operations of the software. The current absolutely maximum rate of growth is about 52Gbytes/yr. This is high and scaling improvements are needed to deal with it but with the download eventually not blocking use of the software its less of an issue. ... But fundamentally running a full bitcoin node will remain to be more burdensome than alternatives. It's also more secure— both for yourself and for all the users of bitcoin.
52GB/yr is still a lot. Is the idea of a distributed blockchain where each node only holds 1-2GB out of question for a reason I'm missing? With such a "storage cluster", space would be less of an issue. Out of curiosity, what happens when the growth would exceed 52GB/yr?This sounds strange, unexpected, and it's inconsistent with what other people are experiencing. What version of the software are you running? On what kind of system? (OS? CPU? Memory? SSD? HD?). Especially the report of high cpu on a single block is surprising— there should not be more than a second to a few of CPU time spent on any block.
I ran into that with the 0.6.2 client released by Luke-Jr (https://bitcointalksearch.org/topic/m.910320) and I verified the checksum. Ran it on a XP-VM with 1.5GHz and 512MB RAM. Blockchain is accessed via a share. Most blocks were processed rather quick; usually just a few seconds per block, sometimes a minute or three. But when I noticed that the VM was eating up CPU constantly, I took a closer look; and block 181868 was being processed until I gave up after ~15 mins.I'm not sure why you're using pywallet. Bitcoin has had integrated key import/export for something like a year now. Can you help me understand what's missing?
My bad then. I was working with an old 0.3.x client until recently and there I needed pywallet. Seems I didn't check if the 0.6.x releases already added that. Sorry for the confusion.
(I'm using the sizes of the snapshots starting Sep/2011, provided by Bitcoincharts for my estimations)
On a rough average, the chain grows by 10% each month, although that may be too low, seeing that in May, it grew by 20%. Even if we just assume 10%, the chain
On a rough average, the chain grows by 10% each month, although that may be too low, seeing that in May, it grew by 20%. Even if we just assume 10%, the chain
Your exponential growth figures are incompatible with the current operations of the software. The current absolutely maximum rate of growth is about 52Gbytes/yr. This is high and scaling improvements are needed to deal with it but with the download eventually not blocking use of the software its less of an issue. ... But fundamentally running a full bitcoin node will remain to be more burdensome than alternatives. It's also more secure— both for yourself and for all the users of bitcoin.
Quote
Some of the large blocks hog CPU, making it a pain to catch up. While waiting for the update to complete, I got stuck at block 181868 (526 tx) for more than 15 minutes with 100% CPU. It got so annoying that I stopped the client after that time. As a result, I'm currently stuck with an outdated chain. It's become easier to just download a nightly snapshot and do a rescan than letting the client update a few days; even though this takes ~5 hours on my connection. Yet with the next big block, the problem arises again.
This sounds strange, unexpected, and it's inconsistent with what other people are experiencing. What version of the software are you running? On what kind of system? (OS? CPU? Memory? SSD? HD?). Especially the report of high cpu on a single block is surprising— there should not be more than a second to a few of CPU time spent on any block.
Quote
While most of the users won't have to deal with internals, it still should be possible to manage wallets easily. I can extract keys via the pywallet tools after setting up Python, but a simple standalone tool should come with the client itself. Having said that, the devs of the various clients should agree on a wallet export/import format (XML?) to make it dead simple to switch between different clients.
I'm not sure why you're using pywallet. Bitcoin has had integrated key import/export for something like a year now. Can you help me understand what's missing?
Moving between some different clients may be easier in the future, I don't know if it will ever be dead simple simply because differences in how wallets are handled are part of the distinctions which make alternative clients worth having.
Quote
4. Merge coincontrol
This is not a problem but a feature request. I've used the 0.6.2 release with coincontrol merged in recently. You quickly get used to this great extra and miss it in the official releases.
This is not a problem but a feature request. I've used the 0.6.2 release with coincontrol merged in recently. You quickly get used to this great extra and miss it in the official releases.
This is now becoming increasingly to happen because no one is stepping up to continue maintaining it.
All of these are "problems" with the Satoshi client specifically, not Bitcoin itself, except for 1 and 2, which are a necessary evil of running a full node (which is not something that ordinary users are required (or even recommended) to do). The Satoshi client has these issues because it implements everything that is required for the Bitcoin network to operate (including things that ordinary users don't want or need) and does not implement certain things that many people want but are not strictly necessary for Bitcoin to function. All of these issues are or can be addressed by alternative clients.
First of all, I like Bitcoin and the whole concept behind it. But there are some problems which need to be addressed if it's meant to succeed. This rant is not only based on my experience, but also on results of introducing Bitcoin to other (non-tech) people.
1. Blockchain size
(I'm using the sizes of the snapshots starting Sep/2011, provided by Bitcoincharts for my estimations)
On a rough average, the chain grows by 10% each month, although that may be too low, seeing that in May, it grew by 20%. Even if we just assume 10%, the chain reaches 2.6GB Sep/2012, and 8.2GB Sep/2013. On Sep/2014, it should be around 23GB. With a 20% monthly growth, the Sep/2014 chain will need 220GB. At this point, nobody will bother anymore. The initial blockchain download will become impossible. This needs to be fixed before users start dropping Bitcoin because of that. If each client would only provide 1GB local storage, that too adds up. Even with only 10,000 users there would be 10,000GB combined storage which is enough to store each block multiple times to provide redundancy (think of it as a p2p-raid).
2. CPU load
Some of the large blocks hog CPU, making it a pain to catch up. While waiting for the update to complete, I got stuck at block 181868 (526 tx) for more than 15 minutes with 100% CPU. It got so annoying that I stopped the client after that time. As a result, I'm currently stuck with an outdated chain. It's become easier to just download a nightly snapshot and do a rescan than letting the client update a few days; even though this takes ~5 hours on my connection. Yet with the next big block, the problem arises again. People should be able to skip verification, maybe in exchange for a malus like less frequent updates (e.g. every 30 mins instead of 10mins). Or only verify max 20 random transactions per block. Or a button to skip verifying the current block. This is not only a problem for users of older PC's, but also for lightweight hardware.
3. Simple management tools
While most of the users won't have to deal with internals, it still should be possible to manage wallets easily. I can extract keys via the pywallet tools after setting up Python, but a simple standalone tool should come with the client itself. Having said that, the devs of the various clients should agree on a wallet export/import format (XML?) to make it dead simple to switch between different clients.
4. Merge coincontrol
This is not a problem but a feature request. I've used the 0.6.2 release with coincontrol merged in recently. You quickly get used to this great extra and miss it in the official releases.
1. Blockchain size
(I'm using the sizes of the snapshots starting Sep/2011, provided by Bitcoincharts for my estimations)
On a rough average, the chain grows by 10% each month, although that may be too low, seeing that in May, it grew by 20%. Even if we just assume 10%, the chain reaches 2.6GB Sep/2012, and 8.2GB Sep/2013. On Sep/2014, it should be around 23GB. With a 20% monthly growth, the Sep/2014 chain will need 220GB. At this point, nobody will bother anymore. The initial blockchain download will become impossible. This needs to be fixed before users start dropping Bitcoin because of that. If each client would only provide 1GB local storage, that too adds up. Even with only 10,000 users there would be 10,000GB combined storage which is enough to store each block multiple times to provide redundancy (think of it as a p2p-raid).
2. CPU load
Some of the large blocks hog CPU, making it a pain to catch up. While waiting for the update to complete, I got stuck at block 181868 (526 tx) for more than 15 minutes with 100% CPU. It got so annoying that I stopped the client after that time. As a result, I'm currently stuck with an outdated chain. It's become easier to just download a nightly snapshot and do a rescan than letting the client update a few days; even though this takes ~5 hours on my connection. Yet with the next big block, the problem arises again. People should be able to skip verification, maybe in exchange for a malus like less frequent updates (e.g. every 30 mins instead of 10mins). Or only verify max 20 random transactions per block. Or a button to skip verifying the current block. This is not only a problem for users of older PC's, but also for lightweight hardware.
3. Simple management tools
While most of the users won't have to deal with internals, it still should be possible to manage wallets easily. I can extract keys via the pywallet tools after setting up Python, but a simple standalone tool should come with the client itself. Having said that, the devs of the various clients should agree on a wallet export/import format (XML?) to make it dead simple to switch between different clients.
4. Merge coincontrol
This is not a problem but a feature request. I've used the 0.6.2 release with coincontrol merged in recently. You quickly get used to this great extra and miss it in the official releases.
Jump to: