* Re: [Bitcoin-development] Bitcoin-development Digest, Vol 27, Issue 33
[not found] <mailman.173353.1377185424.12996.bitcoin-development@lists.sourceforge.net>
@ 2013-08-23 13:28 ` Ron
0 siblings, 0 replies; only message in thread
From: Ron @ 2013-08-23 13:28 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
________________________________
Message: 6
Date: Thu, 22 Aug 2013 17:30:13 +0200
From: Wladimir <laanwj@gmail.com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
bitcoind
Message-ID:
<CA+s+GJC4o5V5p+FY+bgWVUt5umebn4_37bTihfX2q1GF05S=VA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <mike@plan99.net> wrote:
> 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
__________________________________________________________
I see no burden to the code when it is not mining, if that is what you mean by
burden. The miner code's hashes/sec are a function of how much CPU time it
gets. When I am gcc compiling, I see the hashes/sec drop, but bitcoind keeps
up easily side by side with http://blockchain.info/ latest transactions and
new blocks. And I only have a single core AMD Athlon 1.8GHz cpu.
I would hate to admit how many browser windows and tabs I have open too,
and an IDE (LOL)!I will admit that I have modified the miner code a little,
to use (potentially) every allowable nonce and to check for a new block
in a timed fashion and be less aggressive, 8 bytes of 0 instead of 4, in checking
for a potential solution.
Ron
[-- Attachment #2: Type: text/html, Size: 2767 bytes --]
^ permalink raw reply [flat|nested] only message in thread