Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VCFtX-0008Cd-0R for bitcoin-development@lists.sourceforge.net; Wed, 21 Aug 2013 21:24:47 +0000 X-ACL-Warn: Received: from nm14.bullet.mail.ne1.yahoo.com ([98.138.90.77]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VCFtU-00065E-Vi for bitcoin-development@lists.sourceforge.net; Wed, 21 Aug 2013 21:24:46 +0000 Received: from [98.138.226.176] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2013 21:24:39 -0000 Received: from [98.138.89.245] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2013 21:24:39 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 21 Aug 2013 21:24:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 451614.30731.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 35230 invoked by uid 60001); 21 Aug 2013 21:24:39 -0000 X-YMail-OSG: U7fRDkcVM1kAqyMOOSiyDZUfU.h9yiaw4p0XS.76te8hk.6 dk_knbzp5DZOVhSaqoH5g_.q78Xk1sl1OYqdU4ipunVeFtuh.fJxTbAfo5vq 2NTora_jqi4hnt6mPfHbJiweVIqJhWXmmJQDgPMweZMUeTAl4JKhX8Tu6rrg PgSf7qPvJXRtyHcqiT7ymIK0oBsHC1ug5cExruaxdFJ1SjMbjkga4N8fOrVK vIzW3sJTtYXbOkJvWp0MZgtUYvVgYjJ.Fm8Z8xpZNUUPX6VuHoWhpkVOA4WY hGnnqNEwH9eGgsBqlEXiR2YMjxH9hvA7msCT8BLgbYiFVaGnE4YEHAZjInbS N4yL8cK9GxBICl7G8hlmWJvEBMqqpdJNYfAdZIJvxAwaAH_Ureko6TcnN0Tn DFz.aGBYzhumYBIbvV.gz2CUh5hwtQoWgQHjbuh.6GY7kTomBJvQD5gxNW4R INtR4mKKAMuEKpX.qPB1qGQWcIeZU8d13TOP9_IkJRRpqn4dKxb2wX9po16c c.uaHOJv_AC_jxA6uZt2omf3O959oH4dbjlA7JnSCQA4.cPG7Km86esSLRxy 6JUsPAQ9BQQF7WoQoSF86bGvI0nit.7nelTWpym2azNiVoSdSB1R5a4OHXHk lpsFPOUaJERRz_Ta8BcLaklIvOqXIq.U_TSnYNZpBUoniVQJfCe2gDvW2dzE Wc4TZ_sGd Received: from [67.81.143.244] by web124501.mail.ne1.yahoo.com via HTTP; Wed, 21 Aug 2013 14:24:38 PDT X-Rocket-MIMEInfo: 002.001, TWVzc2FnZTogMQoKRGF0ZTogTW9uLCAxOSBBdWcgMjAxMyAxNDowNzo0NiAtMDcwMApGcm9tOiBHcmVnb3J5IE1heHdlbGwgPGdtYXh3ZWxsQGdtYWlsLmNvbT4KU3ViamVjdDogUmU6IFtCaXRjb2luLWRldmVsb3BtZW50XSBQcm9wb3NhbDogcmVtb3ZlICJnZXR3b3JrIiBSUEMgZnJvbQrCoMKgwqAgYml0Y29pbmQKVG86ICJHb3NzLCBCcmlhbiBDLiwgTS5ELiIgPEdvc3MuQnJpYW5AbWF5by5lZHU.CkNjOiAiYml0Y29pbi1kZXZlbG9wbWVudEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQiCsKgwqDCoCA8Yml0Y28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.155.576 References: Message-ID: <1377120278.34996.YahooMailNeo@web124501.mail.ne1.yahoo.com> Date: Wed, 21 Aug 2013 14:24:38 -0700 (PDT) From: Ron To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1477594544-495958326-1377120278=:34996" 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.90.77 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 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1VCFtU-00065E-Vi Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind 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: Wed, 21 Aug 2013 21:24:47 -0000 --1477594544-495958326-1377120278=:34996 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message: 1=0A=0ADate: Mon, 19 Aug 2013 14:07:46 -0700=0AFrom: Gregory Maxwe= ll =0ASubject: Re: [Bitcoin-development] Proposal: remo= ve "getwork" RPC from=0A=A0=A0=A0 bitcoind=0ATo: "Goss, Brian C., M.D." =0ACc: "bitcoin-development@lists.sourceforge.net"=0A=A0= =A0=A0 =0AMessage-ID:=0A=A0=A0= =A0 =0A= Content-Type: text/plain; charset=3DUTF-8=0A=0AOn Mon, Aug 19, 2013 at 1:22= PM, Goss, Brian C., M.D.=0A wrote:=0A> What if we hav= e a massive (like many orders of magnitude) drop in network harsh rate?=A0 = Might such a function be useful to salvage the (non-functioning) network? S= ame for IRC bootstrapping.=A0 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 h= ardware off?).=0A=0A[Aside: When replying to the digest, please try to trim= it]=0A=0AIt appears that we will soon be at a hashrate where all the deskt= op=0ACPUs in the world couldn't really make a dent in it... certainly not= =0Adesktop cpus using the slow integrated cpu miner, which is much slower= =0Athan external optimized cpu miners.=0A=0ABut this is why I suggest packa= ging up a modern mining tool that=0Asupports CPU/GPU/FPGA/ASIC mining again= st a current bitcoind. Doing so=0Awould reduce the difference between testn= et and mainnet, and provide=0Aan actually useful tool for contributing dire= ctly.=0A=0AThough again, I note, that Jeff's patch doesn't actually remove = the=0Aintegrated miner (I think it should?).=A0 Just the getwork support fo= r=0Aexternal miners which don't use getblocktemplate... and if you're=0Agoi= ng to download one of those you could go download bfgminer instead.=0A=0AMe= ssage: 5=0ADate: Tue, 20 Aug 2013 01:02:41 +0200=0AFrom: Andreas Schildbach= =0ASubject: Re: [Bitcoin-development] Proposal: rem= ove "getwork" RPC from=0A=A0=A0=A0 bitcoind=0ATo: bitcoin-development@lists= .sourceforge.net=0AMessage-ID: =0AContent-Type:= text/plain; charset=3DISO-8859-1=0A=0AOn 08/19/2013 10:34 PM, Jeff Garzik = wrote:=0A=0A>> FWIW, Litecoin 0.8.x entirely removed the internal miner and= we warned=0A>> people that getwork will be removed in the next major versi= on.=A0 Pooler's CPU=0A>> minerd which supports both sha256d and scrypt rece= ntly grew stratum support.=0A>> Perhaps he could be convinced to add GBT su= pport too, which would help this=0A>> goal of completely removing the inter= nal miner and getwork.=0A> =0A> The internal miner is still actively used f= or testnet, here.=0A=0AHere, too. If I'm too impatient to wait for the next= block that is.=0A=0AI think it'd be a pity if the easy way to mine blocks = would be removed.=0A_______________________________________________________= ___________=0AMy comments start here.=0A=0AI agree with Andreas. The mining= code in bitcoind & qt is not so hard to improve =0Aand even use, such as i= t is. I am sorry to say that using bfgminer is one big, complicated install= , =0Aon Windows at least, AFAICT from looking at the github code bfgminer-2= .10.11.zip. =0ASeems much more work than I had bringing up bitcoind/qt from= the "ground up" on my =0AWindows machine. And the mining code is only a sm= all part of the end of main.cpp .=0AI don't see it harming the rest of the = code when I run it in the daemon or Qt.=0A=0ACan't one mine "from a distanc= e" using the RPC interface now anyway, even with the =0Acode still there?= =0A=0AI assume that you all would like to have a "seething horde" of new Wi= ndows users =0Arunning and using bitcoin? I know that I sure am trying to m= ake that happen. I think =0Aan integrated, wallet, miner, full node on the = net (which I presume bitcoind/bitcoin-qt =0Aare) is the first step, and may= be should always exist? Though other variations could =0Aexist too. Could e= ven be a compile Define, like USE_PNP for example, to strip off =0Athis or = that?=0A=0ASo for me, if I want to mine, just because my solar powered lapt= op has some free cpu =0Acycles, I don't mind having a "snow ball's chance i= n hell" of solving the "next" block. At =0A~0.5 MHPS on my CPU it takes me = ~2.5 hours to go through all (2^32)-1 nonces for a =0Atentative new block, = with a particular set of transactions. I only can get "deep" into =0Athe no= nces when one of those +30 minute blocks comes by! And they do from time to= time.=0A=0AI think forcing users to have two computers to mine, or run two= programs,=A0 is "pushing it" =0Aso to speak? And do I also see some wallet= removal code being conjured up on git hub?=0A=0AI think the beauty that is= Satoshi's original bitcoin idea should be kept, together in one =0Apackage= . If the code was properly commented, formatted, organized , etc.etc., whic= h I =0Aunderstand is "postponed" when one is "in the zone" writing code, th= en I think =0Aseparating the wallet code or mining code, ought to be much e= asier. =0A=0AI feel that the dirty task of at least "calling things by thei= r right names" (as said in the =0AChinese proverb) should be done first. As= an example calling the main Berkeley =0Adatabase environment class instanc= e of the wallet an abbreviated 5 lower case =0Aletter cryptic "bitdb" remin= ds me of the time when ram and disc storage were =0A"dear" and compilers co= uldn't handle "long" names! I would call it something =0Amuch grander! Only= 46 places to change ! Also the member DbEnv dbenv =0Ais equally underplaye= d as it is the main actor in the play! Let's not even mention pdb =0Abeing = used both for a BerkeleyDB=A0 CDB.Db* and as an albeit private leveldb DB*.= !=0A=0APointers that aren't called pSomething, un-commented/un-documented m= agic numbers =0Awhere commented constants should be, and on and on it goes.= =0A=0ASo I just sit back doing the clean up on 0.8.1, then .0.8.2, now 0.8.= 3 while you =0Aarchitects march ahead oblivious to the cryptic minefield of= code that exists underneath :) =0AMy aim is to first clean up the code eno= ugh so that I can understand it. Then eventually, =0Atake it over to a real= Windows project/solution where it can be made into an executable =0Athat i= s palatable for the masses.=0A=0AGetting off soapbox now and retreating to = the back...(bitcointalk.org that is)=0A=0ARon --1477594544-495958326-1377120278=:34996 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Message: 1
Date: Mon, 19 Aug 2013 14:07:= 46 -0700
From: Gregory Maxwell <gmaxwell@gmail.com>
Subjec= t: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
 &= nbsp;  bitcoind
