Re: [Bitcoin-development] Reconsidering block version number use

2012-07-24 Thread Mike Hearn
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

Re: [Bitcoin-development] Reconsidering block version number use

2012-07-24 Thread Mike Hearn
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

Re: [Bitcoin-development] Reconsidering block version number use

2012-07-24 Thread Peter Vessenes
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