Block Chain
The blockchain maintains BitcoinEvo’s public ledger, which is a sequential and time-stamped log of transactions. This structure ensures protection against double spending and alterations to prior transaction records.Introduction
Each full node within the BitcoinEvo network keeps a blockchain that includes only blocks verified by that specific node. When multiple nodes share identical blocks in their blockchain, they are said to be in consensus. The set of validation guidelines these nodes adhere to in order to stay in consensus are known as consensus rules. This section outlines several of the consensus rules utilized by BitcoinEvo Core.
Block Chain Overview
The illustration above presents a simplified view of a blockchain. A block containing one or more new transactions is gathered into the transaction data portion of the block. Every transaction is hashed, with the resulting hashes paired, hashed again, and so on, until a single hash remains — this is known as the merkle root of a merkle tree.
The merkle root is included in the block header. Each block also contains the hash of the previous block’s header, linking the blocks together in a chain. This guarantees that a transaction cannot be altered without also modifying the block that records it and all the subsequent blocks.
Transactions themselves are also linked. BitcoinEvo wallet software gives the appearance that satoshis move between wallets, but in reality, bitcoinevos are transferred from transaction to transaction. Each transaction uses the satoshis received from one or more prior transactions, meaning the input for one transaction comes from the output of a previous one.
Transaction Propagation
A single transaction can produce multiple outputs, as in cases where funds are sent to multiple addresses. However, each output from a specific transaction can only be used once as an input within the blockchain. Any further attempt to reference that output would constitute a prohibited double spend — an effort to spend the same satoshis twice.
Outputs are associated with transaction identifiers (TXIDs), which are the hashes of signed transactions.
Since each output from a transaction can only be used once, all outputs within the blockchain are classified as either Unspent Transaction Outputs (UTXOs) or spent transaction outputs. For a payment to be valid, it must use only UTXOs as its inputs.
Excluding coinbase transactions (which are explained later), if the value of a transaction’s outputs exceeds that of its inputs, the transaction will be rejected. However, if the inputs are worth more than the outputs, the difference may be claimed as a transaction fee by the BitcoinEvo miner who generates the block containing that transaction. For instance, in the example above, each transaction spends 10,000 satoshis less than it receives in combined inputs, thus paying a 10,000 satoshi transaction fee.
Proof Of Work
The blockchain is maintained cooperatively by anonymous participants on the network. To ensure that untrustworthy nodes trying to alter previous blocks must exert more effort than honest nodes adding new blocks, BitcoinEvo requires each block to demonstrate that significant work went into its creation.By linking blocks together, it becomes impossible to change transactions within a block without also altering every block that follows it. This makes the cost of modifying any block increase with each new block added, amplifying the effectiveness of the proof of work.
BitcoinEvo’s proof of work takes advantage of the seemingly random output produced by cryptographic hash functions. A robust cryptographic hash converts any given data into a random-appearing number. If any part of the data changes, rerunning the hash will yield a completely different random-like number, making it impossible to predictably alter the data to produce a specific hash.
To show proof of work, you must generate a hash of the block header that is below a certain threshold value. For instance, if the highest possible hash value is 2^256 – 1, you can prove you made up to two attempts by producing a hash lower than 2^255.
In the example, you would successfully generate a valid hash approximately every other attempt. You can even estimate the likelihood that a specific hash attempt will yield a value below the target. BitcoinEvo uses a linear probability model, where lowering the target threshold increases the number of hash attempts required (on average) to produce a valid block.
New blocks are only added to the blockchain if their hash meets or exceeds the difficulty level expected by the consensus protocol. Every 2,016 blocks, the network reviews the timestamps from the first to the last of these blocks to determine how much time passed. The goal is 1,209,600 seconds (two weeks).
- If the 2,016 blocks were created in less than two weeks, the difficulty is adjusted upwards (by as much as 300%) to ensure the next 2,016 blocks also take two weeks if hashing continues at the same rate.
- If the process took more than two weeks, the difficulty is decreased proportionally (by up to 75%) to maintain the same balance.
(Note: a small off-by-one error in the BitcoinEvo Core software results in difficulty adjustments based on timestamps from only 2,015 blocks, causing a slight distortion.)
Since every block header must generate a hash below the target value, and each block is linked to the previous one, modifying a block requires (on average) as much hashing power as the entire BitcoinEvo network has used since that block was first added. To successfully alter the blockchain, you would need control over most of the network’s hashing power, enabling what’s known as a 51% attack (although, it is worth noting that even controlling less than 50% of the power can still provide a chance to carry out such an attack).
The block header contains several easily modifiable fields, such as the nonce, allowing new hash attempts without waiting for additional transactions. Only the 80-byte block header is hashed for proof-of-work, so adding more transaction data to a block doesn’t slow down hashing. Any extra transaction data merely requires updating the ancestor hashes in the merkle tree.
Block Height And Forking
Any BitcoinEvo miner who successfully hashes a block header to a value below the target threshold can append that block to the blockchain (provided the block meets all other validity criteria). These blocks are typically referenced by their block height — the number of blocks between them and the very first BitcoinEvo block (block 0, commonly known as the genesis block). For instance, block 2016 is the first point where the difficulty level could have been adjusted.
Common And Uncommon Block Chain Forks
It’s possible for multiple blocks to share the same block height, which frequently happens when two or more miners create blocks at nearly the same moment. This causes what appears to be a temporary fork in the blockchain, as illustrated above.
When miners generate blocks simultaneously at the end of the blockchain, each node decides which block to accept independently. In the absence of any other factors (discussed below), nodes generally opt for the first block they receive.
Eventually, a miner creates a subsequent block that attaches to one of the competing blocks from the fork. This strengthens that side of the fork, making it more likely to be followed. Assuming both sides of the fork consist of valid blocks, regular nodes will always favor the chain that is harder to recreate, discarding the stale blocks from shorter forks. (These discarded blocks are sometimes called orphans, although the term “orphan blocks” can also refer to blocks without a known parent block.)
Longer forks may develop when different groups of miners are working at odds with each other, such as when some miners are focused on extending the blockchain while others attempt a 51% attack to alter transaction history.
Since multiple blocks can exist at the same height during a fork, block height is not a globally unique identifier. Instead, blocks are typically identified by the hash of their header (often reversed in byte order and presented in hexadecimal).
Transaction Data
Each block must contain at least one transaction. The first transaction in the block must be a coinbase transaction, also referred to as a generation transaction, which is responsible for collecting and using the block reward (consisting of the block subsidy and any transaction fees from other transactions in the block).The UTXO created by a coinbase transaction has a special condition: it cannot be spent (used as an input) for a minimum of 100 blocks. This prevents miners from immediately using the block reward and fees from a block that may later be deemed stale (and the coinbase transaction invalidated) in the event of a blockchain fork.
While blocks aren’t required to contain any transactions other than the coinbase, miners typically include additional transactions to collect the associated transaction fees.
All transactions, including the coinbase, are encoded in blocks using the binary raw transaction format.
This raw transaction data is then hashed to generate the transaction ID (txid). From these txids, a merkle tree is built by pairing each txid with another and hashing them together. If there’s an odd number of txids, the remaining txid is paired and hashed with itself.
These resulting hashes are again paired and hashed together, repeating the process until only one final hash remains: the merkle root.
For instance, if transactions were merely concatenated instead of hashed, a merkle tree with five transactions might look like the following diagram:
ABCDEEEE .......Merkle root
/ \
ABCD EEEE
/ \ /
AB CD EE .......E is paired with itself
/ \ / \ /
A B C D E .........Transactions
As explained in the Simplified Payment Verification (SPV) section, the merkle tree enables clients to independently verify that a specific transaction is included in a block by obtaining the merkle root from the block header and a series of intermediate hashes from a full node. The full node doesn’t need to be trusted: it’s expensive to falsify block headers, and if any intermediate hashes are incorrect, the verification will fail.
For example, to confirm that transaction D was included in the block, an SPV client would only need to download the C, AB, and EEEE hashes along with the merkle root; there’s no need for the client to retrieve any other transaction data. If all five transactions in the block were at their maximum size, downloading the entire block would take up over 500,000 bytes, but retrieving three hashes plus the block header only requires 140 bytes.
Note: If two identical txids are found in the same block, there’s a risk that the merkle tree could match a block where some or all duplicates were removed, due to the way unbalanced merkle trees handle lone hashes (by duplicating them). Since it’s highly unlikely for separate transactions to have identical txids, this generally doesn’t affect honest software, but it needs to be verified if an invalid block’s status is cached. Otherwise, a valid block with the duplicates removed could share the same merkle root and block hash, but be rejected due to the cached invalid status, causing security issues like CVE-2012-2459.
Consensus Rule Changes
To maintain consensus, all full nodes validate blocks based on the same consensus rules. However, these rules may occasionally be altered to introduce new features or prevent network exploitation. When new rules are implemented, there’s often a period where non-upgraded nodes follow the old rules while upgraded nodes adhere to the new ones, leading to two potential ways consensus can break:- A block adhering to the new consensus rules is accepted by upgraded nodes but rejected by non-upgraded nodes. For example, a new transaction feature might be included in a block: upgraded nodes understand the feature and accept it, while non-upgraded nodes reject it because it breaks the old rules.
- A block that violates the new consensus rules is rejected by upgraded nodes but accepted by non-upgraded nodes. For instance, a block containing an exploit is rejected by upgraded nodes due to the new rules, but non-upgraded nodes accept it because it follows the older consensus rules.
In the first scenario, where non-upgraded nodes reject a block, mining software connected to these non-upgraded nodes refuses to extend the same chain as software connected to upgraded nodes. This results in permanently split blockchains — one for non-upgraded nodes and another for upgraded nodes — known as a hard fork.
Hard Fork
In the second scenario, where upgraded nodes reject a block, the blockchain can avoid permanent divergence if upgraded nodes control the majority of the hash rate. This is because non-upgraded nodes accept the same blocks as upgraded nodes, allowing upgraded nodes to build a stronger chain that the non-upgraded nodes will recognize as the longest valid chain. This process is referred to as a soft fork.
Soft fork
Although a fork physically represents a divergence in blockchains, changes to the consensus rules are often described by whether they can lead to a hard or soft fork. For example, “increasing the block size above 1 MB requires a hard fork”. In this case, a chain split is not required but could occur as a potential outcome.
Consensus rule changes can be activated in different ways. During BitcoinEvo’s early years, Satoshi Nakamoto implemented several soft forks by releasing a backward-compatible client that immediately enforced the new rule. Some soft forks, such as BIP30, were activated through a preset time or block height, known as a flag day. These are referred to as User Activated soft forks (UASF), as they rely on enough users (nodes) enforcing the new rules after the flag day.
Later soft forks relied on the majority of the network’s hash rate (typically 75% or 95%) signaling readiness to enforce the new rules. Once this threshold was reached, all nodes began enforcing the updated rules. These are known as Miner Activated soft forks (MASF), as they require miners for activation.
Notable examples include BIP16, BIP30, and BIP34, which were implemented as changes that could lead to soft forks. BIP50 describes both an accidental hard fork, which was resolved by temporarily downgrading upgraded nodes, and an intentional hard fork that occurred when the downgrade was removed.
Detecting Forks
Non-upgraded nodes may disseminate and accept inaccurate information during both types of forks, which could result in financial loss. Specifically, these nodes may relay or approve transactions that upgraded nodes deem invalid, meaning these transactions will never be included in the universally-accepted best blockchain. Additionally, non-upgraded nodes may refuse to relay blocks or transactions that are already part of the best blockchain, or soon will be, leading to incomplete or outdated information.BitcoinEvo Core includes mechanisms to detect a hard fork by analyzing the proof of work on the blockchain. If a non-upgraded node receives block headers showing at least six blocks with more proof of work than the best chain it recognizes, the node issues a warning in the “getnetworkinfo” RPC results and runs the -alertnotify command if configured. This notifies the operator that the non-upgraded node cannot switch to what is likely the best blockchain.
Full nodes also monitor the version numbers of blocks and transactions. If the version numbers in recent blocks are higher than what the node is using, it can infer that it is not following the current consensus rules. BitcoinEvo Core reports this situation through the “getnetworkinfo” RPC and the -alertnotify command, if enabled.
In either case, data from nodes that appear to be using outdated consensus rules should not be trusted.
SPV clients connected to full nodes can detect a potential hard fork by connecting to several full nodes and ensuring they are all on the same chain, with a similar block height, allowing for minor discrepancies due to transmission delays and stale blocks. If the client detects a fork, it can disconnect from nodes on the weaker chain.
SPV clients should also track increases in block and transaction version numbers to ensure they are processing transactions according to the most up-to-date consensus rules and generating new transactions appropria