Upcoming network event: block v2 lock-in
9 messages, 23 Mar 2013. Started by Jeff Garzik.
Jeff Garzik (4), Luke Dashjr (4), Greg Maxwell
Once a supermajority (95%) of mining reaches block version 2, nVersion==1 blocks will be rejected. This event seems likely to occur in the next week.
Version 2 block specification: https://en.bitcoin.it/wiki/BIP_0034
Watching for the event: http://blockorigin.pfoe.be/top.php The text is at the bottom: "We are currently at 100 out of the latest 1000 blocks on version 1 (10.00%) and 899 out of the latest 1000 blocks on version 2 (89.90%)"
Users should not be impacted. Some ancient miners will produce newly-invalid blocks (v1), that will get ignored. The easy solution is to mine using a recent bitcoind (0.7 or later). If you are a miner and need help upgrading to v2, ping us on #bitcoin-dev or bitcoin-development@lists•sourceforge•net.
On Saturday, March 23, 2013 4:16:19 PM Jeff Garzik wrote:
Quoted text (5 lines)
> Users should not be impacted. Some ancient miners will produce > newly-invalid blocks (v1), that will get ignored. The easy solution > is to mine using a recent bitcoind (0.7 or later). If you are a miner > and need help upgrading to v2, ping us on #bitcoin-dev or > bitcoin-development@lists•sourceforge•net.
I don't think anyone is mining using bitcoind 0.7 or later? Deepbit is the only pool I know of using bitcoind at all, and it's based on 0.3.21 (or about that)...
p2pool has supported v2 blocks since 2012 Aug 8. Eloipool has supported v2 blocks since 2012 Sep 1. slush's stratum server has supported v2 blocks since it was written.
I'm not aware of any other maintained open source poolservers. At least PoolServerJ and ecoinpool are known to break when v2 blocks become mandatory.
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (1 line)
> I don't think anyone is mining using bitcoind 0.7 or later?
slush, BTC Guild, ozcoin too I think, several others.
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
Quoted text (4 lines)
> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr <luke@dashjr•org> wrote: > > I don't think anyone is mining using bitcoind 0.7 or later? > > slush, BTC Guild, ozcoin too I think, several others.
Not for producing coinbases (where BIP 34 is implemented).
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (7 lines)
> On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: >> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr <luke@dashjr•org> wrote: >> > I don't think anyone is mining using bitcoind 0.7 or later? >> >> slush, BTC Guild, ozcoin too I think, several others. > > Not for producing coinbases (where BIP 34 is implemented).
Sure, that is largely the pool server layer. But it is misleading to imply that bitcoind is nowhere in the stack.
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
Quoted text (11 lines)
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr <luke@dashjr•org> wrote: > > On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: > >> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr <luke@dashjr•org> wrote: > >> > I don't think anyone is mining using bitcoind 0.7 or later? > >> > >> slush, BTC Guild, ozcoin too I think, several others. > > > > Not for producing coinbases (where BIP 34 is implemented). > > Sure, that is largely the pool server layer. But it is misleading to > imply that bitcoind is nowhere in the stack.
Context is everything. bitcoind is nowhere in the implementation of the miner end of BIP 34.
On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (1 line)
> bitcoind is nowhere in the implementation of the miner end of BIP 34.
Again, not strictly true.
bitcoind's 'getblocktemplate' RPC call used by some supplies the block version, selects transactions for the miner, and other tasks integral to the implementation of the miner and BIP 34.
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
Quoted text (8 lines)
> On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr <luke@dashjr•org> wrote: > > bitcoind is nowhere in the implementation of the miner end of BIP 34. > > Again, not strictly true. > > bitcoind's 'getblocktemplate' RPC call used by some supplies the block > version, selects transactions for the miner, and other tasks integral > to the implementation of the miner and BIP 34.
Transaction selection and everything else bitcoind does, is irrelevant to BIP 34. It is incompatible with getblocktemplate for coinbase-creating software to produce v2 blocks without implementing BIP 34 themselves, even if the upstream GBT server specifies it.
On Sat, Mar 23, 2013 at 10:47 AM, Jeff Garzik <jgarzik@exmulti•com> wrote:
Quoted text (4 lines)
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr <luke@dashjr•org> wrote: >> Not for producing coinbases (where BIP 34 is implemented). > Sure, that is largely the pool server layer. But it is misleading to > imply that bitcoind is nowhere in the stack.
You're both right: BIP34's addition of the height is implemented in the coinbase generator, so for almost everyone the Bitcoind version is not very relevant for that. Rejection of invalid chains, however, is in the Bitcoin daemon. Upgrading bitcoind alone should be sufficient to prevent the creation of forks, though if miners would like to avoid losing income they must update _both_ so that they don't create invalid blocks or mine on invalid forks.