From: Ron <rdwnj@yahoo•com>
To: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 27, Issue 33
Date: Fri, 23 Aug 2013 06:28:58 -0700 (PDT) [thread overview]
Message-ID: <1377264538.81477.YahooMailNeo@web124501.mail.ne1.yahoo.com> (raw)
In-Reply-To: <mailman.173353.1377185424.12996.bitcoin-development@lists.sourceforge.net>
[-- 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 --]
parent reply other threads:[~2013-08-23 13:29 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <mailman.173353.1377185424.12996.bitcoin-development@lists.sourceforge.net>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377264538.81477.YahooMailNeo@web124501.mail.ne1.yahoo.com \
--to=rdwnj@yahoo$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox