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 without a hardfork anyway). Perhaps we should consider > > bumping the coinbase transaction version number to 2 for this instead? > > I'd thought about bumping the coinbase transaction version, but the > problem is if we want a smooth rollout then, during the rollout, every > time a new block comes in the percentage of the last 1,000 blocks that > support the new version has to be computed. > > If that means looking in the coinbase transaction, then either the > last 1,000 coinbases have to be stored in memory or they have to be > fetched from disk. Which isn't a huge deal, unless we start > aggressively pruning spent transactions, and that coinbase 900 blocks > back got spent and pruned.
Any reason CBlockIndex couldn't cache the coinbase version? > On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr <l...@dashjr.org> wrote: > > 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. > > Hmm... I think it'd be ok to give 3 of the 4 block version bytes as a > simple extranonce, so version=0x00000001 is what we have now, version > 2 blocks are any with 0x02 in the low byte, 0x03 is version 3, etc. I > don't think we'll go through 253 block versions before we're all dead. > > 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." That sounds workable. > > Also, Jeff noticed that block 190192 has version==2 without a valid block > > height in the coinbase. I suspect this may be the result of combining the > > current blockheight-in-coinbase pullreq with P2Pool. This means that if > > we go forward with the version==2 marker, we will forever need to make > > an exception for that block. > > No, the rules are "enforce the rules when the chain has a > super-majority." Since block 190192 is in a part of the chain with > zero other version==2 blocks, the height-in-the-coinbase rule will not > be enforced. I was thinking more of the end-game of changing the rule to simply "if version==2, require the height in coinbase" after the point of no return is met without any infringement. ------------------------------------------------------------------------------ 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
