Updates & Forks - Discussion

Hey Filip,

In “Accidental Forks” video at 8:17 you said that if my transaction is in a stale block then I will lose my money. But if I’m correct, that transactions will get back to mempool, so nothing is lost, just that transaction will be confirmed a bit later on the “longer”/valid chain. Am I right?




Hi, good question. I took a look at the video but didn’t actually find the part where Ivan mentioned that you will loose your money.

You are correct, the tx will go back to the mempool. What can happen however is that a payment that you have received could be taken away from you. Let’s say you’re an online store and you sell digital goods. If you get a tx sent to you, you send the product to the customer, then the tx happens to be in a stale block.

If the sender has bad intent and removed the tx from the mempool, you as a receiver of crypto have now lost your money. But this almost never happens of course. But this is one of the reasons you should wait 6 confirmations.


Thank you for the answer - now it is absolutely clear.


How can you remove your tx from mempool?


I assume you mean from the senders perspective, and not the nodes perspective. As a sender you have 2 options in order to “cancel” a transaction. There is no easy way to cancel, and no built in method to do so, so both of these are sort of workarounds.

  1. Replace by fee. You can replace/edit your transaction if your wallet support RBF(replace by fee). Then you can edit it so that the funds just go back to you.

  2. Double spend. You can submit a new transaction with a higher fee. This transaction spends the same UTXO as your earlier transaction, but will hopefully be confirmed before your previous tx. But this is not guaranteed.


Here’s a link to a post going into more detail about the nature of stale blocks which occur with accidental forks. It turns out that they aren’t literally “thrown away”, more “disregarded temporarily”, but they’re still kept by the nodes as valid blocks and monitored in case they need to be “re-activated”.
The post itself is within a longer thread, where I was asking about how nodes validate blocks and update their version of the blockchain. As it also delves into a more detailed analysis of stale blocks, I thought it would be helpful to include a link to it here. Check out the whole thread if you think it may be of interest :smiley:


Hi Filip I understand the details of the lesson but I’m really not sure why would you introduce a rule that will result in stale blocks? Is this not a waste of effort?

Next: Why do you say people prefer a soft fork to a hard fork? (The answer to the first question might clarify this.)

Basically I understand the reason for a hard fork but soft fork is a mystery to me.

One other point is that someone was explaining a soft fork to me and his explanation of it was that two miners create a valid hash at the same time but only one of the new blocks gets accepted by the network.

I’m not sure about the mechanism by which one of the two blocks gets accepted: Is it that the winning block contains more transactions?



Here again!

Pros v Cons: When you say that nodes “don’t understand” the new transactions, how do they remain as a functioning part of the network? Don’t they receive the software update the same as the other miners?


Stale blocks happen all the time, even without an update (accidental forks)
Because of the size of the network, more than 1 miner can mine a valid block at the same time.
ex. If an american and an european miner could mine a valid block at the same blockHeight, You basically have two valid blocks that are propagating through the network starting from their location.
Because the longest chain wins (most proof of work) means that it depends on wich of those 2 block the next miner can mine the next valid block. The transactions from the losing block that were not included in the ‘winning block’ are going back to the mempool. The losing block is called a stale block.

A soft fork is a change in the protocol wich makes previous valid blocks invalid. So the old nodes can still talk to the new updated nodes (backwards compatible) So not every node needs to update.
while in a hard fork, every node has to update, otherwise you end up in a split because the old nodes can’t talk to the updates nodes.
Thats why soft forks are not a big issue. while in hard forks you need to convince every miner to update.

wining blocks has noting to do with the amount of transactions init.

I hope this helps.


Thanks. I’ll study your answer some more. Much appreciated!

1 Like

I’m assuming here you are talking about some of the nodes not updating for a soft fork…
If you are, then maybe this will help:

= a shrinking/tightening of the rule set.
So, the nodes which choose not to update (for whatever reason) will still be able to validate ALL transactions and new blocks which they receive from the updated nodes — because the updated protocol “fits within” the old one. I think this is what @Fabrice means by:

However, with transactions and new blocks which are valid according to the old rules but don’t “fit within” the tighter/stricter rule set of the updated nodes, if these are propogated throughout the network by the non-updated nodes and then received by the updated nodes, the updated nodes will treat them as invalid and reject them — only other non-updated nodes will accept them. Due to consensus, this means that as long as more than 50% of the miners update, then only blocks that are valid according to the updated protocol will end up in the longest chain. Non-updated nodes can still mine or operate as non-mining nodes within the same network, but any mining nodes that don’t update will immediately become uncompetitive (because proportionately, less of their mined blocks will end up being confirmed within the longest chain). So, due to competition, miners will be incentivised to eventually update to the new protocol, whether or not they agree to it in principle — which I think could be seen as either an advantage or disadvantage of a soft fork, depending on whether you (a) want to promote adoption of the update without splitting the network, or (b) are against the update yet forced to implement it in order to remain competitive.

