RFC: Remove mining from bitcoin?

[m0mchil]

This "remote mining" scheme with active TCP connections is superior to the polled 'getwork' method in use by some GPU miners.  Incorporating remote mining into upstream will also provide a very strong incentive for GPU miner authors to use upstream bitcoin without modification (a win for open source, IMO).

I definitely agree. Push-based work distribution is the way to go. I just wanted to make as few changes as possible using existing RPC server. My hope was that BTC developers will evaluate the idea and make something better to get in the mainline. Perhaps we should just implement this 8334 push patch and propose it for inclusion?

Also, it's OK to have CPU generation in mainline. Just let the user decide how much resources he is willing to give. Something like how many lottery tickets he is willing to buy.

[da2ce7]

I think that the simplest (short term) solution is to have a button or a dialogue that shows the how long it will take (on average) to generate a coin on via the client… this is just a 30min code job.  This will at least stop the disillusionment of newcomers.

Separating the processes into low security net code and high security wallet code in, my opinion is a very high priority.  This is a potentially very dangerous security flaw.

In the longer term, using Trusted Platform Module (TPM) for key storage would be a good idea, particularly for laptops and other mobile devices.

[Cdecker]

+1

The request is certainly reasonable and we would get a leaner, cleaner, main stream client, with less dependencies and easier to distribute, also the modularization proposed by some people (Wallet manager separate) would be desirable for people trying to implement their own network, wallet or mining clients as long as the communication interfaces are well documented.

[Anonymous]

A calculator at bitcoin.org where people can enter the type of hardware they have would let them see what the expected amount of time it might take to generate a block ?

[da2ce7]

A calculator at bitcoin.org where people can enter the type of hardware they have would let them see what the expected amount of time it might take to generate a block ?

and a link to that from the software, so that people whom miss it can find it easy.

[mimarob]

But do you still (on average) get bitcoins proportional to the amount of CPU that you chip in?

Or do the fastest node always "win" ?

[ribuck]

But do you still (on average) get bitcoins proportional to the amount of CPU that you chip in?

YES

Or do the fastest node always "win" ?

NO

If you ignore small effects (e.g. due to network latency), a CPU that is 10 times as powerful will in the long term "win" 10 times as many blocks.

[zipslack]

A calculator at bitcoin.org where people can enter the type of hardware they have would let them see what the expected amount of time it might take to generate a block ?

