Bitcoin Forum

The difficulty is now so high that it might take a couple weeks for a beefy multi-core CPU to generate a single block.

Therefore, I conclude that the existing CPU-based code in bitcoin is largely pointless, as GPU miners continue to win blocks.  And GPU miners obviously require running a fork of bitcoin, rather than 100% upstream bitcoin.  Therefore, it can be said that the overwhelming majority of today's generated blocks are generated by forked source code and not upstream bitcoin.

Here's a radical proposal:

• Move the current CPU miner code to a separate program, bitcoin-minerd.
• Listen on TCP port 8334 for incoming connections (w/ applicable IP address whitelist).  When work arrives via P2P network, broadcast new work to all connected miners.  Miners submit potential solutions via this same TCP connection.

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).

Moving CPU mining out of bitcoin, to a separate process, ends the current practice of teasing users with a "Generate coins?" option that will waste electricity for months on end, without generating any blocks, given the current difficulty level.  That is not a friendly experience for first-time bitcoin.exe users.

It's hard to get a new idea to take hold. The "generate coins" option is the hook that gets many people to download, install and run bitcoin.

I'd love to see distributed mining in the standard client. That way, newcomers could earn something every day (even if it would only be a fraction of a coin).

That's intentionally selling users a false premise, though, right?

It's a false premise, but it wasn't intentional because until a couple of months ago the average Joe could generate blocks on ordinary hardware.

That's why I'd like to see distributed mining on the standard client, to make that false promise become true again.

Agree with you.
It is the worst thing to disappoint consumers through to high expectations.

The problem is not technical - it is administrative. Decision must be too administratively.
Separation would lead to complication of the maintenance fragments into a compatible state. Also, bitcoin generation is not such bad option. (It can also be simple build option for building without generation.)

Need to come up with another way to keep the source.

For example, as in a repository of Linux kernel - allow commits to the repository for a lot of people. Among these people are authors of the various versions of the client. Satoshi will be able to decide what to commit and which are not into master branch.

Also, this will lead to a lot of people will see the same code that is beneficial for its security.

(Apparently, again, will return to the issue of translation in the git repository)

I guess a "distributed mining" option in the original client shut do the trick.
Just make a litle pop-up explaining what this is and why somebody would use it.
Then the average user can decide which way he want to generate coins.

+ 1, however this may be difficult to implement.

Also, i don't like the idea of removing mining from Bitcoin completely. Perhaps it should use 10-25% of PC's computational power by default to make network stronger and more resistant to attacks. If user wants, he can shut down the block generation.

Users do shut down bitcoin generation...  after getting excited about mining, turning on generation, and then finding out they did nothing but generate a lot heat due to difficulty level.

Mining is a small part, a beneficial side effect, of the overall bitcoin economy, with a very small, usually technically-skilled users excelling at mining and everyone else getting almost nothing.  The most important thing is for users to be able to send and receive bitcoins in a decentralized manner. 

I only want that for the sake of greater network security against double spending attacks done by network takeovers.
I do not want generation for the generation itself.

I agree that the Bitcoin coin generation should be a separate process that has a clean interface to the network.

I further think that the block chain maintainance code should be a separate process from the wallet management and transaction creating process. Let's suppose that there's a buffer overflow or similar flaw in the network handling code of the current client. If an attacker sends a suitably malformed transaction onto the network then they can execute arbitrary code on all connected machines running the client. This code could empty all the attacked clients' wallets or more subtly, send the attacker all the private keys in the wallet. If the block chain maintainance code were a separate process to the wallet code then this attack would be prevented.

I have mentioned this before in http://bitcointalk.org/index.php?topic=665.msg18578#msg18578

Also, for those interested in some sort of collaborative or distributed mining there's this thread
http://bitcointalk.org/index.php?topic=1458.msg17020#msg17020

If implemented appropriately as discussed in the thread I believe it can be implemented completely securely and transparently.

ByteCoin

Yes, there seems to be agreement that eventually users will have a "lightweight" bitcoin client to use, which can send/receive transactions, manage a wallet, and nothing more.  This is analogous to the distinction between leaf nodes and ultrapeer nodes, on the Gnutella network.

I was arguing more along the lines of removing wallet handling code from the current client and putting it in a separate process.
Suppose the bitcoin client has a buffer overflow or other similar vulnurability in the code that handles incoming network transactions or blocks. A suitably malformed transaction could result in arbitrary code execution and the malicious code could quickly steal all your bitcoins (or worse).

It's hard to secure a process that accepts multiple network connections from arbitrary peers and performs complex validation processing on the arbitrary data they send.

ByteCoin

I like the sound of that. Sounds like the chrome browser where if one tab crashes it doesnt bring down the whole browser.

indeed, i think this is an important point. once we have millions of nodes, if we have default-generation to 'on' and using even 5-10% cpu (configurable), that'll provide significant computing power and raise the bar to taking over the network.

even if generation isn't profitable, it's not unreasonable to expect that people may do it - see how many millions of people run things like folding@home, completely at no personal gain. bitcoin generation may easily be done the same way - with little hope of personal gain, but to help secure the network against attack.

something to think about, i think. it's not only about 'making free btc'.

How about you change the hash algorithm to something that doesn't run so well on GPU's?  I saw a mention that the one BitCoin is using is designed for speed in this type of implementation.  How about using something clunky that CPU's are better at than GPU's?

Process separation and a clean interface which alternative miner implementations can use both sound like excellent ideas to me.

I don't think there's much of a problem with disappointed users who thought they could get rich generating bitcoins. The bitcoin.org front page does a good job of emphasizing the real advantages of bitcoin rather than offering false promises of easy money. However it wouldn't hurt if it said that it might take weeks rather than days to generate coins, since that's closer to reality for most users right now.

As for providing an incentive for a lot of users to run the miner to prevent the network from being hijacked, to me it seems that some kind of 'pooled mining' scheme (like the one which ByteCoin provided a link to) would work very well, assuming it's feasible from a technical standpoint. I'm in no position to judge that.

I think distributed mining should be coded. I joined almost a month ago hoping to maybe make a few bitcoins for free and then us them to entice others to join. But now with the difficulty at 3000 It will take me 1y to make 50 coins. Why not let me generate coins at a smaller pace such as 1 coin a week and then i could spread that coin to others for them to join.

it will run with the same permissions as bitcoin/bitcoind. Therefore, there is no reason to make a separate binary. daemon can fork and continue to communicate with generating code through a socket

+ 1.

Somebody make a poll perhaps ?

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.

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.

+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.

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.

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" ?

YES

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.

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.

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

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.

+100500

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.

Why not have the generation calculator (http://www.alloscomp.com/bitcoin/calculator.php) 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)

+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...

Agreed.


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.

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...

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.

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.

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.

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.