Jump to content
coinologist

What can an attacker who controls majority or all of the full nodes do?

Recommended Posts

But what can an attacker do if he has the majority (>80%) of the validators and the other nodes don't have any history (can such a situation come to exist?)

Will he be able to make up a ledger in which he can set balances to his own hand, such that this ledger is accepted by the other nodes?

I still have the feeling history is important. I know it is said that you only need validator consensus on the current ledger, but not 100% convinced. Imo, the more history, the better..

 

 

Share this post


Link to post
Share on other sites
1 minute ago, jn_r said:

But what can an attacker do if he has the majority (>80%) of the validators and the other nodes don't have any history (can such a situation come to exist?)

Will he be able to make up a ledger in which he can set balances to his own hand, such that this ledger is accepted by the other nodes?

I still have the feeling history is important. I know it is said that you only need validator consensus on the current ledger, but not 100% convinced. Imo, the more history, the better..

If they have 80+ they can do whatever they want, even if other nodes have history. Because the 80+ will agree on "set balance" (you can put whatever transaction here) and they will apply the transaction. The other nodes can only agree on that.

Share this post


Link to post
Share on other sites
1 hour ago, tulo said:

If they have 80+ they can do whatever they want, even if other nodes have history. Because the 80+ will agree on "set balance" (you can put whatever transaction here) and they will apply the transaction. The other nodes can only agree on that.

I thought that each node also applied the rules? So as long as it is within the rules, the other nodes will agree, but if it is not they would not accept the ledger and stop. That was at least my thinking, but could be wrong

--

edit: The crux of the matter should be found here: https://developers.ripple.com/consensus.html#validation, specifically what is described in figure 7: 

Quote

Each validator and tracking server calculates the next ledger version by applying the agreed-upon transactions to the previous ledger version

(.. not only validator servers but also tracking servers) and figure 8:

Quote

Each server compares its calculated ledger with the hashes received from its chosen validators. If not in agreement, the server must recalculate or retrieve the correct ledger.

What is dubious to me is when the server recalculates or when it retrieves the 'correct' ledger. If it only retrieves when it has no history (i.e. it cannot recalculate), then I think I am understanding correct and the ripple consensus mechanism is even more rock solid than you describe.

Edited by jn_r

Share this post


Link to post
Share on other sites
1 hour ago, jn_r said:

I thought that each node also applied the rules? So as long as it is within the rules, the other nodes will agree, but if it is not they would not accept the ledger and stop. That was at least my thinking, but could be wrong

Yeah, probably that depends on the rules (code) of the 20%. They can reject transactions and stop going forward.

Share this post


Link to post
Share on other sites
9 minutes ago, tulo said:

Yeah, probably that depends on the rules (code) of the 20%. They can reject transactions and stop going forward.

I was thinking of the other 967 stock/tracking nodes - that those stock nodes also apply the rules, the stock nodes just don't determine the order of transactions. But again I could be wrong :P I'll read some more if I can find some more convincing/clear text on the subject

Share this post


Link to post
Share on other sites
8 hours ago, tulo said:

Yeah I agree totally. The rest of validators won't make progress in ledgers, while the 80% of validators will proceed with their rules. I don't know if we can talk about a fork, because the 80% are actually the majority, so that network IS the main network :) . 

Would you define the main network as that with the most validators or that with the most users/activity?

Share this post


Link to post
Share on other sites
7 hours ago, tulo said:

If they have 80+ they can do whatever they want, even if other nodes have history. Because the 80+ will agree on "set balance" (you can put whatever transaction here) and they will apply the transaction. The other nodes can only agree on that.

But seems that history would matter. If other validators have no history they cannot tell what the state of the network was before the 80% colluded. If they want to fork and maintain a "fair" distribution of XRP they need to have some history so they can reset the state of the ledger after they've forked. 

Share this post


Link to post
Share on other sites
15 hours ago, jn_r said:

My guess: The network between the validators will keep on running, but the other nodes (the rest of the network) that didn't 'upgrade' will not follow, as the new transactions don't fit their ruleset. I think the validators will fork away from the rest of the network and the rest of the network will stop. Until new validators have been appointed in the rest of the network that do fit the same ruleset.

But I'm really interested in some more opinions on this..

 

15 hours ago, tulo said:

Back to topic: IF a misterious entity can control 80%+ of all validators in the UNL, then they can basically do whatever they want with the network. They can completely change codebase and validate any transaction. So they can double spend, create new XRP, ban someone from the network, change the rules of XRPL.

