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