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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1R9DmI-0001eF-MY
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Sep 2011 10:23:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R9DmE-0002jl-Gj
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Sep 2011 10:23:42 +0000
Received: by yxj17 with SMTP id 17so534227yxj.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Sep 2011 03:23:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.11 with SMTP id x11mr3177937ybx.279.1317291813003; Thu,
29 Sep 2011 03:23:33 -0700 (PDT)
Received: by 10.150.57.13 with HTTP; Thu, 29 Sep 2011 03:23:32 -0700 (PDT)
In-Reply-To: <4E80D591.2080100@nilsschneider.net>
References: <4E80D591.2080100@nilsschneider.net>
Date: Thu, 29 Sep 2011 10:23:32 +0000
Message-ID: <CAJNQ0stW-7HMw-O_C9Go8ViRrxBNtEpsbhSRyc3aOzm6OvR6dA@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Nils Schneider <nils@nilsschneider.net>
Content-Type: multipart/alternative; boundary=000e0cd6a6f094626604ae11e644
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
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 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R9DmE-0002jl-Gj
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Deprecating "midstate" in getwork?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 29 Sep 2011 10:23:42 -0000
--000e0cd6a6f094626604ae11e644
Content-Type: text/plain; charset=ISO-8859-1
Nils,
Sounds good. I'm also doubtful of depending on two crypto libraries when
OpenSSL does perfectly well.
However, losing compatibility with miners is not very nice. Is there really
not a way to compute midstate with OpenSSL?
JS
On Mon, Sep 26, 2011 at 7:42 PM, Nils Schneider <nils@nilsschneider.net>wrote:
> Hey,
>
> I'd like to simplify the internal reference miner and remove all
> dependencies on cryptopp (it's the only place we use cryptopp instead of
> OpenSSL).
>
> Unfortunately, cryptopp is also used to calculate getwork "midstate".
> This field is redundant and the miner could easily calculate it from the
> blockheader so I'd like to remove it.
>
> Any thoughts? Where should such a change should be announced so all
> miners can be upgraded?
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--000e0cd6a6f094626604ae11e644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Nils,<br><br>Sounds good. I'm also doubtful of depending on two crypto =
libraries when OpenSSL does perfectly well. <br><br>However, losing compati=
bility with miners is not very nice. Is there really not a way to compute m=
idstate with OpenSSL?<br>
<br>JS<br><br><div class=3D"gmail_quote">On Mon, Sep 26, 2011 at 7:42 PM, N=
ils Schneider <span dir=3D"ltr"><<a href=3D"mailto:nils@nilsschneider.ne=
t">nils@nilsschneider.net</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Hey,<br>
<br>
I'd like to simplify the internal reference miner and remove all<br>
dependencies on cryptopp (it's the only place we use cryptopp instead o=
f<br>
OpenSSL).<br>
<br>
Unfortunately, cryptopp is also used to calculate getwork "midstate&qu=
ot;.<br>
This field is redundant and the miner could easily calculate it from the<br=
>
blockheader so I'd like to remove it.<br>
<br>
Any thoughts? Where should such a change should be announced so all<br>
miners can be upgraded?<br>
<br>
---------------------------------------------------------------------------=
---<br>
All the data continuously generated in your IT infrastructure contains a<br=
>
definitive record of customers, application performance, security<br>
threats, fraudulent activity and more. Splunk takes this data and makes<br>
sense of it. Business sense. IT sense. Common sense.<br>
<a href=3D"http://p.sf.net/sfu/splunk-d2dcopy1" target=3D"_blank">http://p.=
sf.net/sfu/splunk-d2dcopy1</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br>
--000e0cd6a6f094626604ae11e644--
|
