15

Orphan blocks (in that meaning) are not a network-wide condition. They're an implementation detail (and arguably a bug). Orphan blocks are simply blocks for which a particular node in the network doesn't have the parent yet. It doesn't mean that parent does not exist. Since Bitcoin Core 0.10, this concept simply doesn't exist anymore. They were a side ...


14

What Nicolai said is not completely right. The network would decide which one is the main chain according to the following block mined. Let's assume that block A and B are mined at almost the same time. The miners would accept the first block that was broadcast to them, so there would be some miners accept A and others accept B, it doesn't matter whether A/B ...


14

Orphaned transactions are returned to the memory pool, they are never "lost". If the TX did cease to exist from the mempools, it would just be as if they has never been sent, so again they wouldn't be lost.


10

The "longest" chain is the one with the most work. A chain's work is equal to the expected number of hashes it would take for someone to replicate a chain of the same number of blocks and the exact same difficulty steps. So currently each block adds about 266 work to the chain because it takes on average ~266 hashes to solve a block with the current ...


7

I am not sure that I can rule out that something useful could be achieved with a tree of blocks, but let me walk you through a few thoughts and you can then tell me whether they answer your question. When we're talking about Bitcoin, we should make clear what we're actually interested in achieving. We're talking about a decentralized system to track value, ...


6

Orphan rate is primarily influenced by latency but by any source of latency, not just network latency. There are many sources of latency: Network latency and serialization delay (transmission time) to communicate a block between nodes. The transmission time can be influenced by how predictable the content of the block is due to the use of efficient ...


5

So is it that a miner who mined an orphan block receives the outputs of coinbase transaction but can never spend them? Kind of. In such a case the number of bitcoins in circulation would reduce overtime due to creation of orphan blocks. No, that's not how miners are paid. Miners are essentially paid by themselves; they are allowed to produce coins out ...


5

Lots of things really, most are fairly abusive if they're a large pool though, or at least undesirable in network terms. Not including transactions in blocks. This is the obvious one, it's a lot easier to broadcast a single 25kB block than it is a bigger one. You do of course forfeit all the fees you would otherwise get, but some might see that as a ...


5

Will the miner simply ignore that block? Yes, the block will be just ignored by the miner. how will the miner update to A-B-C-D-E (step by step)? When the miner's node gets online and start connecting to peers, it will start a “handshake” by transmitting a version message, which contains all basic identifying information, including BestHeight (the ...


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, ...


4

Consensus rules are often a lot more delicate than they might first appear. Having a tie breaker can actually enable attacks. If I find a block with a really low nonce, I can gamble to keep it secret and then only when a competing block is found, I can simply neutralize it by broadcasting my low-nonce block. This makes other miners waste their time on a ...


4

Orphans are not in the chain (as seen by the processing node) because their parents are missing, stales are not in the chain because they have no children in the chain. Source: the glossary at bitcoin.org: stale blocks are: "Blocks which were successfully mined but which aren’t included on the current best block chain, likely because some other block at ...


4

Invalid transactions are never included in valid blocks. They can be included in a block, but that block would be rejected as invalid (and not classified as an orphan block).


4

A fork happens. If A and B are competing for the next block, they probably share transactions. So you cannot simply append A to B. They're both valid blocks, nodes hold both of them until they hear about a new block that was built on top of either A or B. Let's say a node hears a new block C was built on top of B, that node will then disregard A because it ...


3

An attack like this is possible, it is just a way to profit off a 51% attack. However you must remember several things: if a miner controls less than 51% of the hashpower, then chances are they will not be able to catch back up to the network after mining the malicious tx, so the honest network will prevail as the longest chain if a miner tries the attack ...


3

Two different blocks were mined at height 494676, i.e. two different blocks both naming the same previous block as their parent. One of them has a hash starting 262f and the other is 6d0d. Both of them included the 9c7b transaction. This happens normally from time to time; for instance, it could be that 262f was mined first, but it wasn't relayed to the ...


3

Update for everyone who stumbles up on this question. There is a paper that shows why it is hard to figure out the actual fork rate. it's from this paper "Echoes of the Past: Recovering Blockchain Metrics From Merged Mining" https://eprint.iacr.org/2018/1134.pdf


3

The UXTO set certainly isn't reconstructed from scratch, that would be an incredible DoS vector if it did. Even on fast machines a complete reconstruction takes hours, days on slower disks and processors. From a look at the source on github, we can see that your assumption is correct. The UXTO set is reconstructed backwards to the point where the chain is ...


3

There isn't really a "race" any more than there is a race normally. Since both chains are valid, miners can choose which block they would like to build off of. There isn't an advantage to mining on one vs the other; whichever chain you build off of, if you find a block, your block is valid. There doesn't need to be any sort of tie breaking.


3

How can i tell if the block is official / not orphaned and that it will not be replaced by a 'better' block? As Nate notes, there's no guarantee that any block will be part of the best chain in the future. Here's what you should ask: Is this block part of the highest-work valid blockchain? Here's how you determine that: you get the blocks, and connect them ...


3

Bitcoin Core includes code which rolls back a block from the chain when it is orphaned. All transactions from that block are checked against the new best block chain to see if they've already been added to a block or if they spend the same input as a transaction already added to a block; if they aren't---meaning they're valid transactions on the new best ...


3

The Bitcoin client used to download blocks without necessarily knowing if they could connect it to their current chain. If it couldn't connect a block to the genesis block, it would just keep it in memory. This was a waste of memory (up to 750 MB could be used up before it started dropping blocks) and bandwidth (if you drop a block that you need, that wastes ...


3

Blocks with an unknown parent block are stored in the orphan block pool. They will stay there until the parent block is received and then linked to the existing chain. As far as I know, there's no other condition for the block to be removed from the pool. If the particular parent is never received, they will remain there forever. The current difficulty ...


3

When a block is disconnected, its transactions are added back to the mempool (where possible). If the new branch connected afterwards does not remove them again, they remain there, and will be picked up by the block construction code.


3

Each block commits to the previous block in the block header by including the previous block's hash. A block's hash is defined as the output of hashing the block header, and for a block to be valid, this hash must fulfill the current difficulty requirement. While blocks can have more than one child block, the Bitcoin network finally agrees on just one best ...


2

Don't we actually mean stale blocks when talking in context of selfish mining? You always mean stale blocks, never orphan ones. An orphan block is one that you can not connect to your local chain because you are missing a parent, in the current version of the software you can never get into the situation where this happens. When most people are talking ...


2

The term seems to have been defined in this GitHub issue: https://github.com/zone117x/node-open-mining-portal/issues/138#issuecomment-42396180. Kicked basically means orphaned one way or another. Apparently, the creator of this pool software was seeing some strange behavior in the way the daemon would report blocks as being orphaned, and decided to just ...


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

Nothing malicious. Two blocks were mined at the same time by different miners (Block 267647). Both blocks included the transaction and both were broadcast to the network. Both blocks show up in the block chain because you don't know who actually won until additional blocks are mined and added to one chain or the other. The chain with the greatest amount ...


2

Well that is simply bad luck. It can happen if the miner uses multiple Bitcoin nodes to handle the getwork or stratum requests. In the case of GHash.io my guess is that they either have so many resources that a single nodes cannot handle all the work to keep them working, so they created multiple nodes and distributed the resources on them. Another reason ...


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