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

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