blob: 8ec0f4e561d9a366d584bd266fe9b04601b3258a (
plain)
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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1StaO5-0006AZ-9l
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jul 2012 08:22:37 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1StaNz-0003jV-Ua
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jul 2012 08:22:37 +0000
Received: by wgbfm10 with SMTP id fm10so5487726wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Jul 2012 01:22:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.20.239 with SMTP id q15mr4734277wie.13.1343118145746; Tue,
24 Jul 2012 01:22:25 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.19.13 with HTTP; Tue, 24 Jul 2012 01:22:25 -0700 (PDT)
In-Reply-To: <CAMGNxUvRXA4y98ojrzQqLhKcYPXM9CUFXKdguQz3iu=jaNvk5w@mail.gmail.com>
References: <201207222052.28579.luke@dashjr.org>
<CABsx9T0JK9qBKZu7YWeQCBAjT1Ur05BQ26A5NdLCwD6Wuyc0nQ@mail.gmail.com>
<CANEZrP0NMmwWN1U3V_hha7+C8meKWK_szhh+6xP7VQMbFTLoqQ@mail.gmail.com>
<CAMGNxUvRXA4y98ojrzQqLhKcYPXM9CUFXKdguQz3iu=jaNvk5w@mail.gmail.com>
Date: Tue, 24 Jul 2012 10:22:25 +0200
X-Google-Sender-Auth: cdCo6m67blEuOvp6zTREwKAWkY8
Message-ID: <CANEZrP0QQKukDa6biLqDjEvra7KSQbeo991-LJ9faa-39n5CVg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1StaNz-0003jV-Ua
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering block version number use
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: Tue, 24 Jul 2012 08:22:37 -0000
My point is that stuffing nonces into whatever spaces we can find to
eke out a bit more scalability in pools seems like a very short term
fix with potentially very long term consequences.
Although it may sound harsh, if your pool is struggling to keep up
with calculating merkle roots (which is cheap!) then it's time to
either upgrade your pool or for some of those users to migrate to
p2pool and handle creation of work themselves. Trying to squash more
nonce bits out of fields that were never meant for that seems like a
bad precedent with no real motivation beyond making running
centralized pools a bit cheaper.
What I'm interested in is, can a powerful server-class machine really
not keep up with work generation for things like the BitForce SC
devices? How many devices would you need to exhaust the ability to
generate work for them? You'll need powerful machines just to run a
node at all sooner or later.
|
