[Bitcoin-development] Bitcoin-development Digest, Vol 27, Issue 33

Ron rdwnj at yahoo.com
Fri Aug 23 13:28:58 UTC 2013





________________________________
Message: 6
Date: Thu, 22 Aug 2013 17:30:13 +0200
From: Wladimir <laanwj at gmail.com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
    bitcoind

Message-ID:
    <CA+s+GJC4o5V5p+FY+bgWVUt5umebn4_37bTihfX2q1GF05S=VA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130823/9f649a6f/attachment.html>


More information about the bitcoin-dev mailing list