Difference between revisions of "Orphan Block"
Todd Price (talk | contribs) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | An "orphan block" is a well-formed block with valid proof of work which has been rejected by Miners and does not form part of the longest chain of proof of work. As the block in question has not been accepted, the | + | An "orphan block" is a well-formed block with valid proof of work which has been rejected by Miners and does not form part of the longest chain of proof of work. As the block in question has not been accepted, the [[Block Reward]] and the [[transaction fees]] are no longer spendable on the difficulty wise-longest well-formed [[Blockchain]]. This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional". |
An orphan block often originates when two [[Mining|Miners]] produce a block around the same point in time. The time delay in propagating and accepting a block leads to Bitcoin SV nodes encountering scenarios where they need to select which of multiple blocks to accept as the most legitimate to include next in the chain. After a block is selected by the network, the other block is considered an orphaned block. Transactions in the orphaned block that were not included in the successful block, are re-included into the mempool as membership candidates for future blocks. In most cases the vast majority of transactions will be included in both, as propagation of transactions across the network is very efficient and both Miners are likely to have seen the same set. | An orphan block often originates when two [[Mining|Miners]] produce a block around the same point in time. The time delay in propagating and accepting a block leads to Bitcoin SV nodes encountering scenarios where they need to select which of multiple blocks to accept as the most legitimate to include next in the chain. After a block is selected by the network, the other block is considered an orphaned block. Transactions in the orphaned block that were not included in the successful block, are re-included into the mempool as membership candidates for future blocks. In most cases the vast majority of transactions will be included in both, as propagation of transactions across the network is very efficient and both Miners are likely to have seen the same set. | ||
| − | In other instances, orphan blocks may be generated when malicious nodes seek to reverse transactions by generating alternative desired blocks. This, they hope to accomplish through the utilisation of large amounts of hash power (see [[ | + | In other instances, orphan blocks may be generated when malicious nodes seek to reverse transactions by generating alternative desired blocks. This, they hope to accomplish through the utilisation of large amounts of hash power (see [[51% attack]]). However, attacks intended to cause the deliberate orphaning of blocks are extremely resource-intensive and are largely infeasible. The blocks they generate generally end up being orphaned themselves. |
==See Also== | ==See Also== | ||
* [[Miner subsidy]] | * [[Miner subsidy]] | ||
Latest revision as of 03:06, 21 April 2022
An "orphan block" is a well-formed block with valid proof of work which has been rejected by Miners and does not form part of the longest chain of proof of work. As the block in question has not been accepted, the Block Reward and the transaction fees are no longer spendable on the difficulty wise-longest well-formed Blockchain. This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".
An orphan block often originates when two Miners produce a block around the same point in time. The time delay in propagating and accepting a block leads to Bitcoin SV nodes encountering scenarios where they need to select which of multiple blocks to accept as the most legitimate to include next in the chain. After a block is selected by the network, the other block is considered an orphaned block. Transactions in the orphaned block that were not included in the successful block, are re-included into the mempool as membership candidates for future blocks. In most cases the vast majority of transactions will be included in both, as propagation of transactions across the network is very efficient and both Miners are likely to have seen the same set.
In other instances, orphan blocks may be generated when malicious nodes seek to reverse transactions by generating alternative desired blocks. This, they hope to accomplish through the utilisation of large amounts of hash power (see 51% attack). However, attacks intended to cause the deliberate orphaning of blocks are extremely resource-intensive and are largely infeasible. The blocks they generate generally end up being orphaned themselves.