But the remaining validators (the "good" ones) can choose to basically fork at a specific ledger and start a new ledger from there (not an easy task :) ).

Thank you both so much, that answers my question perfectly. Thanks again!

Share this post


Link to post
Share on other sites
On 12/5/2018 at 4:28 AM, cmbartley said:

Would you define the main network as that with the most validators or that with the most users/activity?

That's a philosophical question. From a technical point of view it's the one with more validators. If you personally don't agree with the majority of validators and you think the remaining 20% are the good ones, then you can hope for a fork and support the 20%.

And BTW the remaining 20% won't have more activity nor more users because the ledger will update only following the 80% rules.

Share this post


Link to post
Share on other sites

If someone controls >80% of trusted validators, that party is in full control of the network. Others who follow along and trust them will do so as long as the transactions they send are not in contradiction with the rules of the network as the other servers understand them.

If you connect to the network and have no history stored at all, you have to take your trusted validators' word for what the state and history of the network are. You would have no way of knowing if the state those validators are telling you about is contradictory with the state that the network was following yesterday. But you could change your configuration to trust a different set of validators who you think are more honest.

If you are running a server and it has any history at all, then it enforces the rules it knows and the history it has. It won't approve of new transactions that don't follow the rules of the network as it knows them. If the trusted validators are using some different rules (i.e. new transaction types or fields, or just processing things incorrectly) your server will stop making progress in declaring ledgers validated because the new ones don't make sense to it.

I think there may be some exceptions, so that your server will correctly jump chains if you reconfigure it to use a set of validators who're currently on a history that's incompatible with the history your server was previously on, but I'm not totally sure where the boundaries are.

Share this post


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

If you connect to the network and have no history stored at all, you have to take your trusted validators' word for what the state and history of the network are. You would have no way of knowing if the state those validators are telling you about is contradictory with the state that the network was following yesterday. But you could change your configuration to trust a different set of validators who you think are more honest.

So what would happen if the server that didn't have history and caught up with the malicious validators, but then after some time would catch up via other nodes with its desired history up to the point where the malicious attack took place, would the server notice that the rules didn't apply at that specific ledger and retroactively render all ledgers thereafter invalid?

I'm not sure it is that important, as people will find out if an event like this would take place (and those people will consequently choose another set of validators), but for the sake of argument it would be nice to know how the network would behave (will it detect automatically) and if it is in this regard beneficial to keep more history for the network as a whole.

 

Edited by jn_r

Share this post


Link to post
Share on other sites
18 hours ago, jn_r said:

So what would happen if the server that didn't have history and caught up with the malicious validators, but then after some time would catch up via other nodes with its desired history up to the point where the malicious attack took place, would the server notice that the rules didn't apply at that specific ledger and retroactively render all ledgers thereafter invalid?

Do you mean you fetch history from other nodes and then discover a malicious transaction back in time? I don't think there is something already implemented to do that. You'd have to analyze the history yourself, and BTW how can you decide it was a malicious transaction or a group of malicious validators? You can't know which were the rules when that transaction was validated (amendments are approved sometimes and the code is changed, so the rules are).

Share this post


Link to post
Share on other sites
3 hours ago, tulo said:

Do you mean you fetch history from other nodes and then discover a malicious transaction back in time? I don't think there is something already implemented to do that. You'd have to analyze the history yourself, and BTW how can you decide it was a malicious transaction or a group of malicious validators? You can't know which were the rules when that transaction was validated (amendments are approved sometimes and the code is changed, so the rules are).

If you receive a ledger (I guess receiving history goes by ledger but not sure) then it makes sense to check if you already have a ledger before or a ledger after that one, so you can verify that you have a valid historic ledger according to -some- rules. I can imagine things like this are already done, how would you otherwise know that you are collecting valid history? I agree that it is not straightforward to handle the amendments. But on the other hand if you know the historical amendments and their timing (the time of going life is stored in the ledger) and the old rules are still in the codebase and you know which rules to apply at which time, then the whole ledger would still be deterministic. I am not sure however about the period before introduction of the amendments. And I also don't know if validation checks like this are already done when retrieving history.

 

edit: I found this at https://developers.ripple.com/history-sharding.html:

Quote

XRP Ledger Network Data Integrity

The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce proof trees or ledger deltas. Since rippled servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.

'producing proof trees' sounds a bit like what I had in mind

Edited by jn_r

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

×
×
  • Create New...