Page 1 of 4

Consensus...mechanisim UNL

PostPosted: Wed Apr 02, 2014 11:15 am
by GryphonArk
what is the mechanism of deciding who get on a servers on the UNL....

who/what has control of this?

Re: Consensus...mechanisim UNL

PostPosted: Wed Apr 02, 2014 2:41 pm
by Sukrim
Each operator of a rippled server has full control over the UNL of that server. They can freely choose whatever they can come up with to ensure relative uniqueness of the entries.

I read on some wiki page that there are ideas of replacing this with some kind of "supernodes" - no idea how far that idea is taken so far.

Re: Consensus...mechanisim UNL

PostPosted: Wed Apr 02, 2014 7:13 pm
by JoelKatz
Each person who runs a server can choose the entries on their UNL. However, we want rippled to "just work" without you being forced to make decisions if you don't want to.

Our plan is to have organizations that publish lists of validators. Organizations will confirm the identity of validator operators, what jurisdiction they are in, what kind of organization they are, and so on. They can set policies for inclusion or include metadata about each validator relating to its policy. They would be expected to monitor the performance of the validators they publish.

Server operators can then select publishers to use. They can enforce a policy if they want by using the metadata (for example, no validators in the UK or no validators operated by governments). The default policy can also avoid too many validators in the same jurisdiction or operated by the same type of organization.

The default configuration in the Ripple Labs distribution of the server will be to include every publisher that meets some set of guidelines we would come up with. That would mean that no configuration changes would be necessary unless a publisher went rogue or a several publishers ceased operating.

What's nice about this approach is that publishers can facilitate policy enforcement without having to decide what the policy is. For example, say there's a consensus that many people would like to exclude validators that don't certify every 90 days that they accept all transactions on a non-discriminatory basis. A publisher could decide to include a metadata bit indicating whether a validator had made that certification while listing validators in both categories. Those who wished to could exclude validators that didn't have this bit set.

Re: Consensus...mechanisim UNL

PostPosted: Sun Apr 06, 2014 5:54 pm
by GryphonArk
...This seems open to manipulation.

eg you could do something pretty much like a 51% if you get enough servers together....what sort of hardware do you need to run as a server.....I suppose the centralised rules re like bit coins core dev deciding the code base and miners deciding to run it.......

also why can't more XRP be made...whats stopping that?

Re: Consensus...mechanisim UNL

PostPosted: Sun Apr 06, 2014 6:04 pm
by AndrewSF
GryphonArk wrote:...This seems open to manipulation.

eg you could do something pretty much like a 51% if you get enough servers together....what sort of hardware do you need to run as a server.....I suppose the centralised rules re like bit coins core dev deciding the code base and miners deciding to run it.......


No. The Ripple Consensus algo requires 80% of validator nodes to agree a transaction took place. There is no known 51% attack possible on Ripple or Ripple gateways.

also why can't more XRP be made...whats stopping that?



Because that is the hard limit in the Ripple software. Read the source if you don't believe us (hint: don't! :geek: ).

Re: Consensus...mechanisim UNL

PostPosted: Sun Apr 06, 2014 6:25 pm
by Sukrim
GryphonArk wrote:what sort of hardware do you need to run as a server.....

Depends on what you want this server to do. As there are currently no packages available one limiting factor might be that you need more than 2 GB RAM to compile it. Otherwise it would be cool to try to run it on a RaspberryPi...

In reality though you simply need a lot of everything. CPU, RAM, disk I/O... the more the better.

Re: Consensus...mechanisim UNL

PostPosted: Mon Apr 07, 2014 4:17 am
by moocowpong1
GryphonArk wrote:...This seems open to manipulation.

eg you could do something pretty much like a 51% if you get enough servers together....what sort of hardware do you need to run as a server.....I suppose the centralised rules re like bit coins core dev deciding the code base and miners deciding to run it.......

also why can't more XRP be made...whats stopping that?


It sounds like you're thinking of something like a Sybil attack, where you have many apparently independent nodes operated by the same attacker. But to do this, you don't just need to run the software, you need to convince the operators of existing validators that they should put you on their UNL. This is why the community shouldn't trust anonymous validators – there should always be some sort of real-life verification of the identity of the validator. Otherwise it's impossible to have any idea which validators might be colluding.

Re: Consensus...mechanisim UNL

PostPosted: Mon Apr 07, 2014 8:03 am
by Sukrim
I would trust anonymous validators, I wouldn't just go and put all of them in my UNL.

Re: Consensus...mechanisim UNL

PostPosted: Mon Apr 07, 2014 1:07 pm
by moocowpong1
Perhaps it would be more precise to say you should treat completely anonymous validators as potentially colluding with anyone.

Re: Consensus...mechanisim UNL

PostPosted: Mon Apr 07, 2014 2:32 pm
by Sukrim
Yes, you can of course try to do some statistics or metrics about them, but then again these could be faked/gamed by them too (e.g. you could analyze response times, only allow 1 anonymous validator per large IP subnet...).

As long as one does not overdo it, I guess having a bunch of anonymous validators is quite fine and useful, after all Bitcoin miners/pool operators are largely anonymous too or could be secretly colluding (though it costs more money there to game the system)