[Bitcoin-development] BIP 34: Block v2, Height in Coinbase

Amir Taaki zgenjix at yahoo.com
Fri Jul 6 20:02:40 UTC 2012

It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me.

From: Mark Friedenbach <mark at monetize.io>
To: Jeff Garzik <jgarzik at exmulti.com> 
Cc: Bitcoin Development <bitcoin-development at 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 <jgarzik at exmulti.com> wrote:

On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter at 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 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 cases for making this
>> change. What do we get over just the prev_hash by doing this?
>With the existing setup (sans height in coinbase), you might not have
>unique transactions, with all that entails.

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?

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 at lists.sourceforge.net

More information about the bitcoin-dev mailing list