From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1StaWZ-0003ys-Ak for bitcoin-development@lists.sourceforge.net; Tue, 24 Jul 2012 08:31:23 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.161.175 as permitted sender) client-ip=209.85.161.175; envelope-from=peter@coinlab.com; helo=mail-gg0-f175.google.com; Received: from mail-gg0-f175.google.com ([209.85.161.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1StaWT-0004QY-Je for bitcoin-development@lists.sourceforge.net; Tue, 24 Jul 2012 08:31:23 +0000 Received: by ggnp4 with SMTP id p4so6549255ggn.34 for ; Tue, 24 Jul 2012 01:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=RWIqLxMC9q9EZI7jqGfKK5gwkJFZfG4e9NKIUlhhxRA=; b=fCnvxs5XynpMcHHALsTztnFfIEbhQtu08lYUGyR+ISgoKPc9tv+qGvj8a8FwhKWUwF 80ov/Ilc+DXLPXt65MyHhPrv2+0F4aYpOfUk45904nXi8mymb1syQ3fO/agrISO9GWAT N06uMWL6bB+dK521ULxiafuERXZfe4uZ3fydZTe3FUZ700wrcCrE9z6gYnSdbDNXbsFL gC4xBem1lWxe1Q5qlS6+AjBdlgmBbRtTkWAG+MLyMt9sBp7iwahe3whf7LOSFufb7+Xa S3YvCm8XZEuJnNlRnWH93DzqnvtHdzDYqvLYGrOvgr0tsi3LvCBMy5Ph2FRgzYVPzOGw BM/A== Received: by 10.42.145.7 with SMTP id d7mr13185668icv.45.1343116892596; Tue, 24 Jul 2012 01:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.3 with HTTP; Tue, 24 Jul 2012 01:01:11 -0700 (PDT) In-Reply-To: References: <201207222052.28579.luke@dashjr.org> From: Peter Vessenes Date: Tue, 24 Jul 2012 17:01:11 +0900 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=90e6ba6136b846696d04c58ec544 X-Gm-Message-State: ALoCoQn1BPJf792qoN64GMcmLFtYSOGma+oaa8cd9fohdqhE6ra6n07hY/2vsmQk7WtzFJMyzfjy 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1StaWT-0004QY-Je 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:31:23 -0000 --90e6ba6136b846696d04c58ec544 Content-Type: text/plain; charset=ISO-8859-1 I think it would be great to have more nonce space with less merkle calculation; keeping track of all possible versions of a block already takes real RAM, real computation. Being able to change one bit in the header and send out a new block for checking would ease our pool server work by a real amount, somewhat on the work generation side, but also on the checking old work side; we'll have a lot fewer unique transaction / coinbase sets to hold on to for checking when we get back a solution. Peter On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn wrote: > > That'd be 7 bytes of nonce in the block header, which is > > 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes > > > > So: the changes for version 2 blocks would be "has height in the > > coinbase, and has a 1-byte version number with a 3-byte extranonce." > > I don't understand why more nonce bits are necessary. Is it really > impossible for a multi-core CPU to keep up with the merkle root > re-calculation and keep an ASIC miner fed, or is this working around a > performance bottleneck somewhere else? > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 --90e6ba6136b846696d04c58ec544 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be great to have more nonce space with less merkle calcula= tion; keeping track of all possible versions of a block already takes real = RAM, real computation. Being able to change one bit in the header and send = out a new block for checking would ease our pool server work by a real amou= nt, somewhat on the work generation side, but also on the checking old work= side; we'll have a lot fewer unique transaction / coinbase sets to hol= d on to for checking when we get back a solution.

Peter


On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn <mike@plan99.net> wrote:
> That'd be 7 bytes= of nonce in the block header, which is
> =A0 72,057,594,037,927,936 =A0~ 72 petahashes =3D 72,000 terahashes >
> So: the changes for version 2 blocks would be "has height in the<= br> > coinbase, and has a 1-byte version number with a 3-byte extranonce.&qu= ot;

I don't understand why more nonce bits are necessary. Is it reall= y
impossible for a multi-core CPU to keep up with the merkle root
re-calculation and keep an ASIC miner fed, or is this working around a
performance bottleneck somewhere else?

---------------------------------------------------------------------------= ---
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--
=

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104

--90e6ba6136b846696d04c58ec544--