[noxer]

unwanted/unplanned forking is a "threat" in the sense that it causes uncertainty. Idk about this specific project and how they handle this but for example the XRPL has amendments which come with software update but are not enabled they are open to votes. Each amendment must constantly get over 80% positive votes for 2 weeks to be accepted. The validator nodes who voted against it are overruled by this they must install the latest version to be able to vote on the amendment therefore they do have the code and if the consensus is to enable the new code their node will do so. This prevents forking.

Intentional forking as a feature is ofc still possible. Validators owner who disagree with an amendment to the point that if it is accepted they would want to stay on the "old chain" and thus fork it, can simply remove the "yes" votes from their validator list essentially ignoring their votes and thus separate from each other. By the time one cluster enabled an amendment and the separated cluster does not, a fork happens*. This requires some kind of coordination and is unlikely to happen unexpected. A largely unpopular amendment would simply not reach the 80%. And one that reached 80% is unlikely to be consider so bad by the remaining 20% that they would want to fork. But the possibility is there it just never happened in the 8+ years its running.

*ofc it would also go the other way around. An amendment that wont reach 80% could also cause a cluster to intentionally separate and enable it there which would also case a fork.

[capableweb]

First you bring up something that is neither a cryptocurrency or properly decentralized (XRP and the XRP Ledger [Ripple]) then you simply miss the question as a whole.

The question was: "What exactly is the "threat" of forks?"

Your answer seems to be the answer to the question "How can we prevent forks?"

"Uncertainty" is certainly getting at some sort of answer, but falls short as you're not really explaining what kind of uncertainty and why it's bad in the first place.

[noxer]

>The question was: "What exactly is the "threat" of forks?"

Yes uncertainty was the answer. If a fork happens you dont know which side is going to die or if both keep going on. You dont know which sides coin someone wants if he wants to be paid in the coin named prior to the fork. You may not even know there is a fork because it happen on accident and is only discovered after it happened.

I would say this is the "threat" the "bad part" and it is bad because it is unwanted by most users of the system but that's just my opinion. There is now way to proof its unwanted by most user nor does that mean its bad for everyone. So this goes nowhere. If you think its good I'm happy to agree that this is purely an opinion.

A controlled/planed intentional fork seems to be what I assume most people would want but that again is "good" solely because its my opinion.

Hence my message pointed out the fact that we can have the "good" part about forks without the "bad" part about forks if the system prevents the "bad kind" of forks to happen. Your message already pointed out the benefit of forking and preventing unintentional forking would not affect these benefits.

Now to the other part which was really just an example how another system managed to prevent unintentional forking without preventing forking itself. I'm sure there are tons of other solutions so the fact that you don't seem to like this one is kinda irrelevant, it was just the example that I know best and was probably the first around.

Still gonna "fact check" this because why not^^ You seem to be confusing stuff. I wont go any further into a discussion about that tho because quite frankly its all out there to read for anyone who cares. It not my goal to shill stuff or prevent people from reading and believing whatever FUD they choose. Everything can be verified, no need to trust what I tell you, its all public since many many years.

First, the XRPL is not a cryptocurrency and I never said it is, its a distributed ledger. XRP is a cryptocurrency/digital asset/token whatever you wanna call it. There is no consent over the definition for these words so its not really debatable.

The XRPL is however definitely "properly decentralized" regardless of what FUD you may have read about it. Decentralization is rather well defined and whether something is or isn't can be objectively "measured". Although I ofc dont know what _your personal_ definition for "properly decentralized" may be, its decentralized as in no single point of failure or control exists in the system. If you use another definition then it may or may not fit. But this is the most common simplified definition.

For a system that has to "decentralized" reach 80% agreement this means at least 3 independent entities are necessary to make it de-facto decentral. However, 2 colluding would break this already so obviously more than 3 is wanted. 3 would be the theoretical minimum. How many _you personally_ want to have to make it "properly decentralized" _for you_ isn't really a debatable topic, its an opinion. More is objectively better and less than 3 is objectively not decentral anymore.

The XRPL currently has about 30 _legally independent_ validator operators. There is no means to measure independents however. And no means to evaluate what would be needed to make 80% collude. BUT its important to know that colluding would not give them any financial benefit, in fact it would just stop the XRPL from working, which they all voluntary choose to support so that does not make much sense.

There is no double spending or the like possible if someone gains control over 80% of the validators. It could be turned off or they could push an amendment though that does whatever they want but its all public. No honest node can be tricked into breaking its own rules and add any kind of invalid transaction, reverse something or allow double spend. No amount of control can change the code that runs on the other validators. Assuming you dont trust anyone, you have to run your own node and then you can only be fooled if someone takes over your node at which point there is no way to prevent you from being fooled anyway.

If a collusion or take over would happen is would be a situation where a fork would be unavoidable and ofc wanted. Every honest participant would obviously choose the side that didn't push some amendment trough that somehow benefits someone. So there would be a fork with everyone who doesn't wanna play by the rules and the "main chain". This immediately renders the whole collusion useless as they have full control now but only on their own chain that no one cares about and are excluded from voting on the "main chain".

But overall its a purely theoretical scenario. There is no incentive to gain control if you cant do anything useful with it as the honest participants would just fork and exclude the compromised parties. Same if they would turn it off. It would just be a matter of time before the non-compromised parties ignore the offline ones so they can reach 80% consent again.

>(XRP and the XRP Ledger [Ripple])

That makes no sense

- XRP is the token in the XRP Ledger

- The XRPL is the whole system, the "blockchain", the DLT

- rippled is the name of the C++ implementation of the XRPL

- Ripple is a company that currently maintains the source code of XRPL reference implementation (rippled), which is open for anyone including for contribution. They are not controlling the XRPL. They are not controlling the code. Just like controlling the bitcoin GitHub repo does not control bitcoins code or the network.

Ripple also runs validators and in the early days they ran all of them so it was not decentralized according to the definition above. Over time more and more validators joined so Ripple no longer has any special power.

So far exactly 1 amendment was accepted with over 80% quorum without ripples positive votes. That means Ripple could not prevent that amendment from being enabled - they got overruled/over-voted.

Ripple also holds a lot of XRPs that however gives them no special rights or control over the XRPL. Most of these XRPs are in a time escrows.

Hope that clarifies some stuff you may have head. There is always XRPL.org for more in detail information. And like I said its not the only system that prevents unintentional forking.