<blockquote>
  <p>(1) Each validating server maintains a list of trusted servers known as Unique Node List (UNL).</p>
</blockquote>

<p>This is correct for the XRP Ledger. Non-validating servers do this too.</p>

<blockquote>
  <p>(2) Servers only trust the votes issued by other servers which are contained in their UNL.</p>
</blockquote>

<p>These are votes for whether to delay a valid transaction or process it immediately. This is needed to ensure that honest participants agree on the ordering of valid transactions received at about the same time.</p>

<blockquote>
  <p>(3) Ripple enables different institutions (e.g. banks which run their own servers) to reach a consensus with respect to the fate of financial transactions.</p>
</blockquote>

<p>Right. So if Alice has some XRP, she can send it to Bob or she can send it to Charlie. And every honest participant can tell which transactions are valid and which aren't. The problem is that they need to agree on the order in which the transactions are executed or they may not agree on the results. This is what the XPR Ledger does.</p>

<p>Please don't call it Ripple though. Ripple is a company (with a Trademark on "Ripple") that, among other things, built a payment network (RippleNet) that has different properties and the use of the term"Ripple" to refer to the XRP Ledger risks confusing people.</p>

<blockquote>
  <p>(a) Can we conclude a a bank which runs its own server will reach a consensus on its transactions via only servers trusted by that bank ?</p>
</blockquote>

<p>No. At least not unless something is horribly wrong. Say there are 100 people in a room trying to agree on a number between 1 and 100 and you can only hear 5 people in that room. If those 5 people can hear everyone in the room, you'll still wind up reaching a consensus with everyone in the room.</p>

<blockquote>
  <p>(b) And if so, can we say transaction validation in Ripple is trust-based and not trust-less?</p>
</blockquote>

<p>No. First, every server independently determines the validity of every transaction by itself. It doesn't need anyone else to tell it whether a transaction is valid or invalid. The only thing you need really consensus for is to ensure a consistent ordering of transactions across the network. If some people thing Alice's payment to Bob comes first and some think her payment to Charlie comes first, they'll disagree over which is funded and which is unfunded.</p>

<p>The only reason you need a UNL is that malicious people could create millions of apparent network participants that just refuse to agree on which of two valid transactions received at about the same time should be executed first. To prevent this, you need something scarce associated with each participant you wish to listen to.</p>

<p>PoW uses computing power for this. Consensus just has humans decide who they think is unlikely to collude to halt the network. With PoW, if you get it wrong and there's collusion, you get double spends and can't easily fix it. With consensus, you get a stalled network and can fix it just by ignoring the bad actors. You can easily do that because validators provide signed statements to facilitate the consensus process, so you can tell which keys are signing the nonsense and just stop listening to them.</p>

<p>If you want to argue that the XRP Ledger uses a trust-based method to order valid transactions received at about the same time, I guess I won't agree with you. But the advantages are huge:</p>

<p>1) It's millions of dollars a day cheaper than PoW.</p>

<p>2) It doesn't have the problems caused by conflicting interests. If you and I are mining, I'd prefer you not mine because you're getting a cut of the rewards that reduces my cut. That's why selfish mining is a thing. However, if you and I are validating and you are way better at it than me, I'd be perfectly happy just to stop mining.</p>

<p>3) It's much more fair because miners get to choose which transactions to include and nobody gets to choose which transactions go in consensus because it's done by consensus.</p>

<p>4) While incentives may prevent a double spend attack on PoW chains (so there have been some spectacular failures), it's not clear what to do if there is one. Changing the PoW algorithm screws over all the honest miners, and you didn't have enough of those.</p>

<p>5) Irrevocable confirmation is possible very quickly, typically in under ten seconds compared to many minutes with PoW.</p>

<p>So even if you think it's trust based, it's a minimal amount of trust (trust not to halt the network by refusing to agree, revocable at any time) the advantages are huge (much better censorship resistance, lower cost, higher speed, and so on). And, of course, PoW requires you to trust that a majority of computing power isn't in the hands of bad actors.</p>

