Jump to content
Sign in to follow this  
Coinseeker

A question about validators

Recommended Posts

I was having a discussion today and I got some questions that I know were discussed some years ago but couldn't remember all the facts.  

Once the validators are no longer controlled by Ripple.co, (or even with just Ripple.co in control ) it is possible for the controlling validators to vote to increase the supply of XRP, correct?  As unlikely and unwise as that may be, it's still possible, right?  If so, wouldn't that also mean the supply of XRP could also be decreased?  If this is true, that would mean certain XRP would remain "valid" and others wouldn't, I suppose.  In a case such as these, would this cause RCL to fork or is none of this possible and I'm just misremembering?  

 

Share this post


Link to post
Share on other sites

As I understand it, the XRP is asset on the ledger as any other with the exception that it doesn't have issuing address. I think the scenario you're describing would mean that critical majority of validators would collude and "create" additional XRP (or any other IOU) with fake transactions. Should that happen, "new" XRP would be the smaller problem. And yes, it would likely lead to ledger fork with the other non-colluding validators on the other side.

I might be wrong though. Waiting for somebody who actually understands the protocol.

Share this post


Link to post
Share on other sites
29 minutes ago, inative said:

As I understand it, the XRP is asset on the ledger as any other with the exception that it doesn't have issuing address. I think the scenario you're describing would mean that critical majority of validators would collude and "create" additional XRP (or any other IOU) with fake transactions. Should that happen, "new" XRP would be the smaller problem. And yes, it would likely lead to ledger fork with the other non-colluding validators on the other side.

I might be wrong though. Waiting for somebody who actually understands the protocol.

Yeah, I think you're on the right track as I too think the ledger would fork.  Not 100% certain though. 

Share this post


Link to post
Share on other sites

There is no such thing as "controlling validator". Validators can be trusted or untrusted, but not controlling or not controlling.

There are several degrees of damage, that trusted validators can do (if they decide to give up their hard-earned trust), in increasing difficulty order:

  1. If more than 20% of them decide to collude, they can prevent transactions from being validated.
  2. If a set of them, each of which only trust others in the same set, with less than 20% of them trust others not in the same set, decide to collude, they can create fork.
  3. If more than 80% of them decide to collude, they can rewrite history as they wish.

This is my understanding. Please don't hesitate to correct me, if I were wrong.

Thank you!

Share this post


Link to post
Share on other sites

There's only one way to create more XRP, which is to redefine the protocol and get it approved by a vast majority of trusted validators (~80%). There are a few different ways this could look, but ultimately that's it.

  • You could implement and propose an amendment to the protocol using the amendment system. Introduce a new transaction or pseudo-transaction that generates XRP from nothing. (Stellar-style inflation, for example.) In addition to the usual challenges, this involves a 2-week waiting period.
  • Create transactions that generate XRP in violation of the existing protocol. You'd have to change the rippled source to execute these in a different way than usual, or manually generate a ledger that has these transactions executed in an abnormal way. Then you have to get those transactions / validators approved by the consensus network. (To fraudulently confirm transactions requires control of ~80% of trusted validators, per the consensus whitepaper.) In effect, you're making de factor changes to the protocol to add exceptions for specific cases.
  • Implement a custom version of rippled that has a different protocol, then get 80% of trusted validators to switch to this version of rippled. This is like the amendment system but without the courtesy of a 2-week waiting period. (You could put your changes on any other sort of switch you wanted. In the past, Ripple has basically does this with timed switches for benign reasons, like fixing bugs/exploits in transaction processing.)

Actually, there's one other way to create XRP:

  • Hack at least 80% of validators in existence and edit the databases containing ledger data to change the record of what transactions and balances exist. No protocol changes necessary—just rewrite (the recorded) history!

To be honest, one of my greatest fears and reservations about XRP right now is that, while Ripple still controls all the validators, stuff like this is merely "very difficult", not completely and utterly infeasible.

I should mention, by the way, that if any of the above happened, the people who are running untrusted validators or non-validating servers would follow along what their trusted validators do by default, but they could get together and roll back to a prior version of the ledger, then change their configs to change which validators they trust, to fork away from the version of the ledger with changes they didn't like. (Sort of like what happened to ETH vs. ETC, but with a config change instead of a code change.)

Share this post


Link to post
Share on other sites

@mDuo13 Yes. It seems it's actually very easy to create fork. All it takes is to start a bunch of validators and let them trust each other, and then do whatever they want to do.

Share this post


Link to post
Share on other sites
Just now, r0bertz said:

@mDuo13 Yes. It seems it's actually very easy to create fork. All it takes is to start a bunch of validators and let them trust each other, and then do whatever they want to do.

Yes, it's quite easy to create a fork. (It's only "slightly" tricky becasue rippled servers tend to want to connect to each other and then they get confused about why all their peers are talking about something completely different.)

The hard part is getting people to use your fork instead of the main network that everyone uses, because the point of the whole system is that there's one main network that everyone uses.

Share this post


Link to post
Share on other sites
14 hours ago, mDuo13 said:

Actually, there's one other way to create XRP:

  • Hack at least 80% of validators in existence and edit the databases containing ledger data to change the record of what transactions and balances exist. No protocol changes necessary—just rewrite (the recorded) history!

The ledger headers then would disagree with the data in the database and a simple ledger_cleaner call would just remove these entries again. Historic data integrity is one of the main reasons why RCL is using a blockchain in the first place.

Share this post


Link to post
Share on other sites
20 hours ago, mDuo13 said:

There's only one way to create more XRP, which is to redefine the protocol and get it approved by a vast majority of trusted validators (~80%). There are a few different ways this could look, but ultimately that's it.

  • You could implement and propose an amendment to the protocol using the amendment system. Introduce a new transaction or pseudo-transaction that generates XRP from nothing. (Stellar-style inflation, for example.) In addition to the usual challenges, this involves a 2-week waiting period.
  • Create transactions that generate XRP in violation of the existing protocol. You'd have to change the rippled source to execute these in a different way than usual, or manually generate a ledger that has these transactions executed in an abnormal way. Then you have to get those transactions / validators approved by the consensus network. (To fraudulently confirm transactions requires control of ~80% of trusted validators, per the consensus whitepaper.) In effect, you're making de factor changes to the protocol to add exceptions for specific cases.
  • Implement a custom version of rippled that has a different protocol, then get 80% of trusted validators to switch to this version of rippled. This is like the amendment system but without the courtesy of a 2-week waiting period. (You could put your changes on any other sort of switch you wanted. In the past, Ripple has basically does this with timed switches for benign reasons, like fixing bugs/exploits in transaction processing.)

Actually, there's one other way to create XRP:

  • Hack at least 80% of validators in existence and edit the databases containing ledger data to change the record of what transactions and balances exist. No protocol changes necessary—just rewrite (the recorded) history!

To be honest, one of my greatest fears and reservations about XRP right now is that, while Ripple still controls all the validators, stuff like this is merely "very difficult", not completely and utterly infeasible.

I should mention, by the way, that if any of the above happened, the people who are running untrusted validators or non-validating servers would follow along what their trusted validators do by default, but they could get together and roll back to a prior version of the ledger, then change their configs to change which validators they trust, to fork away from the version of the ledger with changes they didn't like. (Sort of like what happened to ETH vs. ETC, but with a config change instead of a code change.)

To be honest I don't understand why you wrote this here?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×