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 amo
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 che
> 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 b
On Monday, July 23, 2012 12:41:15 AM Gavin Andresen wrote:
> > The current block height in coinbase addition currently proposes to use
> > block version 2. However, the protocol change is in fact to the coinbase
> > transaction, not the block itself (which really doesn't have any
> > extensibility
> The current block height in coinbase addition currently proposes to use block
> version 2. However, the protocol change is in fact to the coinbase
> transaction, not the block itself (which really doesn't have any extensibility
> without a hardfork anyway). Perhaps we should consider bumping the
It just occurred to me that the block version number could easily be used as a
cheap "extra nonce" right now. Considering that we will probably see lots of
ASIC miners running at 1 TH/s per rig before the end of 2012, it might be
desirable to save the block version for this purpose.
The current
6 matches
Mail list logo
