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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering block version number use
Precedence: list

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.