The last week or so I spent some time trying to educate some people on the significance (or lack of it) of a re-org and that it's fundamentally a function of the distributed consensus mechanism that underpins Bitcoin. That is to say, it literally is the novel piece of Bitcoin that made it possible to create a trust less distributed consensus mechanism where nodes could join and leave the network at any time.
I'll say that that process was fairly frustrating since it seems that many people don't understand how the process works. I'm not an expert by any stretch, but I can read, I have been a software engineer for > 20 years, and I used to be a miner. People may not realize that orphaned blocks are not an uncommon occurrence and they are of no consequence what-so-ever, other than to the miner who gets orphaned and loses his block reward. Such is life.
Anyway, I was pleased to see this write up by shadders333 who, being an actual expert in the field, wrote a very informative article on the topic and so from now on my plan is to just refer people to that:
https://www.yours.org/content/on-forks--orphans-and-reorgs-0c0c39d3c79b
On this topic, however, and as I have argued and shadders argues, a 6 block re-org, whilst not a desirable thing to have happening all the time (from a miner's perspective) is a perfectly normal thing to happen, especially under a "high" load situation where "high" means a significant load with respect to the system's capacity. That idea got me thinking about the BCH re-org protection. If I recall correctly, that is set up to prevent any re-org larger than 10 blocks. The recent BSV re-org was 6 blocks. So it doesn't seem to be outside the realm of possibility that if a stress test or some other event that causes unnaturally high load could cause a re-org larger than 10 blocks. If this happened on BSV, it would be more or less just like the 6 block re-org. With the last one under BSV's belt, it would be less disruptive for services since things like Planaria have already had fixes put in place based on the last stress test, but otherwise it would be the same. The network would eventually converge on a single chain and the system keeps on trucking. But with BCH, if a re-org larger than 10 blocks occurs, it is my understanding (subject to correction) that the BCH chain would be irrevocably forked into two (or more) chains. That really sounds like a major disaster waiting to happen does it not?
Now maybe the 32MB limit on BCH right now is sufficient enough to avoid this possible nightmare scenario, I don't know. We haven't seen sustained 32MB blocks on BCH to really know if there are any bottle necks lurking that could cause such a split. But even so, the 10 block re-org "protection" seems like a liability to me. A re-org, as I have talked about and shadders333 talks about, is a perfectly natural thing in a distributed consensus system, yet BCH (ABC) has code to "protect" against the very feature that allows the system to work in the presence of unexpected events. The very feature that makes Bitcoin, Bitcoin.
I don't dislike BCH, but at a technical level, this realization about the BCH re-org protection seems to make me a little nervous. I guess if the BCH chain did split, I'd still have BCH on all of the split chains, but then it would be interesting at the very least to see how that kind of situation could resolve itself.
Like I said, just a random brain fart...
No comments:
Post a Comment