1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
|
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 <rdwnj@yahoo.com>) 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: <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"
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 <rdwnj@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 <<a ymailto=3D"mailto:gmaxwell@gmail.c=
om" href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>><br>Subjec=
t: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from<br> &=
nbsp; bitcoind<br>To: "Goss, Brian C., M.D." <<a ymailto=3D"mailto=
:Goss.Brian@mayo.edu" href=3D"mailto:Goss.Brian@mayo.edu">Goss.Brian@mayo.e=
du</a>><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> <<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>><br>Message-ID:<br> <CAAS2fgQtGg+Sx=
Rc7Byw0_L3NpEudPTtBpmnKYt-+<a ymailto=3D"mailto:7VEVSnKZaQ@mail.gmail.com" =
href=3D"mailto:7VEVSnKZaQ@mail.gmail.com">7VEVSnKZaQ@mail.gmail.com</a>>=
<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><<a ymailto=3D"mailto:Goss.Brian@mayo=
.edu" href=3D"mailto:Goss.Brian@mayo.edu">Goss.Brian@mayo.edu</a>> wrote=
:<br>> 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?).<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=
?). 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 <<a ymailto=3D"mail=
to:andreas@schildbach.de" href=3D"mailto:andreas@schildbach.de">andreas@sch=
ildbach.de</a>><br>Subject: Re: [Bitcoin-development] Proposal: remove "=
getwork" RPC from<br> 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: <kuu86a$ii5$<a ymailto=3D"mailto:1@ger.gmane.org" href=3D"=
mailto:1@ger.gmane.org">1@ger.gmane.org</a>><br>Content-Type: text/plain=
; charset=3DISO-8859-1<br><br>On 08/19/2013 10:34 PM, Jeff Garzik wrote:<br=
><br>>> FWIW, Litecoin 0.8.x entirely removed the internal miner and =
we warned<br>>> people that getwork will be removed in the next major=
version. Pooler's CPU<br>>> minerd which supports both sha256d=
and scrypt recently grew stratum support.<br>>> Perhaps he could be
convinced to add GBT support too, which would help this<br>>> goal o=
f completely removing the internal miner and getwork.<br>> <br>> 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 & 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, 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 =
; 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--
|