Oooh.. I do like the idea of a bitcoin daemon presenting itself through a KDE Plasma widget... 

Either way, I have been thinking about the whole mining aspect of Bitcoin these last weeks, since the difficulty has gone through the roof. It would be nice to have the whole generating part be (more) independent of processing power, and more balanced towards the amount of time one puts in. However, I think most alternatives will, sooner or later, fall victim to people using their non-bitcoin wallets in order to change a new more balanced way of generating bitcoins in their favor.

If generating would be dependent on time spent, people would simply spawn multiple processes, virtual machines, etc. If generation would be dependent on bandwidth spent (as a Tor middleman node perhaps?  ), people would invest in broadband connections, servers in datacenters, etc. If generation would be shifted from something GPU-optimized towards something only CPU's are good at computing, people would invest in CPU's.

As I am running out of ideas, I would like to add that I too am in favor of having Bitcoin default to 10/15% of a CPU core generating for the sake of network stability and security. In fact, it would be nice if Bitcoin allowed me to select percentage in addition to number of cores. I have no clue however if that is easily added or something incredibly complicated to code.

I am aware that this feature request may be rather low priority, but I wanted to put it out here anyway. My suggestion is to switch from the current self-signed SSL certificate to one from CAcert. This way we have the benefit of working with a more widely accepted certificate (yesyes, still not in most main browsers, however still better than self-signed) and working with a more open approach to SSL certificates.

Especially when browsing bitcoin.org using Tor, I prefer to use SSL in order to prevent exit nodes from eavesdropping.

Thanks for the replies, getting it into the main tree is indeed a lot more important. Good luck!

Any chance of a CUDA use flag, maybe restricted to a certain revision?

Hmm.. I am unable to download the full source...


...anyone who was able to download and build this release?

True, using a system outside of Bitcoin itself, opens you up for loads of theoretical and presumably also a couple of real life attacks. Using PGP however does allow establishing trust in a certain way: a bitcoin address signed by a PGP key held by a friend, or a friend of a friend, should indicate that there's a kind of trustworthiness associated with that bitcoin address. After all, the one who holds the PGP private key has announced the authenticity or ownership of that particular bitcoin address.

Now, it could be that the private PGP key is compromised. In that case the original owner should have revoked the PGP key, thereby revoking the associated trust. Also, if an attacker gains access to your private PGP key, there would usually be very little between him and your bitcoin wallet as well, so a compromised PGP key would most likely mean your bitcoin wallet is compromised as well.

Wouldn't it be easiest to simply use PGP for this? If someone posts or emails his Bitcoin address and signs the message with his private PGP key, you can determine whether you trust the identity and trustworthiness associated with said PGP key (and web of trust) and therefore whether you trust the bitcoin address itself.