RFC: Remove mining from bitcoin?

[jgarzik]

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.

[ribuck]

... teasing users with a "Generate coins?" option ...

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

[jgarzik]

... teasing users with a "Generate coins?" option ...

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.

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

[ribuck]

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.

[S3052]

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

[bitcoinex]

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.

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)

[SmokeTooMuch]

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.

[ShadowOfHarbringer]

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.

[jgarzik]

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. 

[ShadowOfHarbringer]

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.

[ByteCoin]

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

[jgarzik]

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.

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.

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

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

[Anonymous]

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.

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.

[nanotube]

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.

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

[FlyingMoose]

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?

[zipslack]

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.

[bober182]

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.

[bitcoinex]

Here's a radical proposal:

• Move the current CPU miner code to a separate program, bitcoin-minerd.

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

[ShadowOfHarbringer]

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.

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.

+ 1.

Somebody make a poll perhaps ?