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 <mike@plan99.net> 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



--

CoinLab LogoPETER VESSENES 
CEO

peter@coinlab.com  /  206.486.6856  / SKYPE: vessenes 
811 FIRST AVENUE  /  SUITE 480  /  SEATTLE, WA 98104