-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
are all nodes aware of the fork before the next blockNot at all. Each node only knows what it has. From a node's point of view, there is no way to know about a fork until a subsequent block arrives which does not link to the tipThe block header contains the hash of the previous block's header. This links all blocks together in a chainSay there was a tied mining race. Some nodes have block A at height x, some have block B at height x. At the mining level, miners' nodes are no different to the rest of the node network. Some will have block A, some will have block B. Only one miner wins (assuming there isn't another tied race). That miner's new block (block C at height x+1) links to either A or B, depending on which side of the fork the miner's node was. The miner propagates his winning block to his neighbor nodesIf block C follows B (C prev_block_hash is the hash of the B header), this makes B the longer chain. Block A is on the shorter chain, so it is now stale (not orphaned, orphaned has a different meaning). The nodes which were following block A need to perform a chain tip reorg. They ask their neighbors if they have block B, because now they know there's probably a fork, and they know the B header hash. The node downloads B from whichever node responds "I have" first, and discards AIs there a message of send me all blocks after this height that nodes can communicate to each other?There might be, but I think the mechanism runs one block at a time, backwards from the tip51% attacks and how creating a fork 'silently' and then broadcasting it to the networkTwo thingsA 51% attack forges a tied mining race, which triggers a chain tip reorgAlthough most tied mining races only need to reorg a 1-block tip, occasionally a reorg can be 2 blocks (2 tied races in a row), and even less often, sometimes a reorg can be re-reorged back to the previous tip. The reorg logic has no depth limitBecause there's no depth limit, an attacker can mine an arbitrarily long replacement chain tip secretly in parallel, for as long as he has 51% hash power availableReplacing a long tip only requires broadcasting the most recent replacement block. This will have a prev_block_hash matching its own previous block, so the reorging nodes will ask for that block, and so on for the entire length of the attacker's chain tipAntonopoulos has a diagramhttps://github.com/bitcoinbook/bitcoinbook/blob/develop/ch10.asciidocSearch down to "Blockchain Forks"An orphaned block is one which arrives before its predecessor, has a x+2 block height. That's a simple network latency quirk, doesn't require a reorg, only requires waiting for the x+1 block3ReplyGive AwardShareReportSaveFollow