Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VCrQG-0006c4-PR for bitcoin-development@lists.sourceforge.net; Fri, 23 Aug 2013 13:29:04 +0000 X-ACL-Warn: Received: from nm26-vm5.bullet.mail.ne1.yahoo.com ([98.138.91.248]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VCrQF-0007nX-Ok for bitcoin-development@lists.sourceforge.net; Fri, 23 Aug 2013 13:29:04 +0000 Received: from [98.138.226.180] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 23 Aug 2013 13:28:58 -0000 Received: from [98.138.226.163] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 23 Aug 2013 13:28:58 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 23 Aug 2013 13:28:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 513968.78207.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 94909 invoked by uid 60001); 23 Aug 2013 13:28:58 -0000 X-YMail-OSG: 7HdzpZIVM1klPiQdWv1wif1xnoJJQdZkhkLksyINXn9yRHK uMAV4ni8oMrbshlg.rODXV0sRnPRi4JVeRB3iwEUkH5B6G.xlcqp2UGG7UAs h3HL9M67YCE1reYm72RKic6cRz6JTvnOcwBSfDzEKlW2vSOV.cc5yQfdQatn yaSl6gkmy.8OHwQj3dA0lV3ozdz._KhZWZVJYr4TEOjVQ9N2qqSIXpSYb.50 EkPIuaL6uNTYLm_I32WPDIa59AnwTydWDqPQxeVdm0Qm8t4tnsHi5G7QxPHQ U_zKJxlTtPUeTr6YIQtvth3K34dDMcdcMa48nuTqF9BCjky99pNfeYhRToV7 Wgf1MZmmFJ8rLn9LVsrh3ToPPLvbVCrn0iZj9ELIgJP7uMSpqDm1taUKKZEV _Q6BUnwWolvkD3_rZxzBvomRzuIj6keJqJpnNprrfzXnVVnuBQxuuxWFgoaI B.DtSNeic6QWECKdBtfwLdDuyasWtVy7uU6y6dGAod_TEMSiwZG5.Uxqntxz 9r8NVBImvCzMfjIFadKTKefjAwVg3bPmgnsUbI5VvCqZKgGFeRBbo1RMMz0k Z4MR.lCgABRGflXebJOWxBbFGhfJSqvlcVdrglQ6GG.2IXCkdQUquGXr8eEK Eib4rAJkeo_w9zyiFIhaY6tIwmY.TML8RU0cxFDEWy912q.ZRaJdP4II_KP6 T0ZYgTznvfqg7W7LK3nVSyoXONjvTzN8lPk_IrFsNWjVOQPPwPN3L Received: from [69.126.245.209] by web124501.mail.ne1.yahoo.com via HTTP; Fri, 23 Aug 2013 06:28:58 PDT X-Rocket-MIMEInfo: 002.001, CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1lc3NhZ2U6IDYKRGF0ZTogVGh1LCAyMiBBdWcgMjAxMyAxNzozMDoxMyArMDIwMApGcm9tOiBXbGFkaW1pciA8bGFhbndqQGdtYWlsLmNvbT4KU3ViamVjdDogUmU6IFtCaXRjb2luLWRldmVsb3BtZW50XSBQcm9wb3NhbDogcmVtb3ZlICJnZXR3b3JrIiBSUEMgZnJvbQrCoMKgwqAgYml0Y29pbmQKCk1lc3NhZ2UtSUQ6CsKgwqDCoCA8Q0ErcytHSkM0bzVWNXArRlkrYmdXVlV0NXVtZWJuNF8zN2JUaWhmWDJxMUdGMDVTPVZBQG1haWwuZ21haWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: Message-ID: <1377264538.81477.YahooMailNeo@web124501.mail.ne1.yahoo.com> Date: Fri, 23 Aug 2013 06:28:58 -0700 (PDT) From: Ron To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1477594544-920541368-1377264538=:81477" X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.248 listed in list.dnswl.org] 0.0 HK_RANDOM_FROM From username looks random 0.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rdwnj[at]yahoo.com) -2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VCrQF-0007nX-Ok Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 27, Issue 33 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ron List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 13:29:05 -0000 --1477594544-920541368-1377264538=:81477 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A________________________________=0AMessage: 6=0ADate: Thu, 22 A= ug 2013 17:30:13 +0200=0AFrom: Wladimir =0ASubject: Re: [= Bitcoin-development] Proposal: remove "getwork" RPC from=0A=A0=A0=A0 bitcoi= nd=0A=0AMessage-ID:=0A=A0=A0=A0 =0AContent-Type: text/plain; charset=3D"utf-8"= =0A=0AOn Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn wrote:= =0A=0A> That would be annoying for testing. Regtest mode allows you to crea= te a=0A> new block by just running "setgenerate true" (it switches itself o= ff after=0A> creating a block). If you had to set up a complicated set of s= eparate=0A> programs just to do regtest mode that'd be a step backwards, IM= O.=0A>=0A=0AThere is some consensus that when the internal miner is to be r= emoved, a=0Asimple miner should be packaged with the main repository as sep= arate=0Aprogram (the "reference miner"?). The only change is that it does n= o longer=0Aneed to burden the core code=0A(see also the discussion here: ht= tps://github.com/bitcoin/bitcoin/pull/2917).=0A=0A=0AWladimir=0A___________= _______________________________________________=0AI see no burden to the co= de when it is not mining, if that is what you mean by=0Aburden. The miner c= ode's hashes/sec are a function of how much CPU time it =0Agets. When I am = gcc compiling, I see the hashes/sec drop, but bitcoind keeps =0Aup easily s= ide by side with http://blockchain.info/ latest transactions and =0Anew blo= cks. And I only have a single core AMD Athlon 1.8GHz cpu.=0A=0AI would hate= to admit how many browser windows and tabs I have open too,=0Aand an IDE (= LOL)!I will admit that I have modified the miner code a little, =0A=A0to us= e (potentially) every allowable nonce and to check for a new block =0Ain a = timed fashion and be less aggressive, 8 bytes of 0 instead of 4, in checkin= g =0Afor a potential solution. =0A=0ARon --1477594544-920541368-1377264538=:81477 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


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

Message-ID:
    <CA+s+GJC4o5V5p+FY+bgW= VUt5umebn4_37bTihfX2q1GF05S=3DVA@mail.gmail.com>
Content-Type: te= xt/plain; charset=3D"utf-8"

On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <<= a ymailto=3D"mailto:mike@plan99.net" href=3D"mailto:mike@plan99.net">mike@p= lan99.net> wrote:

> That would be annoying for testing. Re= gtest mode allows you to create a
> new block by just running "setgen= erate true" (it switches itself off after
> creating a block). If you= had to set up a complicated set of separate
> programs just to do re= gtest mode that'd be a step backwards, IMO.
>

There is some co= nsensus that when the internal miner is to be removed, a
simple miner sh= ould be packaged with the main repository as separate
program (the "refe= rence 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, b= ut bitcoind keeps
up easily side by side with http://blockchain.info/ l= atest transactions and
new blocks. And I only have a single core AMD At= hlon 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 modifi= ed 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 aggre= ssive, 8 bytes of 0 instead of 4, in checking
for a potential solution.=

Ron

--1477594544-920541368-1377264538=:81477--