* [Bitcoin-development] Reconsidering block version number use
@ 2012-07-22 20:52 Luke-Jr
2012-07-23 0:41 ` Gavin Andresen
0 siblings, 1 reply; 6+ messages in thread
From: Luke-Jr @ 2012-07-22 20:52 UTC (permalink / raw)
To: bitcoin-development
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 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?
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. Moving the version==2 to the coinbase transaction version also
means whoever makes that transaction (thus deciding whether to put the height
in it or not) also sets the version number - instead of the block version
coming from bitcoind and the coinbase transaction coming from P2Pool or other
software.
Thoughts?
Luke
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Reconsidering block version number use
2012-07-22 20:52 [Bitcoin-development] Reconsidering block version number use Luke-Jr
@ 2012-07-23 0:41 ` Gavin Andresen
2012-07-23 0:57 ` Luke-Jr
2012-07-24 7:58 ` Mike Hearn
0 siblings, 2 replies; 6+ messages in thread
From: Gavin Andresen @ 2012-07-23 0:41 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
> 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.
On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr <luke@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."
> 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.
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Reconsidering block version number use
2012-07-23 0:41 ` Gavin Andresen
@ 2012-07-23 0:57 ` Luke-Jr
2012-07-24 7:58 ` Mike Hearn
1 sibling, 0 replies; 6+ messages in thread
From: Luke-Jr @ 2012-07-23 0:57 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
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 <luke@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Reconsidering block version number use
2012-07-23 0:41 ` Gavin Andresen
2012-07-23 0:57 ` Luke-Jr
@ 2012-07-24 7:58 ` Mike Hearn
2012-07-24 8:01 ` Peter Vessenes
1 sibling, 1 reply; 6+ messages in thread
From: Mike Hearn @ 2012-07-24 7:58 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Reconsidering block version number use
2012-07-24 7:58 ` Mike Hearn
@ 2012-07-24 8:01 ` Peter Vessenes
2012-07-24 8:22 ` Mike Hearn
0 siblings, 1 reply; 6+ messages in thread
From: Peter Vessenes @ 2012-07-24 8:01 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
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
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
[-- Attachment #2: Type: text/html, Size: 3546 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Reconsidering block version number use
2012-07-24 8:01 ` Peter Vessenes
@ 2012-07-24 8:22 ` Mike Hearn
0 siblings, 0 replies; 6+ messages in thread
From: Mike Hearn @ 2012-07-24 8:22 UTC (permalink / raw)
To: Peter Vessenes; +Cc: bitcoin-development
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 cheap!) then it's time to
either upgrade your pool or for some of those users to migrate to
p2pool and handle creation of work themselves. Trying to squash more
nonce bits out of fields that were never meant for that seems like a
bad precedent with no real motivation beyond making running
centralized pools a bit cheaper.
What I'm interested in is, can a powerful server-class machine really
not keep up with work generation for things like the BitForce SC
devices? How many devices would you need to exhaust the ability to
generate work for them? You'll need powerful machines just to run a
node at all sooner or later.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-24 8:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-22 20:52 [Bitcoin-development] Reconsidering block version number use Luke-Jr
2012-07-23 0:41 ` Gavin Andresen
2012-07-23 0:57 ` Luke-Jr
2012-07-24 7:58 ` Mike Hearn
2012-07-24 8:01 ` Peter Vessenes
2012-07-24 8:22 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox