|
|
|
@ -167,10 +167,14 @@ Although a single block will always have a specific and invariant block
|
|
|
|
|
height, the reverse is not true—the block height does not always
|
|
|
|
|
identify a single block. Two or more blocks might have the same block
|
|
|
|
|
height, competing for the same position in the blockchain. This scenario
|
|
|
|
|
is discussed in detail in the section <<forks>>. The block height is
|
|
|
|
|
also not a part of the block's data structure; it is not stored within
|
|
|
|
|
the block. Each node dynamically identifies a block's position (height)
|
|
|
|
|
in the blockchain when it is received from the Bitcoin network. The
|
|
|
|
|
is discussed in detail in the section <<forks>>. In early blocks, the block height was
|
|
|
|
|
also not a part of the block's data structure; it was not stored within
|
|
|
|
|
the block. Each node dynamically identified a block's position (height)
|
|
|
|
|
in the blockchain when it was received from the Bitcoin network. A
|
|
|
|
|
later protocol change (BIP34) began including the block height in the
|
|
|
|
|
coinbase transaction, although it's purpose was to ensure each block had
|
|
|
|
|
a different coinbase transaction. Nodes still need to dynamically
|
|
|
|
|
identify a block's height in order to validate the coinbase field. The
|
|
|
|
|
block height might also be stored as metadata in an indexed database
|
|
|
|
|
table for faster retrieval.
|
|
|
|
|
|
|
|
|
|