Topic: what causes forking? (Read 852 times)

That depends on how the change is written.


Yes.

Makes sense, thanks. I guess it's a matter of learning the software for the specifics.

Would a change to block acception/rejection for a prior period of block history cause a fork? Does the block history get checked for validity by the client when first downloaded?

I feel myself absolutly noob here

Yeah, this is what we get when we call transaction validation as mining. Now everyone wants a shovel so they can mine.

Why wasn't it called "proofing" or "processing" or "verifying" or "validating" or something else ... When I think about it, "proofing" would have made more sense, since we are checking the proof of work.

It's called orphan because the biggest pool software MPOS uses it that way; and all the pools use this code or a derivative of it. I'm not sure, but maybe p2pool also uses the same word.

So, now everyone is using that word ... so new people think, "wtf is mining?" ... then the first thing they see are pictures of half a dozen graphic cards immersed in oil, even though that is outdated for bitcoin.

There is some terminology confusion between the Bitcoin community on Bitcointalk and the Bitcoin Core implementation.

In the satoshi codebase there is something called an "orphan block" which is quite literally a block which doesn't have a parent— the previous block is not known the the node yet.

The reason that a block which isn't in the longest chain— I'd call it a stale, abandoned, or extinct block— is called "orphan" by the community is because the generated transaction of a stale block displays "orphaned" in the transaction list. But here it's pedantically correct: The generated transaction has no parent in the blockchain, because the block that created it is not in the blockchain.  The transaction list is the only way many miners bothered looking at blocks (instead of things like the debug.log or the source code, which call parent-less blocks orphans), and so they naturally started calling the stale blocks orphans.

Changing an enshrined practice is usually a lost cause, but the word orphan still causes confusion: it's still applied to blocks without a parent, and its the most intuitive term in that case. So I recommend using one of stale, abandoned, or extinct when referring to blocks that didn't make it into the longest chain though I don't begrudge people using the word orphan here too other than by noting the potential for confusion.

A fork is a split in the road. Same analogy in bitcoin. The blockchain is supposed to be a long and winding road.

Every now and then, there is a fork, an alternative path, that some clients / wallets / miners / pools take. Eventually, they realize it doesn't really lead them to where they should be, so they go back ... any new "road" gets left behind, it becomes an "orphan".

Orphans don't have parents, but in bitcoin, it just means it's a block that doesn't get included in the main or biggest chain, even though it is valid, because it got left behind by everyone else.

Any change that results in accepting blocks or transactions that the current software considers to be invalid would cause a fork in the blockchain if used by miners.

Any change that results in rejecting blocks or transactions that the current software considers to be valid would cause a fork in the blockchain if used by miners.

Can someone please explain exactly what kind of code changes cause a fork with the new client version and which ones don't? Is there a reliable test to show whether the new version has forked? Is there some literature on this that I could search for?