From: "Luke-Jr" <luke@dashjr.org>
To: Jeff Garzik <jgarzik@exmulti.com>
Date: Sat, 23 Mar 2013 18:27:20 +0000
User-Agent: KMail/1.13.7 (Linux/3.7.3-gentoo; KDE/4.9.5; x86_64; ; )
References: <CA+8xBpcwLUt=RBYynbQDwY2Bv1keCPy0pdXP4+8CG-wqvrxOCA@mail.gmail.com>
	<201303231751.48969.luke@dashjr.org>
	<CA+8xBpdSHxbzSZenTCLrh7yfCWMLXokbdupTkjpU0V2+B1YV3w@mail.gmail.com>
In-Reply-To: <CA+8xBpdSHxbzSZenTCLrh7yfCWMLXokbdupTkjpU0V2+B1YV3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201303231827.23273.luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Upcoming network event: block v2 lock-in
Precedence: list

On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
> 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.