From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <201207222052.28579.luke@dashjr.org> Date: Tue, 24 Jul 2012 10:22:25 +0200 X-Google-Sender-Auth: cdCo6m67blEuOvp6zTREwKAWkY8 Message-ID: From: Mike Hearn To: Peter Vessenes 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.