Bitcoin Forum
December 10, 2016, 09:22:18 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: BIP 34 : block height in the coinbase  (Read 2837 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 10, 2012, 01:29:10 PM
 #1

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).

How often do you get the chance to work on a potentially world-changing project?
1481361738
Hero Member
*
Offline Offline

Posts: 1481361738

View Profile Personal Message (Offline)

Ignore
1481361738
Reply with quote  #2

1481361738
Report to moderator
1481361738
Hero Member
*
Offline Offline

Posts: 1481361738

View Profile Personal Message (Offline)

Ignore
1481361738
Reply with quote  #2

1481361738
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481361738
Hero Member
*
Offline Offline

Posts: 1481361738

View Profile Personal Message (Offline)

Ignore
1481361738
Reply with quote  #2

1481361738
Report to moderator
MatthewLM
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
July 10, 2012, 08:29:53 PM
 #2

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?

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
July 10, 2012, 08:50:47 PM
 #3

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?
Transactions are valid independent of any block. BIP30 already rejects duplicate coinbases, but that (not this) is the hack.

gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2030



View Profile
July 10, 2012, 08:55:21 PM
 #4

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

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.

Quote
Why doesn't the client just identify transactions by a mixture of the transaction hash and the parent block

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.

Quote
(Hence removing the bug with no need for a hack)

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.

Quote
and why not get the majority of miners to reject blocks with duplicate coinbases to prevent a blockchain fork?

(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).
MatthewLM
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
July 10, 2012, 08:58:09 PM
 #5

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

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
July 10, 2012, 09:02:29 PM
 #6

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.
But the coinbase is the input...

gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2030



View Profile
July 10, 2012, 09:03:18 PM
 #7

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.
But the coinbase is the input...

Well, another input.  I suppose you're right though.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
July 13, 2012, 11:49:51 PM
 #8

Suggested fix: Include the block number in the coinbase.

Nice to see my suggestion being implemented finally.

ByteCoin
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!