Uncles are stale blocks that contribute to the security of the main chain, but are not considered the canonical "truth" for that particular chain height.
In contrast to orphan blocks (which have no parent), uncle blocks are linked to the chain but are not part of the final selection.
Uncles are stale blocks which are not orphaned.
Orphan blocks have no ...
From the glossary
Uncle: a child of a parent of a parent of a block that is not the parent, or more generally a child of an ancestor that is not an ancestor. If A is an uncle of B, B is a nephew of A.
Why they are needed?
To help reward miners for when duplicate block solutions are found because of the shorter block times of Ethereum (compared to other ...
Ethereum determines the longest chain based on the total difficulty, which is embedded in the block header. Ties are broken randomly.
Total difficulty is the simple sum of block difficulty values without explicitly counting uncles. Difficulty is computed based on parent difficulty and timestamp, block timestamp, and block number, again without reference to ...
The mined block is an uncle. The uncle reward formula is (U_n + 8 - B_n) * R / 8 where R is the static reward of 5, U_n is the uncle number and B_n is the block numer, so:
Uncle 0 : 4.375 ETH
Uncle 1 : 3.750 ETH
Here's an example:
B_n = 1337, R = 5
U_0 = (1336 + 8 - 1337) * 5 / 8 == 4.375
U_1 = (1335 + 8 - 1337) * 5 / 8 == 3.750
If you got 3.75 ether, this was an uncle mining reward. Kind of the "second place" of mining on Ethereum. You found a solution but someone else found the solution before you. Thankfully for you, it was soon enough from the original block that a reward was paid out.
It's still 5 ether per block for a mining reward.
Update: As of Oct-16-2017 05:22:11 AM +UTC ...
GHOST is short for the Greedy Heaviest Observed Subtree chain selection rule which was a proposed modification for the Bitcoin blockchain (Paper).
GHOST orignally was a protocol modification, a chain selection rule, that makes use of blocks that are off the main chain to obtain a more secure and
With that modification, it is possible to ...
No, there is no difference in this case-- they are essentially equivalent. If the tx is orphaned, they should return null, but you should still check the block number because it may have been added to the new chain later than you expect, giving less probability of finality.
Casper began life as an adaptation of the principles of GHOST to security-deposit-based PoS. The most complex version of Casper uses a subtree-choice rule, executes all transactions and includes bets from blocks that are included in the dependency graph of winning blocks, and can do sub-network latency confirmations.
Vitalik's PoC of Casper is much simpler ...
The uncle reward calc is:
(U_n + 8 - B_n) * R / 8
In the first example, there are two uncles, U1 and U2. The uncle number of U1 is 4445, and the uncle number of U2 is 4446. The block number is 4447 and R is 5.
The uncle reward for the first example is the sum of the rewards for each uncle:
U1: (4445 + 8 - 4447) * 5 / 8 = 3.75
U2: (4446 + 8 - 4447) * 5 / ...
Uncles occur when a valid block does not make it into the long-term consensus. These orphaned blocks can be caused by high network latency, so I would say that a dramatic increase in the uncle rate indicates that the block gas limit is too high, thus making the blocks too large to propagate efficiently. Alternatively, it could indicate some other slow down ...
Here's my scripts to check and print blocks, uncles and transactions. You will see the logic to retrieve the uncle details within the getMinedBlocks() function.
I've listed them separately for easier reading. If you intend to use it in geth, you would probably want to concatenate the following 5 functions into a single file for easy copy-pasting into the ...
Block number is not unique you can have two or more blocks with the same number. The chain will eventually sentle on one of them, but for a period of time any of them can be valid, ie some nodes on the network will see one of them to be valid and others nodes can see a different block. Usually the period of time is brief, ie less than five blocks, but in ...
Yes, it is possible because the miner's won't necessarily know the other has found a solution. The news of these discoveries spreads via gossip, so there is always latency.
A very short summary of the way this is resolved is that nodes favor the longer of the two chains. It has more proof of more work. It's a little counter-intuitive so it bears mentioning ...
Answering your first question: If the transactions in a block that is declared invalid have not been already validated somewhere else in the main blockchain, they will be returned to the pool of unconfirmed transactions from which miners mine. There is no loss of data.
As it stands, by my reading of it, there is something akin to uncles in the proposed PoS system, referred to as "dunkles". See this:
The second strategy is to simply punish validators for creating blocks
on the wrong chain. That is, if there are two competing chains, A and
B, then if a validator creates a block on B, they get a reward of +R
on B, ...
This is only a partial answer.
Here are some differences which I noticed when looking a the linked pages in your question:
Miner Reward. Forked blocks earned the miners a full reward (5 ETH + gas fees) while uncle blocks only earned them a fraction of that
Numbers As of today (July 7, 2017, 12.25 pm), there are only 15,584 forked blocks on the ...
Things have changed since the answer by Nick was posted.
Especially, with introduction of EIP 100 (which was accepted in June 2017 - just 3 months after Nick's answer) which changes the difficulty calculation algorithm to include Uncles.
I'm new to Ethereum so I don't fully understand what effect this has so if someone could explain it, that'll be great.
No. Only uncle block headers are included. Also when including uncles only the validity of their headers is checked, transactions are ignored. From Design Rationale:
Uncle validity requirements: uncles have to be valid headers, not valid blocks. This is done for simplicity, and to maintain the model of a blockchain as being a linear data structure (and ...
If your frontend observes the event logs via JSON RPC (method eth_newFilter to create a filter and method eth_getFilterChanges to poll for the subsequent changes), you have the ability to receive events either from mined transactions (included into mined blocks), or from pending (not yet mined) transactions.
Even if you receive only events from mined ...
Yes, but they are routine and are less of a concern than they would be if the Bitcoin algorithm was arbitrarily speeded up, Ethereum's proof-of-work is not merely bitcoin's with a faster blocktime.
The concern is that faster blocks imply a predictable increase in branching because of network latency, and consequently faster blocks leads to loss of hash ...
Uncles are there to incentivise miners despite the fact that fast blocks give undue advantage to well-connected miners. Look up the GHOST protocol.
If the calculations needed to create an uncle were factored into adjusting the difficulty, it would make the blocks slower.
In the world of hash calculations, "nearly identical work" is misleading. There ...
Any way they want.
While miners have a good reason to build on the longest chain (because other miners will build on the longest chain (because other miners will build on the longest chain (...))) there's nothing stopping them from using some alternate method. For example, if a miner mines a block, and hears of a block someone else made, the first miner has ...
One block can include up to two uncles. If a block references two uncles, each uncle will earn 7/8th of 5 ETH to whoever mined that uncle. Each uncle being referenced will also earn a small reward per uncle (1/32 of 5 ETH) to the miner who references the uncles in his / her block.
You can find more details here in the Rewards Mining section.
Yes. But the exact circumstances are hard to pin down as it varies between nodes.
Each node on the Ethereum network will maintain it's own finite list of pending transactions. This is configurable on a per-node basis. Since the list is of finite size, if enough new pending transactions are received on the node or from other nodes, some transactions are ...
The Block number is not inherently unique. The Block number is the measure of blocks starting from the block in question to the first block(the genesis block).
It might be simple to assume that the direction of counting the blocks is an unnecessary clarification but this gains some ambiguity when dealing with hard forks.
In the case of a blockchain with ...
In Ethereum, the ommers (i.e. the uncles until 6th generation before
that are "included in the main block") get a reward. According to the Ethereum protocol specification (yellow paper), it is possible to include at most two ommers' headers in the block.
It is worth to mention that the bodies of the ommers (i.e. their transactions and their ommers) are not ...
You can never be 100% sure that any given block will be in the long term chain, but as more blocks are added on top of it, the chance that a given block will become an uncle decreases exponentially. This is exactly the concept of "confirmations" that you may have heard about.
To be relatively sure that any particular block will not be reverted, you should ...
Just to add to Rob's answer.
So does ETH fundamentally have a lot more branches,
Yes, as per Rob's answer.
and a lot more orphaned transactions than BTC does?
Yes, but, if most miners are using the same default transaction ordering* (see What is the default ordering of transactions during mining, in e.g. geth?), and have the same view of the tx pool,...
Uncle are blocks that are not longert part of the main chain due to a chain reorganization. You can try calling getBlock(hash) if it was mined recently.
Nodes will stop propagating once it was mined as an uncle. Even archival nodes might not have the data anymore if they started to sync after the block was mined.