Topic: BIP 34 : block height in the coinbase (Read 3514 times)

Nice to see my suggestion being implemented finally.

ByteCoin

Well, another input.  I suppose you're right though.

But the coinbase is the input...

OK gmaxwell. What you say makes reasonable sense to me.

It makes the duplication ~impossible (save getting a hash collision). There was not previously a behavior where two coinbase transactions became invalid, rather one could replace another— though that is prevented by BIP30.


Because transaction exist externally to and independently of blocks. Even if you were willing to create software which only worked with confirmed transactions (e.g. not a full node) you'd still have crazy issues with transaction IDs changing when the chain reorginizes which could itself create some awesome exploits against merchant software.


Including the height as part of the hash for the coinbase transaction is something Bitcoin should have always done. Although it should have been listed as the 'input' rather than putting it in the coinbase, but sadly the former can't be done compatibly.


(As of BIP30) We reject duplication which would overwrite an existing unspent transaction, because that in and of itself creates some really nasty and critical attacks, but we can't explicitly prevent duplication of already spent transaction in the general case without making pruning impossible.  (If you have to remember every txn ID that ever was in order to refuse to mine duplicates you can't forget spent transactions).

Including the height in the coinbase implicitly prevents duplication by making it infesable but doesn't require unbounded storage like explicit prevention.  It also allows nodes software to be more DOS attack resistant because it would allow additional filtering prior to connecting. This is described in some of the links gavin provided.

BIP30 was an emergency fix for a severe vulnerability, deployed because the real fix couldn't be deployed quickly.  This change fixes the underlying protocol design flaw and fixes up some of the less critiial corner cases the other fix couldn't really address (e.g. the prospect of having to deal with duplicate transaction IDs for distinct transactions).

Transactions are valid independent of any block. BIP30 already rejects duplicate coinbases, but that (not this) is the hack.

So this is to fix duplicate coinbase transactions potentially causing two coinbase transactions becoming invalid?

Why doesn't the client just identify transactions by a mixture of the transaction hash and the parent block (Hence removing the bug with no need for a hack) and why not get the majority of miners to reject blocks with duplicate coinbases to prevent a blockchain fork?

In case you don't subscribe to the bitcoin-development mailing list, we've been talking about a new BIP:

"Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2."

Full BIP: https://en.bitcoin.it/wiki/BIP_0034
Mailing list discussion:  http://sourceforge.net/mailarchive/message.php?msg_id=29505990
Pull request that implements BIP 34: https://github.com/bitcoin/bitcoin/pull/1526
BIP16 "Lessons learned" : https://gist.github.com/2355445

I'd like to keep most discussion on the bitcoin-development mailing and not here on the forums, although I do plan on posting to one of the mining boards to warn solo miners and pool operators that they will eventually need to upgrade (I expect it will take at least a year and probably two or more for 95% of hashing power to upgrade, which is the proposed timeframe for full BIP 34 support).