References: <mailman.167053.1376954386.4583.bitcoin-development@lists.sourceforge.net>
Message-ID: <1377120278.34996.YahooMailNeo@web124501.mail.ne1.yahoo.com>
Date: Wed, 21 Aug 2013 14:24:38 -0700 (PDT)
From: Ron <rdwnj@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <mailman.167053.1376954386.4583.bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="1477594544-495958326-1377120278=:34996"
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
Precedence: list
Reply-To: Ron <rdwnj@yahoo.com>

--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 <gmaxwell@gmail.com>=0ASubject: Re: [Bitcoin-development] Proposal: remo=
ve "getwork" RPC from=0A=A0=A0=A0 bitcoind=0ATo: "Goss, Brian C., M.D." <Go=
ss.Brian@mayo.edu>=0ACc: "bitcoin-development@lists.sourceforge.net"=0A=A0=
=A0=A0 <bitcoin-development@lists.sourceforge.net>=0AMessage-ID:=0A=A0=A0=
=A0 <CAAS2fgQtGg+SxRc7Byw0_L3NpEudPTtBpmnKYt-+7VEVSnKZaQ@mail.gmail.com>=0A=
Content-Type: text/plain; charset=3DUTF-8=0A=0AOn Mon, Aug 19, 2013 at 1:22=
 PM, Goss, Brian C., M.D.=0A<Goss.Brian@mayo.edu> 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=
 <andreas@schildbach.de>=0ASubject: Re: [Bitcoin-development] Proposal: rem=
ove "getwork" RPC from=0A=A0=A0=A0 bitcoind=0ATo: bitcoin-development@lists=
.sourceforge.net=0AMessage-ID: <kuu86a$ii5$1@ger.gmane.org>=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

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt">Message: 1<br><div st=
yle=3D"font-family: times new roman, new york, times, serif; font-size: 12p=
t;"><div style=3D"font-family: times new roman, new york, times, serif; fon=
t-size: 12pt;"><div class=3D"y_msg_container">Date: Mon, 19 Aug 2013 14:07:=
46 -0700<br>From: Gregory Maxwell &lt;<a ymailto=3D"mailto:gmaxwell@gmail.c=
om" href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt;<br>Subjec=
t: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from<br>&nbsp;&=
nbsp;&nbsp; bitcoind<br>To: "Goss, Brian C., M.D." &lt;<a ymailto=3D"mailto=
:Goss.Brian@mayo.edu" href=3D"mailto:Goss.Brian@mayo.edu">Goss.Brian@mayo.e=
du</a>&gt;<br>Cc: "<a ymailto=3D"mailto:bitcoin-development@lists.sourcefor=
ge.net" href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-d=
evelopment@lists.sourceforge.net</a>"<br>&nbsp;&nbsp;&nbsp; &lt;<a
 ymailto=3D"mailto:bitcoin-development@lists.sourceforge.net" href=3D"mailt=
o:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sour=
ceforge.net</a>&gt;<br>Message-ID:<br>&nbsp;&nbsp;&nbsp; &lt;CAAS2fgQtGg+Sx=
Rc7Byw0_L3NpEudPTtBpmnKYt-+<a ymailto=3D"mailto:7VEVSnKZaQ@mail.gmail.com" =
href=3D"mailto:7VEVSnKZaQ@mail.gmail.com">7VEVSnKZaQ@mail.gmail.com</a>&gt;=
<br>Content-Type: text/plain; charset=3DUTF-8<br><br>On Mon, Aug 19, 2013 a=
t 1:22 PM, Goss, Brian C., M.D.<br>&lt;<a ymailto=3D"mailto:Goss.Brian@mayo=
.edu" href=3D"mailto:Goss.Brian@mayo.edu">Goss.Brian@mayo.edu</a>&gt; wrote=
:<br>&gt; What if we have a massive (like many orders of magnitude) drop in=
 network harsh rate?&nbsp; Might such a function be useful to salvage the (=
non-functioning) network? Same for IRC bootstrapping.&nbsp; 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?).<br><br>[Aside: When replying to the d=
igest, please try to trim it]<br><br>It appears that we will soon be at a h=
ashrate where all the desktop<br>CPUs in the world couldn't really make a d=
ent in it... certainly not<br>desktop cpus using the slow integrated cpu mi=
ner, which is much slower<br>than external optimized cpu miners.<br><br>But=
 this is why I suggest packaging up a modern mining tool that<br>supports C=
PU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so<br>would reduc=
e the difference between testnet and mainnet, and provide<br>an actually us=
eful tool for contributing directly.<br><br>Though again, I note, that Jeff=
's patch doesn't actually remove the<br>integrated miner (I think it should=
?).&nbsp; Just the getwork support for<br>external miners which don't use g=
etblocktemplate... and if you're<br>going to download one of those you coul=
d go download bfgminer instead.<br><br>Message: 5<br>Date: Tue, 20
 Aug 2013 01:02:41 +0200<br>From: Andreas Schildbach &lt;<a ymailto=3D"mail=
