Bitcoin Forum

Hi, I wanted to know how far a fork goes when it happens... is it single transactions, tens of them, hundreds?
I need this for my own proof of concept blockchain project to optimize rollbacks.

Surely it last until all miners realise that anything they add to the fork will result in the loss of the work done.

Unless they decide to make it permanent as an altcoin. :)

The question is weird by nature and cannot be answered in this sense. So essentially what you have now is Chain A (currently used) and controversial fork (let's call it Satoshi Reloaded). Satoshi reloaded required 70% of the miners in order to successfully fork. In the case that it gathers the necessary support the following happens: Chain A splits at one point in time into Chain A (the "old" one) and Chain B (the fork). Essentially there is no exact amount of time that the fork last. As long as there are people who run it, it will stay "alive" (e.g. take a look at any altcoin as they are forks).

as long as there is at least someone supporting it by mining the block, and getting the reward, it can last forever, it's all about support

if none is mining it anymore then you cna consider it technically dead

Maybe here are some stats on that:

https://bitcointalk.org/index.php?topic=1403436.0

hi, I meant a fork when transactions collide and orphans are created in the end

not sure where lauda is getting these numbers from but a fork can happen at any percentage.

a consensus fork however needs a majority. (much debate about what magic number that should be classed as majority, lauda himself naively thought 95% was the magic number. now it seems 70% is acceptable.. so take it with a pinch of salt).

but to get to the route of the question.

a fork can happen for a variety of reasons, bugs, differing implementations, a dodgy transaction/block that strangely goes unnoticed.

if its a feature that the majority want(consensus). the fork may never be fixed because its desire of the people to carry on this variant because it offers new features, such as segwit, weakblocks, etc.

if however it was a bug. it depends how disastrous it was and how many are affected. we have had a few bugs recognized and fixed quite quickly in the past, but it is also dependent on how fast full node users update their versions of bitcoin to have the bugfix.

in the past it has been a few hours. not weeks or a year. but the exact timescale is unpredictable because without knowing the cause, no one knows how long it would take to make a fix and release a updated implementation.

but one thing is for sure it does not take a year to get people to update their implementations, especially when a fork is involved

if its just a dogdy tx/block the eventual orphans can be upto an hour(worse case odds) (https://blockchain.info/charts/n-orphaned-blocks). but most of the time ~10 minutes because the next block would most likely be solved by a different pool and pick-up on the problem. worse case a bad pool may solve 6 blocks in a row or a couple pools acting together badly may look passed the error until a good pool solves a block and picks up on the error

Depends on the network speed.
 
It's just all probability, but its in the best interest of all miners to switch fast.

There is already protocols implemented to switch automatically to the long chain.

So if the network speed is fast, it should not last ideally longer than 10-20 min.

Until one the chains become longer than other. If more than half of the hashrate are on chain A, they will produce more blocks than chain B and once they take over B, the B will vanish.

I don't understand what you want to ask. TX "collision", orphans and forks can be very different and individual events. Nobody can give you a fixed answer anyways, as it depends on a lot of factors.

Transactions don't "collide" and orphaned blocks are created every time a block is abandoned. Orphaned transactions aren't a term that is typically used, and therefore doesn't have a well defined meaning.

It really sounds like you don't have a good understanding about how bitcoin works, and therefore are headed down the wrong path of thought.  You are asking questions that don't make much sense and that are therefore difficult to answer (What does the color blue taste like? How many miles is it from here to yesterday?)

Each block has a reference in its header that indicates which block is the block immediately before it.  This is how the blocks are "chained".  Typically (when there isn't a fork) a valid block is broadcast by a miner that references the most recent previous block that nearly everyone has on their blockchain.  All full nodes receive this new block, validate it, and then add it to their own blockchain and relay it to all their peers.  As miners receive this new block and add it to their chain, they begin working on a new block that references this new block as the "previous" block.

A "fork" happens when two different blocks are both built referencing the same previous block.  If some of the network receives one of these blocks and some of the network receives the other block, then the network has "forked" into two slightly different blockchains (this happens nearly every day).  Depending on the reason that this fork has occurred, it may clear up with the very next block (this is what happens most of the time). That typically happens when two different miners each solve a block within a second of each other. It's also possible for the fork to be permanent if each segment of the network decides that it wants to keep its fork and ignore the other one (this is what would happen with a "contentious hard fork").  A fork can also happen if a new version of full node software has a bug in it.  Typically these have been resolved within a few hours.

When a forks happen, it is possible that multiple different transactions that share an input end up with one in each branch.  The branch that ends up "winning" is the one that will have the "real" transaction, the rest of the conflicting transactions will simply cease to exist.  If your node is on a losing branch and eventually switches over to the winning branch, it's possible that you'll see a transaction as confirmed on your losing branch and then suddenly see it disappear when you switch over to the winning branch.  It's also possible that you'll see a transaction as unconfirmed, and then see it disappear when you receive the block that puts you on the losing branch, then later see it come back as confirmed when you switch over to the winning branch.

When a forks happen, it is possible that a transaction is confirmed in some of branches, but not other branches. The branch that ends up "winning" will eventually be the true indicator of whether or not the transaction is confirmed. If your node is on a losing branch and eventually switches over to the winning branch, it's possible that you'll see a transaction as confirmed on your losing branch and then suddenly see it unconfirmed when you switch over to the winning branch.  It's also possible that you see a transaction as unconfirmed on your losing branch, and then suddenly see it with multiple confirmations when you switch over to the winning branch.

Forks aren't measured in numbers of transactions, they are measured in numbers of blocks.  A block can have 1 transaction in it, or it can have a megabyte of transactions in it (or any amount in between).  So it is entirely possible for a 1 block fork to only be a 1 transaction fork, but it's also possible for a 1 block fork to be a 3000 transaction fork.  It's even possible that one branch of a 1 block fork has 1 transaction, and the other branch to have 3000 transactions.

Thanks, transaction and block are synonymous in my project, so I really wanted to ask how many blocks it lasts.
I see that the answer is "depends" and "nobody knows" or "eventually"