To: "Goss, Brian C., M.D." <Goss.Brian@mayo.e= du>
Cc: "bitcoin-d= evelopment@lists.sourceforge.net"
    <bitcoin-development@lists.sour= ceforge.net>
Message-ID:
    <CAAS2fgQtGg+Sx= Rc7Byw0_L3NpEudPTtBpmnKYt-+7VEVSnKZaQ@mail.gmail.com>=
Content-Type: text/plain; charset=3DUTF-8

On Mon, Aug 19, 2013 a= t 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 diffic= ulty up and then turning his hardware off?).

[Aside: When replying to the d= igest, please try to trim it]

It appears that we will soon be at a h= ashrate where all the desktop
CPUs in the world couldn't really make a d= ent in it... certainly not
desktop cpus using the slow integrated cpu mi= ner, which is much slower
than external optimized cpu miners.

But= this is why I suggest packaging up a modern mining tool that
supports C= PU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so
would reduc= e the difference between testnet and mainnet, and provide
an actually us= eful 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 g= etblocktemplate... and if you're
going to download one of those you coul= d go download bfgminer instead.

Message: 5
Date: Tue, 20 Aug 2013 01:02:41 +0200
From: Andreas Schildbach <andreas@sch= ildbach.de>
Subject: Re: [Bitcoin-development] Proposal: remove "= getwork" RPC from
    bitcoind