to:andreas@schildbach.de" href=3D"mailto:andreas@schildbach.de">andreas@sch=
ildbach.de</a>&gt;<br>Subject: Re: [Bitcoin-development] Proposal: remove "=
getwork" RPC from<br>&nbsp;&nbsp;&nbsp; bitcoind<br>To: <a ymailto=3D"mailt=
o:bitcoin-development@lists.sourceforge.net" href=3D"mailto:bitcoin-develop=
ment@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><b=
r>Message-ID: &lt;kuu86a$ii5$<a ymailto=3D"mailto:1@ger.gmane.org" href=3D"=
mailto:1@ger.gmane.org">1@ger.gmane.org</a>&gt;<br>Content-Type: text/plain=
; charset=3DISO-8859-1<br><br>On 08/19/2013 10:34 PM, Jeff Garzik wrote:<br=
><br>&gt;&gt; FWIW, Litecoin 0.8.x entirely removed the internal miner and =
we warned<br>&gt;&gt; people that getwork will be removed in the next major=
 version.&nbsp; Pooler's CPU<br>&gt;&gt; minerd which supports both sha256d=
 and scrypt recently grew stratum support.<br>&gt;&gt; Perhaps he could be
 convinced to add GBT support too, which would help this<br>&gt;&gt; goal o=
f completely removing the internal miner and getwork.<br>&gt; <br>&gt; The =
internal miner is still actively used for testnet, here.<br><br>Here, too. =
If I'm too impatient to wait for the next block that is.<br><br>I think it'=
d be a pity if the easy way to mine blocks would be removed.<br>___________=
_______________________________________________________<br>My comments star=
t here.<br><br>I agree with Andreas. The mining code in bitcoind &amp; qt i=
s not so hard to improve <br>and even use, such as it is. I am sorry to say=
 that using bfgminer is one big, complicated install, <br>on Windows at lea=
st, AFAICT from looking at the github code bfgminer-2.10.11.zip. <br>Seems =
much more work than I had bringing up bitcoind/qt from the "ground up" on m=
y <br>Windows machine. And the mining code is only a small part of the end =
of main.cpp .<br>I don't see it harming the rest of the code when I
 run it in the daemon or Qt.<br><br>Can't one mine "from a distance" using =
the RPC interface now anyway, even with the <br>code still there?<br><br>I =
assume that you all would like to have a "seething horde" of new Windows us=
ers <br>running and using bitcoin? I know that I sure am trying to make tha=
t happen. I think <br>an integrated, wallet, miner, full node on the net (w=
hich I presume bitcoind/bitcoin-qt <br>are) is the first step, and maybe sh=
ould always exist? Though other variations could <br>exist too. Could even =
be a compile Define, like USE_PNP for example, to strip off <br>this or tha=
t?<br><br>So for me, if I want to mine, just because my solar powered lapto=
p has some free cpu <br>cycles, I don't mind having a "snow ball's chance i=
n hell" of solving the "next" block. At <br>~0.5 MHPS on my CPU it takes me=
 ~2.5 hours to go through all (2^32)-1 nonces for a <br>tentative new block=
, with a particular set of transactions. I only can get "deep" into
 <br>the nonces when one of those +30 minute blocks comes by! And they do f=
rom time to time.<br><br>I think forcing users to have two computers to min=
e, or run two programs,&nbsp; is "pushing it" <br>so to speak? And do I als=
o see some wallet removal code being conjured up on git hub?<br><br>I think=
 the beauty that is Satoshi's original bitcoin idea should be kept, togethe=
r in one <br>package. If the code was properly commented, formatted, organi=
zed , etc.etc., which I <br>understand is "postponed" when one is "in the z=
one" writing code, then I think <br>separating the wallet code or mining co=
de, ought to be much easier. <br><br>I feel that the dirty task of at least=
 "calling things by their right names" (as said in the <br>Chinese proverb)=
 should be done first. As an example calling the main Berkeley <br>database=
 environment class instance of the wallet an abbreviated 5 lower case <br>l=
etter cryptic "bitdb" reminds me of the time when ram and disc
 storage were <br>"dear" and compilers couldn't handle "long" names! I woul=
d call it something <br>much grander! Only 46 places to change ! Also the m=
ember DbEnv dbenv <br>is equally underplayed as it is the main actor in the=
 play! Let's not even mention pdb <br>being used both for a BerkeleyDB&nbsp=
; CDB.Db* and as an albeit private leveldb DB*.!<br><br>Pointers that aren'=
t called pSomething, un-commented/un-documented magic numbers <br>where com=
mented constants should be, and on and on it goes.<br><br>So I just sit bac=
k doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you <br>archite=
cts march ahead oblivious to the cryptic minefield of code that exists unde=
rneath :) <br>My aim is to first clean up the code enough so that I can und=
erstand it. Then eventually, <br>take it over to a real Windows project/sol=
ution where it can be made into an executable <br>that is palatable for the=
 masses.<br><br>Getting off soapbox now and retreating to the
 back...(bitcointalk.org that is)<br><br>Ron<br><br></div> </div> </div>  <=
/div></body></html>
--1477594544-495958326-1377120278=:34996--