We’re rewarding the question askers & reputations are being recalculated! Read more.
12

There are two problems with this: The "longest" block chain is selected not by total number of blocks, but by total difficulty. A chain with a large number of low-difficulty blocks would not win. The Bitcoin reference client hard-codes the hashes of a relatively recent block as a "checkpoint" and will reject any chain not containing that block at the ...


11

Your assumptions are perfectly right. Since there is no information exchange between the two partitions while the network is partitioned, and Bitcoin guarantees liveness, the global consistency suffers (see CAP Theorem). This means that each partition will have its own blockchain fork, unaware of each other. The forks are incompatible not just because the ...


10

Immature coins are coins that were created in a block reward and haven't aged sufficiently, yet. The problem with block rewards is that they could still disappear again, if the generating block ends up being invalidated by a competing block chain. In order to minimize the confusion and subsequent problems from someone spending coins that end up disappearing ...


8

As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization. ...


7

Background info: Strongest vs Longest chain and orphaned blocks How does a client decide which is the longest block chain if there is a fork? Where exactly is the "off-by-one" difficulty bug? (timewarp info) A shorter chain could possibly be considered the correct one, but it would be very hard to make this happen in bitcoin. I can think of two ...


6

An attacker has a hard time changing the past An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating. Example: Say, Eve achieved to control 51% of the hash rate and wants to unconfirm a transaction from 6 ...


5

Will it be included in one of blocks E, F, G or another block? It's likely already included in one of those blocks. If not, it can be included in a block after that. Do I need to resend it? Probably not. If block D or Tx4 was widely seen by the network, it should get into a block soon. (It might already be in blocks E, F, or G.) If yes, can I spend ...


4

When a previously unknown chain fork of at least 7 blocks length is published, how does Bitcoin Core react? It reorganizes to that chain, any transactions that were lost are returned to the nodes mempool. Would Bitcoin Core accept the chain fork if it had the most work? Any valid chain with the most work will be reorganised to. How prominent is the ...


4

Random reorganizations of length more than 1 are rare. To get a fork of length 1, you need two miners find a winning nonce at nearly the same time. To get a fork of length 2, you need the same (1) happen right after a fork of length 1 and (2) have those miners mine on different sides of the fork. However, such fork happen once in a while. See this answer ...


4

'Longer' means 'more total work spent'. You're not going to be working harder than all miners put together are you? Then the only way to get some money is to join the existing miners and work with them. And by doing that you coincidentally enlarge the group of 'honest' miners, making it that much harder for someone else to consider your 'evil' plan.


4

Stale and orphan blocks are confusing terms with many meanings, depending on whom you ask. If by stale blocks you mean "blocks that are on branches off the main chain, but are otherwise valid", yes, those still exist. They are inherent to proof-of-work chains, as you can't avoid the case where occasionally two miners produce a competing block. Necessarily, ...


3

You can use the rawblock interface in order to determine whether there was a reorg. Every time you receive a new block, you decode the block, in particular the block header. Then you store in your database each block and its previous block. When you receive a block which shares the same previous block as another block that you have already received, then ...


3

Nate gave a good answer on the modern meaning of "longest chain"-- as a historical curiosity, the originally released Bitcoin software behaved like you were expecting and that attack would actually work! It was later changed to determine "longest" in terms of work. This seems like a pretty big mistake, but for Bitcoin's first year the difficulty was ...


3

I think it's conceivable that this could happen. But under realistic cases, I don't think it actually will. If you don't mine on the longest block, the probability that your block will ever be part of the longest block drops drastically. Unless a block you mine becomes part of the longest chain and stays that way, you never get any fees or reward at all.


2

The answer is simple: if a country blocks off external internet access, its inhabitants effectively cannot use Bitcoin while the country is blocked. Sure, the protocol will continue with a fork ... but this fork has no hopes of ever "reconnecting" with the main blockchain, so any blocks generated / signed in the fork are useless. The country will have ...


2

Depending on what you meant to ask, the answer is one of the following: If you run a Bitcoin-qt fork which is incompatible with the rest of the network, you're running a separate currency which has no value (because no one else accepts it). If you ignore blocks and forge historic timestamps to create a branch with more blocks of low difficulty, it will not ...