To: bitcoin-development@lists.sourceforge.netMessage-ID: <kuu86a$ii5$1@ger.gmane.org>
Content-Type: text/plain= ; charset=3DISO-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 o= f 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 star= t here.

I agree with Andreas. The mining code in bitcoind & qt i= s 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 lea= st, 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 m= y
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 us= ers
running and using bitcoin? I know that I sure am trying to make tha= t happen. I think
an integrated, wallet, miner, full node on the net (w= hich I presume bitcoind/bitcoin-qt
are) is the first step, and maybe sh= ould always exist? Though other variations could
exist too. Could even = be a compile Define, like USE_PNP for example, to strip off
this or tha= t?

So for me, if I want to mine, just because my solar powered lapto= p has some free cpu
cycles, I don't mind having a "snow ball's chance i= n 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 f= rom time to time.

I think forcing users to have two computers to min= e, or run two programs,  is "pushing it"
so to speak? And do I als= o 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, togethe= r in one
package. If the code was properly commented, formatted, organi= zed , etc.etc., which I
understand is "postponed" when one is "in the z= one" writing code, then I think
separating the wallet code or mining co= de, 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
l= etter cryptic "bitdb" reminds me of the time when ram and disc storage were
"dear" and compilers couldn't handle "long" names! I woul= d call it something
much grander! Only 46 places to change ! Also the m= ember 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 com= mented constants should be, and on and on it goes.

So I just sit bac= k doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you
archite= cts march ahead oblivious to the cryptic minefield of code that exists unde= rneath :)
My aim is to first clean up the code enough so that I can und= erstand it. Then eventually,
take it over to a real Windows project/sol= ution 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

<= /div> --1477594544-495958326-1377120278=:34996--