CC BY-SA 4.0
2018-12-24T12:20:54.520Z
Just concerning your last phrase: _"PoW requires you to trust that a majority of computing power isn't in the hands of bad actors."_ from my point of view, PoW is not trust based, but **trusting majority of hashing power** is a **threshold** and means **we trust **functionality of the _entire_ network** instead of trusting **some specific entities**. That is, I accept new block from **any** miner who could solve PoW puzzle, And I **do not make difference between miners** such that I do not accept new block from **only** miners who I trust, but I accept new block from **every winner** miner.
Questioner
CC BY-SA 4.0
2018-12-24T17:55:24.793Z
@sas You may find that difference meaningful, but I don't. When I trust that the majority of mining power won't attack the network, I don't know which specific entities I'm trusting, but there are specific entities I'm trusting. I don't get to choose them, can't police them, and if they betray me, it's a double spend with no clear fix. By contrast, with consensus, you do choose them, they can't double spend no matter what, and you can police them. Plus, consensus is cheaper and faster.
David Schwartz
CC BY-SA 4.0
2018-12-24T22:50:59.747Z
In general, Bitcoin does not remove trust, but distributes trust between **unknown and non-trusted entities** (i.e. volunteer miners). A Bitcoin's user trusts **functionality of entire Bitcoin network**, otherwise he/she does not use Bitcoin network, but we do not say Bitcoin is trust based since a user does not (or is not able to) trust some selected/specific entities in the network. In general, if we **totally remove** trust from a **system**, then it is no longer usable. The target is replacing **trusting one/some specific entities** by **trusting the entire network** (distributing trust).
Questioner
CC BY-SA 4.0
2018-12-24T22:53:30.080Z
Briefly, In Bitcoin: _There is **not** trust between **user** and **miners**_ BUT _There **is** trust between **user** and **entire Bitcoin network.**_
Questioner
CC BY-SA 4.0
2018-12-25T01:24:23.880Z
@sas The same is true with XRP. You don't trust individual validators, but you do trust that the collection of validators won't collude against you. Similarly in bitcoin, you don't trust individual miners but do trust that the collection won't collude against you. The difference is that the XRP Ledger lets you choose and bitcoin doesn't. Both distribute trust, one just does it better because it's less trust (no risk of double spend) and more fault tolerant (you can fix a majority attack without screwing over honest participants).
David Schwartz
CC BY-SA 4.0
2018-12-23T05:32:12.677Z
2018-12-23T05:32:12.677Z
David Schwartz
<p>In Ripple consensus, </p>

<p><strong>(1)</strong> Each validating server maintains a list of trusted servers known as <strong>Unique Node List (UNL)</strong>.</p>

<p><strong>(2)</strong> Servers only trust the votes issued by other servers <strong>which are contained in their UNL</strong>.</p>

<p><strong>(3)</strong> Ripple enables different institutions (e.g. banks which run their own servers) to <strong>reach a consensus with respect to the fate of financial transactions</strong>.</p>

<p>From (1), (2), (3) : </p>

<p><strong>(a)</strong> Can we conclude a a bank which runs its own server will reach a consensus on its transactions <strong>via only servers trusted by that bank</strong> ? </p>

<p><strong>(b)</strong> And if so, can we say transaction validation in Ripple is trust-based and not trust-less?</p>

<ripple><trust><ripple-trust>
Is transaction validation in Ripple trust-based or trust-less?
Questioner
# Is transaction validation in Ripple trust-based or trust-less?

(Asked by: username_0 on 2018-12-20)

In Ripple consensus,

**(1)** Each validating server maintains a list of trusted servers known as **Unique Node List (UNL)**.

**(2)** Servers only trust the votes issued by other servers **which are contained in their UNL**.

**(3)** Ripple enables different institutions (e.g. banks which run their own servers) to **reach a consensus with respect to the fate of financial transactions**.

From (1), (2), (3) :

**(a)** Can we conclude a a bank which runs its own server will reach a consensus on its transactions **via only servers trusted by that bank** ?

**(b)** And if so, can we say transaction validation in Ripple is trust-based and not trust-less?

**Tags:** ripple, trust, ripple-trust


---

## 1 answers

### Answer by username_1 on 2018-12-23. Score: 2

> (1) Each validating server maintains a list of trusted servers known as Unique Node List (UNL).

This is correct for the XRP Ledger. Non-validating servers do this too.

> (2) Servers only trust the votes issued by other servers which are contained in their UNL.

These are votes for whether to delay a valid transaction or process it immediately. This is needed to ensure that honest participants agree on the ordering of valid transactions received at about the same time.

> (3) Ripple enables different institutions (e.g. banks which run their own servers) to reach a consensus with respect to the fate of financial transactions.

Right. So if Alice has some XRP, she can send it to Bob or she can send it to Charlie. And every honest participant can tell which transactions are valid and which aren't. The problem is that they need to agree on the order in which the transactions are executed or they may not agree on the results. This is what the XPR Ledger does.

Please don't call it Ripple though. Ripple is a company (with a Trademark on "Ripple") that, among other things, built a payment network (RippleNet) that has different properties and the use of the term"Ripple" to refer to the XRP Ledger risks confusing people.

