Welcome to the discussion thread about this lecture section. Here you can feel free to discuss the topic at hand and ask questions.
23 Likes
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?
Thanks,
Tamas
51 Likes
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.
47 Likes
Thank you for the answer - now it is absolutely clear.
8 Likes
How can you remove your tx from mempool?
12 Likes
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.
-
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.
-
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.
35 Likes
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 
@filip
15 Likes
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?
Thanks.
5 Likes
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?
2 Likes
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.
27 Likes
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âŠ
11 Likes
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?
2 Likes
No,
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.
2 Likes
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 
this one 
), 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.
RESULT:
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.
5 Likes
Iâm going to research a bit further on it.
I have found a great article about it.
https://medium.com/@lightcoin/the-differences-between-a-hard-fork-a-soft-fork-and-a-chain-split-and-what-they-mean-for-the-769273f358c9
3 Likes
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? 
2 Likes
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. 
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.
4 Likes