Our only URLs are

All other sites are scams – especially be wary of:

benumbs.cards & bennumb.cards & bennumbs.cards & benumb.cc & many more…

(it can be hard to notice the S and extra N if not careful.) 

Welcome to the real deal. 

Please bookmark this link — the other sites have simply copy/pasted our html and don’t actually have any cards to sell. 

They can be easy to fall for if you aren’t cautious!

Technical query on fork decision

Hi there,

When a fork occurs, are all nodes conscious of the fork earlier than the following block or is there a risk {that a} fork is occurring and a few nodes aren’t conscious of it ?

If there’s a risk of it occurring, how do nodes on the orphaned block get the knowledge of all different blocks on the opposite fork. To my understanding they’ll get a brand new block with a better top, and can select to observe it, nonetheless they don’t have the earlier blocks to validate the block they obtained. Is there a message of ship me all blocks after this top that nodes can talk to one another ?

Sorry if it isn’t clear or if does not make sense, I’m additionally attempting to grasp 51% assaults and the way making a fork ‘silently’ after which broadcasting it to the community can work.

7 thoughts on “Technical query on fork decision”

  1. WassaWassaWassup! Scam Alert! Scammers are particularly active on this sub. They operate via private messages and private chat. If you receive private messages, be extremely careful. Use the **report** link to report any suspicious private message to Reddit.

    *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/BitcoinBeginners) if you have any questions or concerns.*

    Reply
  2. there are a couple questions / threads here, so i’ll try my best to help with each of them.

    when folks talk about forks, they are usually referring to something intentional (usually as a means of changing/upgrading the behavior of the actual bitcoin protocol). forking this way usually involves politics and a majority of miners (by hash rate), in conjunction with developers, agreeing on the changes and planning on which block they will switch over to using the new protocol/software. generally miners and wallet software / data providers will keep up with any planned changes. it’s possible some nodes will be unaware, but this doesn’t usually have a major effect since orgs that find bitcoin mission critical will stay on top of goings-on.

    sometimes changes are contentious, and a subset of miners will choose to create their own fork and break from the main chain (like bitcoin cash did).

    regarding orphaned blocks:
    i haven’t analyzed lately, but they do happen. you are correct that the node will receive a block header from a peer with a larger height. you are also correct in guessing that nodes will ask each other for blocks they are missing + validate. this correction process is called a reorg.

    51% and “silent” mining:
    since a node will perform a reorg when it sees a block with larger height + can verify the data/chain, the largest valid chain will always be accepted. if you had alien technology that instantly mined blocks, you could take advantage of this. say you receive a bitcoin in block 10, then buy a car with it on block 20 (let’s say the car seller waits for 5 confirmations, so until block 25). if your machine instantly mines blocks, you could mine/ blocks 19-40 (so that you are ahead of the other miners), then publish them and rewrite that portion of history. in those blocks that you mined you could have excluded the car payment transaction and included your own transaction (sending the money to yourself) that invalidates the car payment transaction. in this scenario, you wouldn’t try to broadcast block 19 immediately, you’d be silent until your chain was long enough to sufficiently overtake the current one (when you get to block 40).

    Reply
  3. Usually all nodes (validating nodes) know about all blocks, including the two competing heads.
    They keep both blocks, but choose one to consider valid (probably the one that came in first).

    However, if a node fell behind for any reason, it can catch-up by downloading from peers.

    Reply
  4. > are all nodes aware of the fork before the next block

    Not 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 tip

    The block header contains the hash of the previous block’s header. This links all blocks together in a chain

    Say 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 nodes

    If 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 A

    > Is 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 tip

    > 51% attacks and how creating a fork ‘silently’ and then broadcasting it to the network

    Two things

    * A 51% attack forges a tied mining race, which triggers a chain tip reorg
    * Although 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 limit

    Because 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 available

    Replacing 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 tip

    Antonopoulos has a diagram
    https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch10.asciidoc
    Search 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 block

    Reply
  5. Great question.

    This isn’t actually a fork though. This is a chain split which is not the same thing.

    A fork is a change in the consensus rules. Hard forks are not backwards compatible while soft forks ARE backwards compatible.

    This is neither. This is a temporary chain split that results in a very small block reorg. In extreme cases, it could result in a relatively large block reorg.

    Nodes are completely unaware of anything that has not been related to them. All they know of what they “hear” via the gossip protocol from other nodes.

    When one of these 2 competing chains is longer than the other, nodes will relay the new block height and the shorter chain will simply update their record of the blockchain to achieve Nakamoto consensus (https://www.whatisbitcoin.com/nakamoto-consensus).

    It’s absolutely possible to work on a different version of the blockchain in private and then broadcast it after I have a longer chain. It just requires more hashpower than the existing chain. If I have a longer proof of work chain that I built privately, I can broadcast it to the nodes and they will check everything. If it is all valid, nodes will drop the old record and use my record and I will have successful done a block reorg. This might help explain things in greater detail: https://www.whatisbitcoin.com/51-attack

    It’s important to understand that the further back you attempt to reorg the blockchain and “erase” transactions, the more expensive it becomes. That’s why the more confirmations a transactions has, the more secure it is considered to be.

    Does that all make sense?

    Reply
  6. When a fork happens, all nodes are aware of it and will choose which fork to follow based on their individual protocols. The nodes on the shorter fork will stop adding blocks to that fork and will switch to the longer fork, which is considered to be the correct version of the blockchain.
    To ensure that the longest fork is always considered to be the correct version of the blockchain, nodes will only accept new blocks that build on top of the longest chain of blocks that they are aware of. This means that in order for an attacker to “silently” create a fork and then broadcast it to the network, they would need to have more than 50% of the network’s mining power in order to mine blocks faster than the rest of the network and extend their fork to become the longest chain. This type of attack is known as a 51% attack, and it is a significant concern for blockchain networks because it can allow an attacker to double-spend their own transactions and potentially cause other forms of disruption.

    Reply

Leave a Comment