> (a) Can we conclude a a bank which runs its own server will reach a consensus on its transactions via only servers trusted by that bank ?

No. At least not unless something is horribly wrong. Say there are 100 people in a room trying to agree on a number between 1 and 100 and you can only hear 5 people in that room. If those 5 people can hear everyone in the room, you'll still wind up reaching a consensus with everyone in the room.

> (b) And if so, can we say transaction validation in Ripple is trust-based and not trust-less?

No. First, every server independently determines the validity of every transaction by itself. It doesn't need anyone else to tell it whether a transaction is valid or invalid. The only thing you need really consensus for is to ensure a consistent ordering of transactions across the network. If some people thing Alice's payment to Bob comes first and some think her payment to Charlie comes first, they'll disagree over which is funded and which is unfunded.

The only reason you need a UNL is that malicious people could create millions of apparent network participants that just refuse to agree on which of two valid transactions received at about the same time should be executed first. To prevent this, you need something scarce associated with each participant you wish to listen to.

PoW uses computing power for this. Consensus just has humans decide who they think is unlikely to collude to halt the network. With PoW, if you get it wrong and there's collusion, you get double spends and can't easily fix it. With consensus, you get a stalled network and can fix it just by ignoring the bad actors. You can easily do that because validators provide signed statements to facilitate the consensus process, so you can tell which keys are signing the nonsense and just stop listening to them.

If you want to argue that the XRP Ledger uses a trust-based method to order valid transactions received at about the same time, I guess I won't agree with you. But the advantages are huge:

1) It's millions of dollars a day cheaper than PoW.

2) It doesn't have the problems caused by conflicting interests. If you and I are mining, I'd prefer you not mine because you're getting a cut of the rewards that reduces my cut. That's why selfish mining is a thing. However, if you and I are validating and you are way better at it than me, I'd be perfectly happy just to stop mining.

3) It's much more fair because miners get to choose which transactions to include and nobody gets to choose which transactions go in consensus because it's done by consensus.

4) While incentives may prevent a double spend attack on PoW chains (so there have been some spectacular failures), it's not clear what to do if there is one. Changing the PoW algorithm screws over all the honest miners, and you didn't have enough of those.

5) Irrevocable confirmation is possible very quickly, typically in under ten seconds compared to many minutes with PoW.

So even if you think it's trust based, it's a minimal amount of trust (trust not to halt the network by refusing to agree, revocable at any time) the advantages are huge (much better censorship resistance, lower cost, higher speed, and so on). And, of course, PoW requires you to trust that a majority of computing power isn't in the hands of bad actors.

> **Comments:**
> **username_0**: Just concerning your last phrase: _"PoW requires you to trust that a majority of computing power isn't in the hands of bad actors."_ from my point of view, PoW is not trust based, but **trusting majority of hashing power** is a **threshold** and means **we trust **functionality of the _entire_ network** instead of trusting **some specific entities**. That is, I accept new block from **any** miner who could solve PoW puzzle, And I **do not make difference between miners** such that I do not accept new block from **only** miners who I trust, but I accept new block from **every winner** miner.  
> **username_1**: @sas You may find that difference meaningful, but I don't. When I trust that the majority of mining power won't attack the network, I don't know which specific entities I'm trusting, but there are specific entities I'm trusting. I don't get to choose them, can't police them, and if they betray me, it's a double spend with no clear fix. By contrast, with consensus, you do choose them, they can't double spend no matter what, and you can police them. Plus, consensus is cheaper and faster.  
> **username_0**: In general, Bitcoin does not remove trust, but distributes trust between **unknown and non-trusted entities** (i.e. volunteer miners). A Bitcoin's user trusts **functionality of entire Bitcoin network**, otherwise he/she does not use Bitcoin network, but we do not say Bitcoin is trust based since a user does not (or is not able to) trust some selected/specific entities in the network. In general, if we **totally remove** trust from a **system**, then it is no longer usable. The target is replacing **trusting one/some specific entities** by **trusting the entire network** (distributing trust).  
> **username_0**: Briefly, In Bitcoin: _There is **not** trust between **user** and **miners**_ BUT _There **is** trust between **user** and **entire Bitcoin network.**_  
> **username_1**: @sas The same is true with XRP. You don't trust individual validators, but you do trust that the collection of validators won't collude against you. Similarly in bitcoin, you don't trust individual miners but do trust that the collection won't collude against you. The difference is that the XRP Ledger lets you choose and bitcoin doesn't. Both distribute trust, one just does it better because it's less trust (no risk of double spend) and more fault tolerant (you can fix a majority attack without screwing over honest participants).  

---

