so the stale blocks are caused by two miners adding blocks at the same block height and then one of the miners blocks because stale and stuck in mempool purgatory?
1 Like
Iām curious to know if there is a Glassnode or any visual way to witness this happening?
Also what is the longest two competing chains have been before being resolved.
1 Like
Transactions in a shorter chain that isnāt already on the current adopted chain will go back to the mempools. Then Miners can pick it up again
But this is about accidental forks, not ordinary soft forks.
1 Like
Yes,
Stale or extinct blocks are blocks that were produced by building on an block that is no longer the active tip of the chain. Some nodes may have considered it to be the best block at some point, but they switched to another chain which does not contain the relevant block anymore. They are valid, verified, and their ancestry up to the genesis block is fully known - theyāre just not currently āactiveā.
When 2 miners mine at the same blockheight, it creates 2 versions of truth, 2 different blockchains. Then it all depends on the next miner on wich version he mines a new block wich makes it a longer chain than the other version. Transactions that were included in the losing block go back to the mempool. Then Miners can confirm it again.
1 Like
Then there are 2 versions of truth (accidental fork) for a while until 1 chain becomes by a new miner
1 Like
In an accidental hardfork, everyone will update with a new bitcoin core version. It happened in the past.
Two hard forks were created by āprotocol changeā
- March 2013 Chain Fork (migration from BerkeleyDB to LevelDB caused a chain split)[3]
- CVE-2018-17144 (Bitcoin 0.15 allowed double spending certain inputs in the same block. Not exploited)
2 Likes
Thatās what I mean, on the non-accidental soft fork. There may be several blocks in the abandoned chain (according to the illustration in the lesson) so what happens to the transactions in those abandoned blocks?
1 Like
Hi Filip,
In the lecture about the pros and cons with hard and soft forks, would it be wrong to say that pros to the Hard forks could be that there are benefits to miners in that:
-
They receive more space in the block which equals more transaction fees?
-
The mining process for larger blocks require greater computation power and will take longer to be mined therefore act as a way to regulate the hash rate?
-
More transactions can be stored at one time equalling faster validation times for transactions.
This last one also doubles up as a con because its more expensive?
Would that be correct?
all the best
Hi Filip,
What happen to the reward of the miner who mines the stale block?
Filip,
In the lecture on accidental forks you said that stale blocks get discarded and that the transactions recorded in them simply get lostāand that the money used in these transactions is lost as well. You also said that accidental forks happen all the time. So taken together, these two statements seem to imply that people lose money all the time. Is that really true? If I remember correctly, it was said in an earlier lecture on stale blocks that the transactions in them re-enter the mempool and therefore do not get lost. So which claim is valid?
I think, I got it now:
With respect to the first quiz question (which I got wrong), I just double-checked the video on accidental forks. In that video the fork is marked by two blocksāone blue and one greenāwhich in that video are said to be different. So I interpreted ādifferentā to mean that the contents are different and therefore chose my quiz answer accordingly. But apparently, what was meant by ādifferentā in the video was not that the contents of the block are different at the level of the transactions in the block but only at the level of the nonce and the resulting hash of the block header. Is that correct? If it is then that also explains my earlier confusion concerning the prior comment that money is lost when one branch of an accidentally forked blockchain is eventually discarded. What was meant in that case, it seems, was not that any money spent or received in the transactions in the block is lost (which would be highly disconcerting) but rather that the miner of the discarded block loses his or her rewards (which is also disconcerting for that miner but less so for the family of bitcoin users as a whole). Is that correct?
Filip,
Without (hopefully) being too tedious about it, I would like to point out that the notion of an update that renders invalid certain previously valid blocks (soft fork) is not logically equivalent to the notion of an update that is contractiveānor is the botion of an update that renders valid certain previously invalid blocks (hard fork) equivalent to the notion of an update that is expansive. The problem is that an update can simultaneously render invalid certain previously valid blocks and render valid certain previously invalid blocks. For instance, if it were decided that very small blocks are inefficient and thatāsimultaneouslyāthe presently largest permitted block size is not large enough, the rule that blocks need to be smaller than 1 mB could plausibly be replaced by the rule that block sizes need to be between 0.5 mB and 1.5 mB. In this case, the resulting fork (according to the definitions given in the video) would be both hard and soft because previously invalid blocks (in the range from 1 to 1.5 mB) would be declared to be valid (hard fork), and simultaneously, previously valid blocks (in the range from 0 to 0.5 mB) would be declared to be invalid (soft fork). My point is not to argue (of course) that the setting of a positive lower bound for block sizes is useful but merely that the notions of hard-fork updates and soft-fork updates (as defined in the video) are not mutually exclusive. By contrast, the notions of contractive and expansive udates are in fact mutually exclusive. For the former notion may naturally be construed to be equivalent to the notion of an update that renders invalid certain formerly valid blocks without rendering valid any previously invalid blocks and the latter notion may equally naturally be construed to be equivalent to the notion of an update that renders valid certain previously invalid blocks without rendering invalid any previously valid blocks.
More abstractly speaking, we may say that an update is contractive if the set A of previously valid blocks contains as a subset the set B of all blocks that are valid after the update and that, analogously, an update is expansive if A is a subset of B. So according to this definition, an update is contractive and expansive simultaneously if and only if A is a subset of B and B is a subset of A, that is, if and only if A equals Bāthat is, if and only if there really is no update.
Also, I am curious about the comment that soft forks are generally preferable to hard forks. The reason given in the video for this suggested opinion was that soft forks become non-forks if a majority of miners is willing to play by the new rules. I understand the argument, and I also understand why in the soft-fork case the dissenting minority of miners will be forced to adopt the new rules so along so long as the rule that the PoW longest chain is the true chain is in place. But so far as I can tell, a soft-fork scenario is one in which the majority imposes its will (ruthlessly) on the minority and in which the minority is given no choice (other than leaving the blockchain world altogether and creating some alternative technology space that can exist without the PoW longest chain rule). So when we say that a soft fork is preferable, we strictly mean that it is preferable in the eyes of the majority. Personally, I am not sure I really find that soft-fork scenario all that attractive. Just a thought.
So with respect to my prior comment concerning the problem of majority rule in the soft-fork case, I would like to add that this problem was addressed in the next video, but that I still beg to differ (in a perfectly friendly spirit of course). The characterization of the hard-fork and soft-fork cases (in this latter video) as democratic and undemocratic, respectively, ought to be reversed. The soft-fork case is analogous to an ideal democracy (not in the sense of being ideally desirable but of being ideally or perfectly true to character) in which the majority can always impose itās will on the minorty, and the hard fork case, by contrast, is analogous to a constitutional republic in which certain inalienable rights (such as the right to create a new blockchain 
) are declared to be absolute and are revocable only if the majority standing against them is exceedingly large.
As I understand there are two valid ways in the BTC blockchain, legacy and the newer Segwit with tighter rulesā¦ is there any information which one is preferred now and why wouldnāt all miners switch to the preferred way after lets say 1 year or 2 years after security is proven?
1 Like
Yes, your statements are correct. Only feeās for the users would be lower because there is more space and less competition for it.
Miners with heavy machines would like that. But other full nodes wonāt be happy. Miners are only 1 part of the whole eco system.
Right now bitcoin has 1MB blocks and hold so many transactions, which increase the fees because there is no system to judge what is spam and wat is a transaction. Equally there is not a system to judge if your transaction is more important than your neighbors.
The option is in the hand of everyone, you want your transaction to go faster you pay higher fees. Since the 1MB gets filled and one block is created every 10 mins, the higher fee you pay the higher the chances you get into the next block.
The problem with block increase, is that if you want to clear the line right now you would need bigger block and this require a hard fork and code upgrade. Not that bad right? No, short term itās not that Bad.
Letās say to sustain the current traffic of bitcoin we need 8MB block and you get low fees transaction are super fast etcā¦ everyone is happy.
Fast forward 2 years in the future, bitcoin is a bit more mainstream a lot of people starts trading it, invest in it. We are seen as a MUST have asset, the traffic had increased 10 foldsā¦ 8MB -> 16MB -> 32MB -> 64MB -> 128MB -> 256MB -> 512MB -> 1024MB -> 2048MB -> 4096MB
Now we need 4Gig blocks to sustain traffic, but remember blocks gets released every 10 minutes, so you need to validate a block before one get released.
Now nodes have to validate 4Gb blocks every 10 mins, blockchain is growing 4GB every 10 minutes. Considering there is 6x4GB blocks in an hour 24GB increase in an hours 24 hours in a day 576GB per day of blocks 4TB a week. 208 TB of data in a yearā¦
I donāt think the regular average joe will run a node for fun and have to keep a datacenter in his house just for āfunā or to help bitcoin.
So youāre creating centralisation of nodes and only big companies can run them. So you need a ābankā to run your nodes ( hold the ledger of all transaction ) and we came full circle. We just recreated the traditional banking system.
2 Likes
They donāt get a reward. This is exactly the reason why the coinbase transaction (block subsidy +all tx feeās) is timelocked for 100 blocks. So miners can only spend the reward after 100 new blocks are mined.
2 Likes
So stale blocks happen when 2 miners accidentally mine a block on the same blockheight. Wich will fork the blockchain for a while with 2 valid versions. Then it depends on the next miner on wich version he mines a new block (wich makes 1 version a longer blockchain) nodes accept the longest blockchain as the current true state. So 1 block on that particular blockheight in the shorter chain will get dropped. Every transaction that was included in the stale block and was not included in the other block and the newly mined block will return to the mempool. Where miners can pick it up again. So basically nothing gets lost. So itās possible that your transaction had 1 confirmation, and later becomes unconfirmed again. As long as you paid a reasonable amount of fee, your transaction will eventually be on the blockchain again. Thatās why you better wait for more confirmations.
For this Reason, The blockreward has a timelock of 100 blocks. So miners canāt spend the reward until 100 new blocks are mined. (just in case their block becomes stale)
1 Like
Hehe, yes but in a hardfork everyone needs to update. So if a small minority doesnāt update, you will have a split in the community. Reduced hashpower on both chains, Also users need to be aware that there are 2 different versions now.
In case bitcoin needs a hard fork because of a security issue, Iām sure that everybody will update and not split the blockchain and community
Thank you so much, Fabrice, I really appreciate your effort in sending me this detailed reply. It seems to me that your answer is mostly in line with my own suggested answer in the post. But in saying that a transaction will be included in the chain so long as the attached fee was reasonable, you are in fact hinting at the possibility that a transaction can get lost. If the fee was very low to begin with but still acceptable (so that the transaction got included in a block) and if the fees increased while the transaction was in the stale block, then, by the time it gets back into the mempool, its attached fee may be too low to be acceptable to any self-respecting miner and in effect the transaction will stay in the mempool forever (and therefore be effectively lost).
Also, in light of your answer, I donāt quite understand why in the quiz the correct answer was referring to equal blocks. You are referring to transactions that are in one block but not in the other. So that seems to indicate that the blocks are or can be different not only in terms of the value of the nonce but also at the level of transactions.
Frank
Good point. The majority can be tyrannical and the minority can be very annoying.
I understandāthank you for your reply.
Frank
Hi @filip, what is the limit criteria, once you have a fork, to define the path based on POW? Is it by blocks (the chain that makes 6 blocks after the fork remain) or by time (after 10 min the chain that makes more blocks remains)? Maybe another criteria which I could not imagineā¦
1 Like