I wrestled with the logic of all this for a while, myself. Hopefully, these extra comments, building on what @Fabrice has already posted, will also help… :smiley:


Thanks for the response. There are a number of questions which arise but they may be answered in the BTC programming course.

So at least if i write them down it should be useful.

Does the 50+% adoption of new protocol precede longest chain production (as in: cause it) or do a minority of participating nodes create longer chains before the 50+% adoption occurs?

I suppose what I’m asking is: Do 50+% of participants need to adopt the new protocols before launch?


In a soft fork, you just start to have 2 types of nodes (if not everyone upgrades) . The updated nodes with ‘tighter’ rules and the others with the previous ‘normal’ consensus rules. The nodes who didn’t update, still allows everything. Only the updated nodes have ‘tighter’ rules and have more restrictions to validate and mine.


@Fabrice @LeCorb @filip

My understanding is the answer to both is actually YES if…

 = >50% of the network’s total hashing power.

I think this is also correct, and that you could theoretically launch an update this way, but that you would still need mining nodes with >50% of the total hashing power to update before the soft fork would actually occur, and before the longest chain would start to only include blocks mined according to the new protocol (i.e. a successful update).

I say theoretically, because I would have thought that in practice, a soft-fork update wouldn’t actually be activated until at least a majority (by a comfortable margin) of the miners were on board (and probably a large number of non-mining nodes as well), in order to account for any slippage, avoid unnecessary implementation costs and disruption — not to mention a public relations failure. I also think that:
The smaller the majority (of hashing power)  the greater the number of stale blocks created…
…leading to a much less certain and “messier” implementation.

The actual implementation of the SegWit soft-fork was extremely complicated and convoluted, with various different activation methods (both miner-activated and user-actived) discussed and attempted, but from what I can gather (bearing in mind it’s a very deep :hole: :rabbit2: this one :wink:), an overriding common theme was the need for adoption by a super-majority of the hashing power (I’ve seen both 95% and 80% mentioned in articles).

However, if by participants we mean all of the network’s nodes (mining and non-mining), then I guess you could have a situation where <50% of the total number of participating nodes update, but >50% of the hashing power updates, and which would still result in a successful soft fork  e.g.

Let’s say there are 100 nodes in the whole network;
60 of these are mining nodes;
18 mining nodes each have 4% of the total hashing power; all of these nodes update;
Only 10 non-mining nodes update (i.e. only 25% of non-mining nodes);
All 72 remaining nodes (42 mining, 30 non-mining) continue operating according to the legacy protocol.

A large majority (72%) of the total participating nodes don’t update (only 28% update).
Only 30% of the mining nodes update, but between them they have 72% of the network’s total hashing power. Therefore, the soft fork is successfully implemented.


I’m going to research a bit further on it.
I have found a great article about it.


what I understand now is that for a softfork you need a majority of the miners to approve.
there is also a difference between miner or user activated soft fork.


Hey! I’m glad we ended up coming to the same conclusion.

Yes, I’d noticed this User-Activated Soft Fork too, while reading about SegWit. I also saw it mentioned in the Medium article you found. I’m starting to understand it — it seems to be a way of the non-mining nodes pressurising reluctant miners to eventually update, in a kind of long and drawn-out soft-fork process — but I definitely want to find out more about how it works in practice.

I also didn’t fully understand what a sustained chain split or a blockchain reorganisation are, which are also mentioned in the article — although they seem to be a way of forcing the implementation of the updated protocol with only a minority of miners onboard (having realised that a soft fork isn’t going to happen).

Nothing is ever straight-forward or clear-cut is it? :joy: :wink:


When there is a hard fork what percentage is needed to decide? 51% Who does the programming, who decides and makes sure it’s programmed correctly?

Can it be forked down the like, BTC then Bitcoin cash then bitcoin cash can then fork again?

Does this effect the supply of the original BTC? When it forks how is the supply determined? Does it mirror BTC then gets mined at a different rate or still 10 minute blocks.

Thanks in Advance. :slight_smile:

Thanks Flip, after reviewing your video concerning Updates & Forks, I have a better understanding. Even more so, the questions and discussions in the forum has also benefitted in my understanding.


A hard fork is when nodes of the newest version of a blockchain no longer accept the newest version of the blockchain; which creates a permanent divergence from the previous version of the blockchain. Adding a new rule to the code essentially creates a fork in the blockchain: one path follows the new, upgraded blockchain, and the other path continues along the old path. Generally, after a short time, those on the old chain will realize that their version of the blockchain is outdated or irrelevant and quickly upgrade to the latest version. You don’t need a certain percentage to fork.
you can fork the bitcoin blockchain on a certain blockheight and it will basically copy the history and utxo’s ect. so If you own 5 bitcoin before the fork happened, you will also have 5 bitcoin of the new forked version of the Blockchain. If you didn’t changed rules on the mining part, The difficulty will adjust to have an approximately of 10min blocktime.