On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes pe...@coinlab.com wrote:
The proposal is simple, and it's a small change for miners, I imagine.
My question is: why?
I worry about stuffing too many requirements on
So,
The proposal is simple, and it's a small change for miners, I imagine.
My question is: why?
I worry about stuffing too many requirements on the coinbase. I suppose the
coinbase is easily extendible if we run out of bytes, but I think I'd like
to see some more discussion / good / bad type
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index refers
to the first such pair that is not already spent. No?
Yes, that is essentially what BIP 30 did.
We want to do this also, partly for belt and
jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Friday, July 6, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote:
On Fri, Jul 6, 2012 at 12:45 PM
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote:
But those issues are solvable through other, non-backwards incompatible
means. For example, mandate that a transaction hash, output index refers
to the first such pair that is not already spent. No?
Yes, that is
5 matches
Mail list logo