2

When a node learns of a transaction, some validity tests are performed and if the transaction is not yet in the blockchain it knows of with the longest height and the transaction also is valid (i.e., not a double spend) then that transaction is added to that node's memory pool. If a later transaction arrives at a node but is an attempt to double spending of ...


2

I know you're looking for some magic constant, but it doesn't exist. Your code needs to deal with reorgs of any depth back to the genesis block. This may seem like a annoyance of dealing with the block chain, but it's how payments have always worked. Even if some guy pays you with a suitcase full of verified gold bars, a court order can compel you to ...


2

First to clarify: Two competing blocks at the same height that build on the same parent block always have the same amount of proof of work, as that depends on the difficulty, which will be the same for both competitors. Thus, a chain reorganization will only occur in practice if a competing chain tip pulls ahead of a previously accepted chain tip by ...


2

It looks like this part of the code is what was adding all those UpdateTip messages: https://github.com/bitcoin/bitcoin/blob/8fe30fb4d130532d4a0e4c9d143f03e1b85a749e/src/main.cpp#L2234 Essentially, bitcoind thinks another chain with more cumulative work exists on your 4-node network, though from the logs, it's hard to tell how much lower it goes. You'll ...


2

Each of the blockchain forks assumes itself to be the only valid blockchain. They do not change their behavior due to a competing chain. They will require checks and confirm transactions completely independently from each other. It is likely that the same transactions are confirmed in both competing chains, just in different order and perhaps also at ...


2

A contentious hardfork (where some portion of the network doesn't agree to modify their consensus rules) is effectively a doomsday scenario, there's no making this safe or making tools which allow you to transact on two chains simultaneously with no ill effect. This almost happened once before, and the miners picked the fork that solved the problem (a ...


2

As long as everyone follows the same rules, mining is convergent, because the expected interval of ten minutes allows every full node to catch up to the current state of the network. Separate p2p networks (altcoins) derive from a different set of rules, where one of the rules is the Genesis block of the blockchain. Since their Genesis block is different and ...


2

Your node doesn't know for sure. Actually, nobody ever knows for sure that the current chain-tip will be in the chain with the most work, it just becomes increasingly likely as more time passes and additional blocks build on-top. Once a sufficient number of blocks have been built on top of the observed block, it will be sufficiently unlikely that the ...


2

Every Bitcoin node creates it's own blockchain. When a new block is found, it is broadcasted to the network. Other nodes will only consider the highest blockchain as being the "real" blockchain. Sometimes, two separate nodes build a block containing different transactions. Two competing blockchains now exist, it is now a race for the next block. Once the ...


2

The blockhash is a hash that includes the previousblockhash as input. Suppose you are trying to change the data in block 9000. You modify it the way you like and then successfully mine the modified block (find a hash that meets the difficulty threshold at that height). You now have a block 9000 with a new hash, so block 9001 has the wrong value in ...


2

If ‘block finalization’ is needed, then your chain is broken. I say this because PoW is the method by which the Bitcoin network maintains consensus, and so the only reason we may introduce a ‘block finalization’ is if we worry that PoW will not be able to accomplish it’s job. If PoW cannot accomplish its job, then the system is already broken. It really is ...


2

What you are referring to are stale blocks. Orphaned blocks are one for which the previous (parent) hash field points to an unknown block or to a block not yet processed by the local node. Since Bitcoin Core follows headers first approach, block headers are downloaded and validated first before downloading the block data. As a result, full nodes will never ...


2

valid-fork means that the blocks were fully downloaded and validated. It is likely that they were part of the active chain but were reorganized after a better chain was received. valid-headers means that the blocks were fully downloaded but not fully validated. Only the headers were validated to have a valid Proof of Work before the block was written to ...


1

I think the answer is the same as when you're receiving a Bitcoin transaction and you want to be "certain" that the coins are now actually yours and can't be double spent anymore: you wait for multiple confirmations (the whitepaper says 6). In situations where you can't afford to wait (like mining) you'll just have to make a gamble and be ready to change ...


Only top voted, non community-wiki answers of a minimum length are eligible