Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - JoelKatz

Pages: [1]
1
So effectively a single node can hold out and say... sorry I am not including any transactions until everyone agrees with me not to include any transactions?  The entire network would then halt....  I am assuming this is NOT the case which means there exist cases where consensus is reached by many but not all and the guy who is out voted must accept it or move on....   
Right, but that's fine. The consensus process can fail and no harm is done except there's no consensus. It causes a tiny spike in transaction validation time. Who cares. (Think of a result of a consensus round being like a mined block. They can be orphaned or abandoned. Either they survive or they don't.)

Quote
If the UNL nodes are public, the government could pass a law requiring filtering and then what?
The same thing could happen with any scheme. Transactions are public. Say the goverrnment passes a law prohibiting people from accepting Bitcoin transactions on any chain that included specific transactions. Business would know who sent them Bitcoins and could tell if those Bitcoins passed through the prohibited transactions.

Quote
How many nodes are currently participating in the UNL consensus aspect of the Ripple network?   Has anyone produced a network topology of a directed graph of UNL lists?
We're hoping to have a transition to a large number of distributed validators well underway around June. Currently, Ripple Labs runs five validators and pretty much everyone just uses those five.

2
It is like having two groups of friends, half want to go to Olive Garden and half want to go to Burger King... but not everyone cares what everyone else things because they all have a local perspective.   So from the perspective of the BK crew they have a super majority and from the perspective of the OG crew they have a super majority... anyone who tries to be friends with both crews is screwed they pick one side to go with... so one guy sides with OG and another sides with BK.
There aren't two positions on an equal footing. Everyone understands that a transaction can only be included if it has a supermajority of support and they are perfectly happy to exclude a transaction for one round rather than risk a fork. If there's a standing agreement to go to Burger King if there's no agreement otherwise, the problem is much simpler.

Also, nothing terrible happens if they go to different restaurants. They just fail to produce a consensus ledger and can try again.

Quote
So everyone wants to reach consensus and they do reach consensus within their domain...  some nodes who are in two domains will recognize a split as a minority of their UNL list goes some other direction.
Those nodes will just convince the side that included the transaction to exclude it, because nobody wants a fork. You have to imagine a crazy topology for that not to work.

Our plan for Ripple is to have organizations that publish lists of validators whose performance they monitor. They will include the jurisidiction and organization type of the validator. By default, the software will pull validator lists from several such organizations and pick a random sample, weighted by the number of organizations that include that validator. You will be able to add filters like "no validators in the US" or "no validators operated by governments" if you wish, as organizations will include that information in the lists they publish. You will, of course, be able to add or blacklist validators, change the list of publishers, and so on.

3
2) If one of the two nodes adds a second person to his UNL list then there is a 50% chance of a fork because not everyone agrees.
You're assuming the nodes aren't trying to reach a consensus when in fact that is their top priority. If one node refuses to change its position because doing so will cause a fork, then the other node will change its position. Avoiding a fork is every node's priority, second only to correctness. Why would a node fork when changing its position would avoid one?

If two people are trying to decide where to go for dinner and one says "it must be Olive Garden" and the other says "Olive Garden is okay, but I prefer Burger King", they'll agree to go to Olive Garden.

Consensus is robust because if there's absolutely no reason at all to exclude a transaction, then every honest node will want to include it. If there's any reason at all to exclude a transaction, then every honest node is perfectly happy to exclude it, so long as it gets introduced into the next round, which every honest node will agree to.

4
I have been working on the consensus algorithm and while it is fast it has the following problems:
1) There is no way to compensate people for running full nodes.
Right, but there is no need to compensate them. Bitcoin doesn't compensate people for running full nodes, only for mining, which consensus doesn't have.

Quote
2) The cost of running full nodes grows with N^2 the number of nodes participating in the consensus process
I'm not sure how you figure that. The cost of the consensus process itself scales as N log N and is divided over the nodes. The work each node has to do scales with the log of the number of nodes participating. Perhaps you're thinking that every node must directly consider what every other node is doing. That's not so. You only need a sample, and that scales with the diameter, which is the log of the number of nodes.

Quote
3) There is no way to reward nodes that participate in consensus to cover the cost of bandwidth growing
There is no evidence that there's any need to do this. Bitcoin doesn't reward transaction relaying either.

Quote
4) If you rely on charity, the regulatory risks may result in nodes not proliferating
It's not charity. People run nodes because they want high-quality access to the network. If the network doesn't provide services worth its bandwidth, it should die. This is the same reason people run Bitcoin nodes.

If you don't believe me or are still worried, then the community can just decide that, say, 1,000 validators is enough to provide reliability and decentralization. Adding more would provide no benefits, so just don't. There's no need for 100% agreement on this, people can just refuse to relay validations they don't think add sufficient value.

Also, you can't have it both ways. Your argument is basically, "nobody will run a validator because the bandwidth caused by all the reliable validators that we can't afford to drop will be too high" that's like "nobody wants to go to that restaurant because it's too crowded".

Pages: [1]