It would be easier to build this straight into the bitcoin software. For a calculator on bitcoin.org to work people somehow have to describe their hardware and the website needs to guess how many hashes/sec they will be able to generate with that hardware. On the other hand the client already has that number and the current difficulty, so it could easily do some simple math (a la http://www.alloscomp.com/bitcoin/calculator.php) and display the time estimates.

[Ewald]

I like the idea of separating the daemon core from the GUI. That way others can build their own interfaces for using bitcoin like a KDE version for my desktop or a web interface.

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.

[RHorning]

I like the idea of separating the daemon core from the GUI. That way others can build their own interfaces for using bitcoin like a KDE version for my desktop or a web interface.

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.

This is an interesting concept by itself, noting how multiple "contribution" metrics could be used in various ways to "earn" bitcoins.  It also hints at perhaps a successor currency to Bitcoins as currently implemented if the time and need arose.

In fact, this is such a good idea, it would be nice to see it spawn into its own thread for a completely separate discussion as I think there are a whole bunch of ideas that can come from this particular topic.

Moving on....

One thing you could add to the code is perhaps doing something with the thread priorities.  Supposedly, Bitcoins is currently at the lowest possible thread priority.  For Linux, this seems likely to be true but I have my doubts about the Windows clients, as the Windows thread priority system is really whacked out hack of the DEC VMS thread priority system (Windows NT is derived from VMS) that also put some really weird things in trying to get it to move over to the x86 architechture.  Essentially, setting a thread priority doesn't seem to really get you the thread priority that you always want.  Perhaps you could bump up the priority from minimum to low or medium for the hash generation?  It is a "settable" parameter that at least in theory could be added to the UI.

I've also run into a problem where my CPU is overheating due to the hash algorithm constantly running, where I turn off the coin generation and my CPU temperature gets back down to normal.  The algorithm is chewing up a lot of juice due to the fact that it is using the math portions of the CPU.  I consider this to be a hardware fault rather than a software problem, but it has also an impact upon computer operations and is a fact of life for modern computers.  Laptops in particular are affected here, where running something like Bitcoins is chewing up battery life as well.  Perhaps a process that would do some hashing but then go into a wait mode every once in awhile could be beneficial?  It would be the equivalent of periodically turning on and off the coin generation option manually, say once a second or so or for some settable parameter?  This would also allow other low-priority tasks to get completed and not be fighting for CPU resources (again, something that is a problem with Bitcoins).  It is this where I see a "percentage of CPU usage" being a settable parameter.

Just blowing a brain fart here on this, but it at least is something to consider.

[throughput]

I think that the simplest (short term) solution is to have a button or a dialogue that shows the how long it will take (on average) to generate a coin on via the client… this is just a 30min code job.  This will at least stop the disillusionment of newcomers.

+100500

Separating the processes into low security net code and high security wallet code in, my opinion is a very high priority.  This is a potentially very dangerous security flaw.

In the longer term, using Trusted Platform Module (TPM) for key storage would be a good idea, particularly for laptops and other mobile devices.

That is a great idea, but it would be nice to also split the blockchain database off the network-facing part,
since network produces untrusted data, but blockchain database should only contain valid and verified blocks,
it should be an intermediary between the rogue users' wallets and the otherwise violent Internet data.

[mgiuca]

Why not have the generation calculator display in the status bar next to the number of khashes while generating. That way, it's not visible in the UI at all for people who aren't generating.

For anyone who gets excited and clicks the "generate coins" button, they will immediately see "1700 khash/sec, average time to generate 50 bc: 2 years 30 days." Instantly explaining to them why this isn't necessarily going to make them rich. Alternatively, "1700 khash/sec, average income per day: 0.06 bc." (at which point you could make the same amount of money by simply using the faucet every day).

(apologies for surfacing this old thread)

[M4v3R]

+1. Now when Bitcoin got all this publicity, many people would run the client hoping to get some free cash. And there goes Gigawatts of energy wasted...

[jgarzik]

For anyone who gets excited and clicks the "generate coins" button, they will immediately see "1700 khash/sec, average time to generate 50 bc: 2 years 30 days."

Agreed.

Instantly explaining to them why this isn't necessarily going to make them rich. Alternatively, "1700 khash/sec, average income per day: 0.06 bc." (at which point you could make the same amount of money by simply using the faucet every day).

The bitcoin client does not support mining pools, so it's either winning a block (50 BTC) or nothing.

[casascius]

For anyone who gets excited and clicks the "generate coins" button, they will immediately see "1700 khash/sec, average time to generate 50 bc: 2 years 30 days."

Agreed.

Instantly explaining to them why this isn't necessarily going to make them rich. Alternatively, "1700 khash/sec, average income per day: 0.06 bc." (at which point you could make the same amount of money by simply using the faucet every day).

The bitcoin client does not support mining pools, so it's either winning a block (50 BTC) or nothing.

The new user experience would be enhanced substantially if the client merely told them, "You may be able to increase this rate substantially by installing a program that enhances generation with your NVidia or ATI video card.  Click here for more info." (and linked to the wiki).

If miners could report to the main Bitcoin program how many hashes they are doing, then the program could natively display the sum of them, as well as calculating average block time.  That would be more encouraging for new users, especially ones just trying GPU mining for the first time and doubting their progress after days of nothing.

[gigitrix]

This is all good stuff. The security point is my biggest concern here. Although it has to be stated that from what I understand the "official" client is intended to be a "reference implementation", so it's probably wise that it shows off all of what the bitcoin spec has to offer.

And I like the idea of adding 10% to the network, even if it's just to marginally strengthen it and decentralise it...

[theGECK]

I'd like to throw my support behind this idea. Of the few people who actually tried out Bitcoin after I told them about it, their number one question was about the "generate bitcoin" option in the client, and why they don't have any money yet, even after running it for a few days. Taking out that option would simplify things a great deal. I'm all for keeping mining to the people who want to take the time to learn about the currency and be active in reading the forums. And as the reward/block drops off, keeping mining in the forefront would be a bad move.

Also, adding a 5-10% CPU load would be a good idea IMHO. If Bitcoin takes off, 5% would be all we really need to keep everything secure and running properly.

[casascius]

What would be nice, is if the generate coins option remained, but it was turned into an enabler for the RPC getwork interface, so people didn't have to bug around with text files and command line scripts to start generating coins.  I would also support leaving the CPU miner in, just for reference's sake, but along with obvious messages that say, "OK, bitcoin is much more popular now, CPU mining is not recommended, GPU mining is the only way to go".  There is a certain educational value in simply seeing "2400 khash/sec" being generated, even if it will produce no BTC, as it helps newcomers develop a reference for the value of a khash and how it correlates to production.

[Cdecker]

I strongly support removing the option from the menu, let's make it harder to find

I may actually be cutting myself here as I am a strong supporter of having large decentralized computation power, unlike the professional multi-GPU setups and pools, but overall having the option in there just turns off alot of people. The getwork interface still enables people interested in supporting the network with their computation power to just start the cpuminer or one of the GPU flavours, but at that point they'll probably have informed themselfs about how long it will take and what probabilities underly the mining process.

[BitterTea]

I may actually be cutting myself here as I am a strong supporter of having large decentralized computation power, unlike the professional multi-GPU setups and pools

I think it's just division of labor at work. The good thing is that you can contribute if you want to. There are no barriers to entry, it's just that the monetary reward diminishes.