Proposal: remove "getwork" RPC from bitcoind
22 messages, 19 to 22 Aug 2013. Started by Jeff Garzik.
Jeff Garzik (3), Frank Flores (3), Greg Maxwell (3), Warren Togami (2), Luke Dashjr, Pieter Wuille, Matt Corallo, Goss, Brian C., M.D., +7 more
Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
On mainnet, almost everybody uses a pool (and therefore, not "getwork" directly to bitcoind). Those few who solo mine use a pool server to talk to bitcoind via "getblocktemplate" or other means. Tests show that attempts to solo mine on mainnet via "getwork" lead to delays and problems.
On testnet, getwork has a better chance of continuing to work. Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork.
However, at one time, getwork to bitcoind was widely used. I wanted to poke the audience, to gauge response to removing "getwork." If a driving use case remains of which we're unaware, speak up, please. We don't want to break anybody needlessly.
I strongly object to removing the only mechanism that allows anyone to say that bitcoin is p2p, in the truest sense of the word. Moves like this that favor only the pool operators and private mining interests are signs that bitcoin is headed towards a monopoly/cartel model, and that would be a tragic outcome for something that holds a great promise. Nobody knows what mining will look like in the future, and denying the individual novice the ability to mine at a small scale, even if we may think it is inefficient now, is not a good path to start down.
If there are technical problems with getwork, maybe they should be addressed and fixed instead of outright abandoned.
On Mon, Aug 19, 2013 at 11:27 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (36 lines)
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to > remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork > > On mainnet, almost everybody uses a pool (and therefore, not "getwork" > directly to bitcoind). Those few who solo mine use a pool server to > talk to bitcoind via "getblocktemplate" or other means. Tests show > that attempts to solo mine on mainnet via "getwork" lead to delays and > problems. > > On testnet, getwork has a better chance of continuing to work. > Nevertheless, the same tools (open source pool servers or p2pool) are > available for testnet, obviating the continued need to support > getwork. > > However, at one time, getwork to bitcoind was widely used. I wanted > to poke the audience, to gauge response to removing "getwork." If a > driving use case remains of which we're unaware, speak up, please. We > don't want to break anybody needlessly. > > -- > Jeff Garzik > Senior Software Engineer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Monday, August 19, 2013 8:09:41 PM Frank F wrote:
Quoted text (11 lines)
> I strongly object to removing the only mechanism that allows anyone to say > that bitcoin is p2p, in the truest sense of the word. Moves like this that > favor only the pool operators and private mining interests are signs that > bitcoin is headed towards a monopoly/cartel model, and that would be a > tragic outcome for something that holds a great promise. Nobody knows what > mining will look like in the future, and denying the individual novice the > ability to mine at a small scale, even if we may think it is inefficient > now, is not a good path to start down. > > If there are technical problems with getwork, maybe they should be > addressed and fixed instead of outright abandoned.
You missed getblocktemplate. It does everything getwork did and more.
Individual solo miners aren't being locked out at all. This is just removal of a protocol that has been obsolete for well over a year now.
Luke
On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> wrote:
Quoted text (11 lines)
> I strongly object to removing the only mechanism that allows anyone to say > that bitcoin is p2p, in the truest sense of the word. Moves like this that > favor only the pool operators and private mining interests are signs that > bitcoin is headed towards a monopoly/cartel model, and that would be a > tragic outcome for something that holds a great promise. Nobody knows what > mining will look like in the future, and denying the individual novice the > ability to mine at a small scale, even if we may think it is inefficient > now, is not a good path to start down. > > If there are technical problems with getwork, maybe they should be addressed > and fixed instead of outright abandoned.
They were addressed and fixed in a successor API, getblocktemplate. It's even more decentralization-friendly, as it allows the caller to see what transactions the daemon is trying to put into a block, and even modify it.
The suggestion here is not to remove functionality - only to remove an obsolete API for doing so.
ACK, I see no reason to leave broken things in that a) arent necessary and b) no one has the developer resources to fix.
Matt
On Mon, 2013-08-19 at 12:27 -0400, Jeff Garzik wrote:
Quoted text (19 lines)
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to > remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork > > On mainnet, almost everybody uses a pool (and therefore, not "getwork" > directly to bitcoind). Those few who solo mine use a pool server to > talk to bitcoind via "getblocktemplate" or other means. Tests show > that attempts to solo mine on mainnet via "getwork" lead to delays and > problems. > > On testnet, getwork has a better chance of continuing to work. > Nevertheless, the same tools (open source pool servers or p2pool) are > available for testnet, obviating the continued need to support > getwork. > > However, at one time, getwork to bitcoind was widely used. I wanted > to poke the audience, to gauge response to removing "getwork." If a > driving use case remains of which we're unaware, speak up, please. We > don't want to break anybody needlessly. >
Thank you for setting me straight. Please forgive my ignorance.
On Mon, Aug 19, 2013 at 3:14 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
Quoted text (29 lines)
> On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> wrote: > > I strongly object to removing the only mechanism that allows anyone to > say > > that bitcoin is p2p, in the truest sense of the word. Moves like this > that > > favor only the pool operators and private mining interests are signs that > > bitcoin is headed towards a monopoly/cartel model, and that would be a > > tragic outcome for something that holds a great promise. Nobody knows > what > > mining will look like in the future, and denying the individual novice > the > > ability to mine at a small scale, even if we may think it is inefficient > > now, is not a good path to start down. > > > > If there are technical problems with getwork, maybe they should be > addressed > > and fixed instead of outright abandoned. > > They were addressed and fixed in a successor API, getblocktemplate. > It's even more decentralization-friendly, as it allows the caller to > see what transactions the daemon is trying to put into a block, and > even modify it. > > The suggestion here is not to remove functionality - only to remove an > obsolete API for doing so. > > -- > Pieter >
On Mon, Aug 19, 2013 at 1:09 PM, Frank F <frankf44@gmail•com> wrote:
Quoted text (2 lines)
> If there are technical problems with getwork, maybe they should be addressed > and fixed instead of outright abandoned.
They have been, resulting in a replacement called "getblocktemplate" which (presumably) almost everyone talking to bitcoin(d|-qt) has been using for a long time.
I think removing the ability to mine in the stock package would be regrettable, but to be honest we already don't have it for the mainnet. I think we should do as Jeff suggests and remove getwork. But I think we should also package along a proper getblocktemplate miner to remove any doubt that we're providing a full network node here. (I note that the choice of miner is also easy: Regardless of people's preferences which way or another, AFAIK only luke's bfgminer stuff can mine directly against bitcoin getblocktemplate with no pool in the middle. It also supports a huge variety of hardware, and a superset of our target platforms)
This sounds like an ideal compromise.
On Mon, Aug 19, 2013 at 3:16 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (20 lines)
> On Mon, Aug 19, 2013 at 1:09 PM, Frank F <frankf44@gmail•com> wrote: > > If there are technical problems with getwork, maybe they should be > addressed > > and fixed instead of outright abandoned. > > They have been, resulting in a replacement called "getblocktemplate" > which (presumably) almost everyone talking to bitcoin(d|-qt) has been > using for a long time. > > I think removing the ability to mine in the stock package would be > regrettable, but to be honest we already don't have it for the > mainnet. I think we should do as Jeff suggests and remove getwork. But > I think we should also package along a proper getblocktemplate miner > to remove any doubt that we're providing a full network node here. (I > note that the choice of miner is also easy: Regardless of people's > preferences which way or another, AFAIK only luke's bfgminer stuff can > mine directly against bitcoin getblocktemplate with no pool in the > middle. It also supports a huge variety of hardware, and a superset > of our target platforms) >
What if we have a massive (like many orders of magnitude) drop in network harsh rate? Might such a function be useful to salvage the (non-functioning) network? Same for IRC bootstrapping. How do we pick ourselves up off the ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).
-----Original Message----- From: bitcoin-development-bounces@lists•sourceforge•net [mailto:bitcoin-development-bounces@lists.sourceforge.net] On Behalf Of bitcoin-development-request@lists•sourceforge•net Sent: Monday, August 19, 2013 3:16 PM To: bitcoin-development@lists•sourceforge•net Subject: Bitcoin-development Digest, Vol 27, Issue 28
Send Bitcoin-development mailing list submissions to bitcoin-development@lists•sourceforge•net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-request@lists•sourceforge•net
You can reach the person managing the list at bitcoin-development-owner@lists•sourceforge•net
When replying, please edit your Subject line so it is more specific than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
1. Proposal: remove "getwork" RPC from bitcoind (Jeff Garzik) 2. Re: Proposal: remove "getwork" RPC from bitcoind (Frank F) 3. Re: Proposal: remove "getwork" RPC from bitcoind (Luke-Jr) 4. Re: Proposal: remove "getwork" RPC from bitcoind (Pieter Wuille) 5. Re: Proposal: remove "getwork" RPC from bitcoind (Matt Corallo) 6. Re: Proposal: remove "getwork" RPC from bitcoind (Frank F)
----------------------------------------------------------------------
Message: 1 Date: Mon, 19 Aug 2013 12:27:01 -0400 From: Jeff Garzik <jgarzik@bitpay•com> Subject: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind To: Bitcoin Dev <bitcoin-development@lists•sourceforge•net> Message-ID: <CAJHLa0MnnWw=qiYC0nJcY=BdTDcAjGtraJ+kazoG7_bHW-HBtw@mail•gmail•com> Content-Type: text/plain; charset=ISO-8859-1
Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
On mainnet, almost everybody uses a pool (and therefore, not "getwork" directly to bitcoind). Those few who solo mine use a pool server to talk to bitcoind via "getblocktemplate" or other means. Tests show that attempts to solo mine on mainnet via "getwork" lead to delays and problems.
On testnet, getwork has a better chance of continuing to work. Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork.
However, at one time, getwork to bitcoind was widely used. I wanted to poke the audience, to gauge response to removing "getwork." If a driving use case remains of which we're unaware, speak up, please. We don't want to break anybody needlessly.
On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (2 lines)
> I think removing the ability to mine in the stock package would be > regrettable,
I am naughty and should clarify. I had ass.u.me.d that Jeff's patch also removed the internal CPU miner, because doing so is necessary for actually getting rid of most of the getwork code. It doesn't actually.
Though this doesn't change the fact that the internal miner is mostly a pretext for integrated mining. Since it only really works on testnet it also means our testnet testing using it is not a good test of the actual production software. I'd rather remove the internal miner too, getting rid of the extra code and complexity, and package up a GBT miner which would actually be usable on the mainnet.
FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork.
Warren
On Mon, Aug 19, 2013 at 10:23 AM, Gregory Maxwell <gmaxwell@gmail•com>wrote:
Quoted text (28 lines)
> On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell <gmaxwell@gmail•com> > wrote: > > I think removing the ability to mine in the stock package would be > > regrettable, > > I am naughty and should clarify. I had ass.u.me.d that Jeff's patch > also removed the internal CPU miner, because doing so is necessary for > actually getting rid of most of the getwork code. It doesn't actually. > > Though this doesn't change the fact that the internal miner is mostly > a pretext for integrated mining. Since it only really works on > testnet it also means our testnet testing using it is not a good test > of the actual production software. I'd rather remove the internal > miner too, getting rid of the extra code and complexity, and package > up a GBT miner which would actually be usable on the mainnet. > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Mon, Aug 19, 2013 at 4:33 PM, Warren Togami Jr. <wtogami@gmail•com> wrote:
Quoted text (5 lines)
> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned > people that getwork will be removed in the next major version. Pooler's CPU > minerd which supports both sha256d and scrypt recently grew stratum support. > Perhaps he could be convinced to add GBT support too, which would help this > goal of completely removing the internal miner and getwork.
The internal miner is still actively used for testnet, here.
On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D. <Goss.Brian@mayo•edu> wrote:
Quoted text (1 line)
> What if we have a massive (like many orders of magnitude) drop in network harsh rate? Might such a function be useful to salvage the (non-functioning) network? Same for IRC bootstrapping. How do we pick ourselves up off the ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).
[Aside: When replying to the digest, please try to trim it]
It appears that we will soon be at a hashrate where all the desktop CPUs in the world couldn't really make a dent in it... certainly not desktop cpus using the slow integrated cpu miner, which is much slower than external optimized cpu miners.
But this is why I suggest packaging up a modern mining tool that supports CPU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so would reduce the difference between testnet and mainnet, and provide an actually useful tool for contributing directly.
Though again, I note, that Jeff's patch doesn't actually remove the integrated miner (I think it should…). Just the getwork support for external miners which don't use getblocktemplate... and if you're going to download one of those you could go download bfgminer instead.
Removing getwork and the old miner and packaging a better miner seems the best solution for the reasons already mentioned.
Not directly related, but this remembered me that we planned to remove the accounting features on freicoin. We don't want to adapt them for demurrage and we think business shouldn't use it and should code their own accounting system instead. One that keeps a full log of the accounting, etc. Unfortunately the first exchange to support freicoin (cryptonit) used this feature for accounting user balances on the exchange.
So the question is, is there any good reason to maintain this? Is any serious business really using this or anyone at all?
I'm talking about removing the following rpc calls:
getaccount getaddressesbyaccount getbalance getreceivedbyaccount listaccounts listreceivedbyaccount move sendfrom setaccount
...and modifying these:
getnewaddress listreceivedbyaddress listtransactions sendmany
I think this would also leave a cleaner API, but I'm just interested on what the objections would be to this removal.
How crazy does this sound? Should we reconsider their removal for freicoin, proceed or create a pull request for bitcoin?
On 08/19/2013 10:34 PM, Jeff Garzik wrote:
Quoted text (7 lines)
>> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned >> people that getwork will be removed in the next major version. Pooler's CPU >> minerd which supports both sha256d and scrypt recently grew stratum support. >> Perhaps he could be convinced to add GBT support too, which would help this >> goal of completely removing the internal miner and getwork. > > The internal miner is still actively used for testnet, here.
Here, too. If I'm too impatient to wait for the next block that is.
I think it'd be a pity if the easy way to mine blocks would be removed.
Hence ship a miner that automatically reads the bitcoin.conf to find the RPC authentication info. It would be faster and more efficient than the unoptimized miner while simplifying the bitcoind code. Win for everyone.
Warren
On Mon, Aug 19, 2013 at 1:02 PM, Andreas Schildbach <andreas@schildbach•de>wrote:
Quoted text (31 lines)
> On 08/19/2013 10:34 PM, Jeff Garzik wrote: > > >> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned > >> people that getwork will be removed in the next major version. > Pooler's CPU > >> minerd which supports both sha256d and scrypt recently grew stratum > support. > >> Perhaps he could be convinced to add GBT support too, which would help > this > >> goal of completely removing the internal miner and getwork. > > > > The internal miner is still actively used for testnet, here. > > Here, too. If I'm too impatient to wait for the next block that is. > > I think it'd be a pity if the easy way to mine blocks would be removed. > > > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
Message: 1
Date: Mon, 19 Aug 2013 14:07:46 -0700 From: Gregory Maxwell <gmaxwell@gmail•com> Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind To: "Goss, Brian C., M.D." <Goss.Brian@mayo•edu> Cc: "bitcoin-development@lists•sourceforge•net" <bitcoin-development@lists•sourceforge•net> Message-ID: <CAAS2fgQtGg+SxRc7Byw0_L3NpEudPTtBpmnKYt-+7VEVSnKZaQ@mail•gmail•com> Content-Type: text/plain; charset=UTF-8
On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D. <Goss.Brian@mayo•edu> wrote:
Quoted text (1 line)
> What if we have a massive (like many orders of magnitude) drop in network harsh rate? Might such a function be useful to salvage the (non-functioning) network? Same for IRC bootstrapping. How do we pick ourselves up off the ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).
[Aside: When replying to the digest, please try to trim it]
It appears that we will soon be at a hashrate where all the desktop CPUs in the world couldn't really make a dent in it... certainly not desktop cpus using the slow integrated cpu miner, which is much slower than external optimized cpu miners.
But this is why I suggest packaging up a modern mining tool that supports CPU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so would reduce the difference between testnet and mainnet, and provide an actually useful tool for contributing directly.
Though again, I note, that Jeff's patch doesn't actually remove the integrated miner (I think it should?). Just the getwork support for external miners which don't use getblocktemplate... and if you're going to download one of those you could go download bfgminer instead.
Message: 5 Date: Tue, 20 Aug 2013 01:02:41 +0200 From: Andreas Schildbach <andreas@schildbach•de> Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind To: bitcoin-development@lists•sourceforge•net Message-ID: <kuu86a$ii5$1@ger•gmane•org> Content-Type: text/plain; charset=ISO-8859-1
On 08/19/2013 10:34 PM, Jeff Garzik wrote:
Quoted text (7 lines)
>> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned >> people that getwork will be removed in the next major version. Pooler's CPU >> minerd which supports both sha256d and scrypt recently grew stratum support. >> Perhaps he could be convinced to add GBT support too, which would help this >> goal of completely removing the internal miner and getwork. > > The internal miner is still actively used for testnet, here.
Here, too. If I'm too impatient to wait for the next block that is.
I think it'd be a pity if the easy way to mine blocks would be removed. __________________________________________________________________ My comments start here.
I agree with Andreas. The mining code in bitcoind & qt is not so hard to improve and even use, such as it is. I am sorry to say that using bfgminer is one big, complicated install, on Windows at least, AFAICT from looking at the github code bfgminer-2.10.11.zip. Seems much more work than I had bringing up bitcoind/qt from the "ground up" on my Windows machine. And the mining code is only a small part of the end of main.cpp . I don't see it harming the rest of the code when I run it in the daemon or Qt.
Can't one mine "from a distance" using the RPC interface now anyway, even with the code still there?
I assume that you all would like to have a "seething horde" of new Windows users running and using bitcoin? I know that I sure am trying to make that happen. I think an integrated, wallet, miner, full node on the net (which I presume bitcoind/bitcoin-qt are) is the first step, and maybe should always exist? Though other variations could exist too. Could even be a compile Define, like USE_PNP for example, to strip off this or that?
So for me, if I want to mine, just because my solar powered laptop has some free cpu cycles, I don't mind having a "snow ball's chance in hell" of solving the "next" block. At ~0.5 MHPS on my CPU it takes me ~2.5 hours to go through all (2^32)-1 nonces for a tentative new block, with a particular set of transactions. I only can get "deep" into the nonces when one of those +30 minute blocks comes by! And they do from time to time.
I think forcing users to have two computers to mine, or run two programs, is "pushing it" so to speak? And do I also see some wallet removal code being conjured up on git hub?
I think the beauty that is Satoshi's original bitcoin idea should be kept, together in one package. If the code was properly commented, formatted, organized , etc.etc., which I understand is "postponed" when one is "in the zone" writing code, then I think separating the wallet code or mining code, ought to be much easier.
I feel that the dirty task of at least "calling things by their right names" (as said in the Chinese proverb) should be done first. As an example calling the main Berkeley database environment class instance of the wallet an abbreviated 5 lower case letter cryptic "bitdb" reminds me of the time when ram and disc storage were "dear" and compilers couldn't handle "long" names! I would call it something much grander! Only 46 places to change ! Also the member DbEnv dbenv is equally underplayed as it is the main actor in the play! Let's not even mention pdb being used both for a BerkeleyDB CDB.Db* and as an albeit private leveldb DB*.!
Pointers that aren't called pSomething, un-commented/un-documented magic numbers where commented constants should be, and on and on it goes.
So I just sit back doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you architects march ahead oblivious to the cryptic minefield of code that exists underneath :) My aim is to first clean up the code enough so that I can understand it. Then eventually, take it over to a real Windows project/solution where it can be made into an executable that is palatable for the masses.
Getting off soapbox now and retreating to the back...(bitcointalk.org that is)
Ron
Quoted text (3 lines)
> It appears that we will soon be at a hashrate where all the desktop > CPUs in the world couldn't really make a dent in it... certainly not > desktop cpus using the slow integrated cpu miner,
I thought the integrated miner was retired a version or so ago - I dontrecall seeing it for some time in bitcoin-qt
Now you can buy a USB stick for $20 which can be pushed to around 500MH/s, and there's no reason the manufacturers couldn't ship those with a miner-program onboard !
Rob
Will removing "getwork" from the client impact the "setgenerate" RPC call? I.e. would you still be able to generate coins on testnet-in-a-box this way, or would you need a dedicated miner for that? testnet-in-a-box is very useful for testing and easy to setup, it would be great if it stays that way :).
On Wed, Aug 21, 2013 at 11:39 PM, <rob.golding@astutium•com> wrote:
Quoted text (25 lines)
> > It appears that we will soon be at a hashrate where all the desktop > > CPUs in the world couldn't really make a dent in it... certainly not > > desktop cpus using the slow integrated cpu miner, > > I thought the integrated miner was retired a version or so ago - I > dontrecall seeing it for some time in bitcoin-qt > > Now you can buy a USB stick for $20 which can be pushed to around > 500MH/s, and there's no reason the manufacturers couldn't ship those > with a miner-program onboard ! > > Rob > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz <maciej@bitalo•com> wrote:
Quoted text (4 lines)
> Will removing "getwork" from the client impact the "setgenerate" RPC call? > I.e. would you still be able to generate coins on testnet-in-a-box this way, > or would you need a dedicated miner for that? testnet-in-a-box is very > useful for testing and easy to setup, it would be great if it stays that way
Yes, that is currently being discussed in a separate pull request. My pull request does not impact setgenerate, but an added proposal does remove the internal miner completely.
That would be annoying for testing. Regtest mode allows you to create a new block by just running "setgenerate true" (it switches itself off after creating a block). If you had to set up a complicated set of separate programs just to do regtest mode that'd be a step backwards, IMO.
On Thu, Aug 22, 2013 at 3:18 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (30 lines)
> On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz <maciej@bitalo•com> wrote: > > Will removing "getwork" from the client impact the "setgenerate" RPC > call? > > I.e. would you still be able to generate coins on testnet-in-a-box this > way, > > or would you need a dedicated miner for that? testnet-in-a-box is very > > useful for testing and easy to setup, it would be great if it stays that > way > > Yes, that is currently being discussed in a separate pull request. My > pull request does not impact setgenerate, but an added proposal does > remove the internal miner completely. > > -- > Jeff Garzik > Senior Software Engineer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (5 lines)
> That would be annoying for testing. Regtest mode allows you to create a > new block by just running "setgenerate true" (it switches itself off after > creating a block). If you had to set up a complicated set of separate > programs just to do regtest mode that'd be a step backwards, IMO. >
There is some consensus that when the internal miner is to be removed, a simple miner should be packaged with the main repository as separate program (the "reference miner"?). The only change is that it does no longer need to burden the core code (see also the discussion here: https://github.com/bitcoin/bitcoin/pull/2917).
Wladimir