Bob - I could use some help clarifying these claims

[SamIam]

Hey Bob,

I was just pointed to this report: https://cryptoresearch.report/wp-content/uploads/2019/07/Crypto-Research-Report-July-2019-EN.pdf

While it makes some obviously incorrect claims about Ripple/XRP, there's some things I'm not entirely clear on as it relates to consensus. I'm hoping you can help clear this up, and I'm posting here because I think a lot of people in the group will benefit from this as well. I'm going to put a video together on this report, and want to get it as accurate as possible to educate the larger community.

There's a lot to explain here, and I'm happy to review links to go read up on any of the questions below.

Here's where my questions start:

P28:

Quote

. . . Is XRP Ledger’s consensus mechanism decentralized?. . . What is clear is that RippleNet’s xCurrent and xVia are not using the XRP Ledger, so they have centralized consensus.

xVia was billed initially as an interface for corportates so submit payments via RippleNet. Birla recently tweeted that it's a bridge between xCurrent and xRapid. Can you add anything to that? Has that always been the case? 

On the centralized consensus, my understanding - it's running on top of ILP and using a payment channel so upon close settlement over XRPL uses consensus.

P28 - This is from Binance Academy:

Quote

The UNL nodes exchange transaction data between each other until all of them agree on the current state of the ledger. In other words, transactions that are agreed upon by a supermajority of UNL nodes are considered valid and the consensus is achieved when all these nodes apply the same set of transactions to the ledger.

 

My best answer to this - That's just Ripple's list, if the default UNL becomes a small minority the rest of the network disagrees with, there is no overriding protocol/code putting Ripple or it's UNL nodes as a higher authority to the rest of the network. I'm confused as to what happens when the nodes start disagreeing. ( I realize this is a deep deep dive into consensus protocol, if I need to go read up somewhere I'm happy to if anyone can recomend a link to follow)

 

Quote

However, as BitMEX claims this entire process is unnecessary because,in order for a node to support a proposal for a new set of transactions, a node must download private keys from a server that is controlled by Ripple.

“The software indicates that four of the five keys are required to support a proposal in order for it to be accepted. Since the keys were all downloaded from the Ripple.com server, Ripple is essentially in complete control of moving the ledger forward, so one could say that the system is centralized. Indeed, our node indicates that the keys expire on 1 February 2018..., implying the software will need to visit Ripple.com’s server again to download a new set of keys.”

This is the first I've heard of ripple holding private validator keys. Is this an encrypted default UNL list or something more? Either they're misrepresenting how the keys are used, or this is a pretty solid claim.

 

P29:

Quote

According to BitMEX Research, XRP’s Ledger is unable to achieve distributed consensus: “For example, one user could connect to five validators and another user could connect to five different validators, with each node meeting the 80% thresholds, but for two conflicting ledgers. The 80% quorum threshold from a group of servers has no convergent or consensus properties, as far as we can tell. Therefore, we consider this consensus process as potentially unnecessary.”

This is where I'm confused about the whole consensus mechanism overall. I understand you can have different pools (UNLs), but how do they all stay in sync? If one validator or group gets out of sync or behind, does it just grab a current ledger close and pick back up? How does this sort itself out?

 

They seem to go completely off the rails with this one:

Quote

xCurrent’s peer-to-peer structure is similar to the Lightning Network discussed in The Crypto Research Report March 2018 edition.If Bank A wants to pay Bank B with US dollars, but Bank B wants to be paid in euros, the xCurrent protocol layer could route the transaction. Bank A would submit a transaction to convert the US dollars to euros(in the form of an IOU) to a global order book. xCurrent then acts as a path-finding algorithm to find the cheapest route for the US dollars amount to be exchanged to euros.

Not at all like lightening network, Banks provide their own liquidity, still uses Nostro/Vostro, and xCurrent is simply tracking/directing/updating private ledgers of the movement/release of funds between the two or more institutions involved. After reading a bit more, seems they're bringing issued currencies and gateways on the XRPL into the mix, and that's mostly what they're referring to here.

P31:

Quote

SWIFT is only a messaging system between banks and settlement systems, such as the Clearing House Interbank Payments System (CHIPS). xVia is the messaging application for RippleNet users that need to send invoices or other information to other users. This is the part of the technology that would compete with the SWIFT network.

This is largely only true for corporates correct? It seems like the "workaround" DS was describing is the use of xVia to bridge xCurrent and xRapid so MG can quote Fiat to Fiat while completing via xRapid.

 

The rest of the report is so ridiculous I'll have no problem destroying their arguments. Any input you guys can provide would be helpful.

~Sam

 

 

[CT99]

@BobWay if @SamIam were to ask would you consider being a guest on his youtube channel "To The Lifeboats"? - Check it out if you haven't already done so, that is one interview I would absolutely love to watch and I'm sure I'm not alone.

Thanks in advance guys (maybe!)

[BobWay]

Wow @SamIam there is a lot of crap in that "report". Not sure I have the interest to tolerate reading it.

I'm under the weather so feeling a bit grouchy. Any snark is targeted at the writers of the "report" @SamIam is questioning. Not toward Sam's queries

6 hours ago, SamIam said:

Quote

. . . Is XRP Ledger’s consensus mechanism decentralized?. . . What is clear is that RippleNet’s xCurrent and xVia are not using the XRP Ledger, so they have centralized consensus.

xVia was billed initially as an interface for corportates so submit payments via RippleNet. Birla recently tweeted that it's a bridge between xCurrent and xRapid. Can you add anything to that? Has that always been the case? 

On the centralized consensus, my understanding - it's running on top of ILP and using a payment channel so upon close settlement over XRPL uses consensus.

"Is XRP Ledger’s consensus mechanism decentralized?"  

Yes. The technology is documented in lots of places. This "report" doesn't seem to understand its most basic concepts.

"What is clear is that RippleNet’s xCurrent and xVia are not using the XRP Ledger, so they have centralized consensus."

How on earth is that clear? The statement doesn't make the least bit of sense. Consensus isn't even a concept that applies to xCurrent and xVia.

 

Sometimes he has all the clarity of BG123. Wait...? That's a thought. Nah.

In my understanding, xVia isn't a bridge between xCurrent and xRapid. Those connect together naturally through multi-hop rippling payments. xVia is basically a cloud hosted version of xCurrent. The original vision was to provide businesses and payment originators access to RippleNet (xCurrent) APIs, without their having to license and host the xCurrent software itself. I think of it this way:

xCurrent == RippleNet software for Banks
xRapid == RippleNet software for Exchanges
xVia == RippleNet hosted APIs for Business

"On the centralized consensus..."

There really isn't any such thing as centralized consensus. RippleNet's ILP is a synchronized payment protocol. it relies on bi-lateral agreement between parties sharing an accounting relationship. The synchronization is handled by ILP's notary component. The notary is only responsible for time keeping. It doesn't handle any other significant part the the transactions. (balances or approvals)

But yes, AFAIK you are correct. the xRapid parties settle using either XRPL payments or by closing XRP payment channels. I'm not up on the details of the latest partner implementations.

Oops, pressed return too early. I'll continue in separate posts.

Edited August 20, 2019 by BobWay

[BobWay]

6 hours ago, SamIam said:

P28 - This is from Binance Academy:

Quote

The UNL nodes exchange transaction data between each other until all of them agree on the current state of the ledger. In other words, transactions that are agreed upon by a supermajority of UNL nodes are considered valid and the consensus is achieved when all these nodes apply the same set of transactions to the ledger.

My best answer to this - That's just Ripple's list, if the default UNL becomes a small minority the rest of the network disagrees with, there is no overriding protocol/code putting Ripple or it's UNL nodes as a higher authority to the rest of the network. I'm confused as to what happens when the nodes start disagreeing. ( I realize this is a deep deep dive into consensus protocol, if I need to go read up somewhere I'm happy to if anyone can recomend a link to follow)

Binance Academy doesn't seem to understand even the most basic concepts.

Each rippled node operates completely independently. This is no different from how bitcoind nodes operate. A node's UNL and its consensus rules are set by the owner/operator of that node through configuration options.  A node's UNL and its rules define how that particular node decides whether or not it is in agreement with the rest of the rippled nodes it cares about.

That last phrase is more profound than it may at first seem.

If I run my own personal rippled node, the "unique" in my UNL (unique node list) means that I personal know who the operators of my specified UNL nodes are. Furthermore, it means that I personally am confident that the nodes I specify are not conspiring against me. This "uniqueness" requirement is how your rippled node protects itself against sybil attacks from anonymous conspirators. In effect, it just completely ignores those conspirators.

Those who choose to participate in consensus also do so independently. Each participating node broadcasts its own proposal for the transactions to be included in the next ledger. There is no barrier to entry for participation. Anyone can broadcast their own proposals.

However, NOBODY else is required by the protocol to care that you are broadcasting proposals. Each node operator makes a personal decision about the other node operators it cares to stay in agreement with. (This differs significantly from bitcoin's mining approach. It is also one of the more confusing characteristics to mining fans.)

If you did a little deeper it is easy to see that there can be many different rippled "consensus" agreements operating at the same time. This is true even if everyone's nodes are running exactly the same rippled software. In fact, this is how the XRP Test Net and the XRP Ledger both operate simultaneously using exactly the same software.

If you dig still deeper, it is pretty easy to see that if a set of rippled nodes all specify exactly the same UNL and 80% consensus setting, then every node in that set will remain synchronized with every other rippled node in that set. 

Note that the set of rippled nodes specifying a UNL is completely independent of the rippled nodes specified on the UNL So anonymously operated rippled nodes can say in prefect sync with a set of non-anonymously operated rippled nodes. However, by design, anonymously operated rippled nodes cannot participate in consensus. This characteristic tends to be the biggest annoyance to other cryptocurrency fans. However, this non-anonymity requirement leads directly to the XRP Ledger's consensus efficiency. In reality, the entire electrical burn rate of mining exist purely to allow anonymous nodes to participate in consensus. So this difference is fundamental. 

If a set of rippled nodes doesn't specify exactly the same UNL and 80% consensus setting it becomes non-trivial for most people to know/show if that set of nodes will remain synchronized in all circumstances. Ethan, David and others have set some bounds on what the UNL overlap must be. But that is a deeper and unnecessary discussion. If everyone starts with the same known UNL set, then subtracts or adds a few other nodes of their own choosing, it is likely they will stay in sync without problems.

It doesn't actually matter who chooses the set that everyone starts with. The only requirements for that initial UNL set is that every node operator is both known and unique. (known is required to guarantee unique). In reality most people have little reason to modify the common UNL.

However, it is possible for every rippled node to stay in perfect sync, but the network as a whole to still come to a grinding halt. This is true because it is possible for every node to decide independently that it does not have enough information to guarantee to itself that it is in agreement with the others. This can happen when more than 20% of the nodes on a given UNL (with an 80% consensus setting) all simultaneously fail. The halted state however, guarantees that no transactional forks can occur and that no transactions will need to be reversed.

So deciding which nodes are reliable enough to include on any given UNL is important as well. That is why Ripple keeps statistics for all known validating (consensus proposing) nodes whether or not they are on the current recommended UNL.

https://xrpcharts.ripple.com/#/validators

If the reliability of a validating node drops or its operator takes it down, that node's entry should be removed from the UNL of every rippled node that depends on it. This can be done independently by each node's operator or in unison by changing some common UNL definition. As long as there is not a dramatic number of simultaneous validator failures these UNL edits are not time critical.

Cobalt and other internal Ripple research integrate these UNL update decisions into the automated consensus process. But again, that is an advanced topic far beyond those who wrote the referenced hit piece.

 

[SamIam]

That clarifies a lot. I knew there could be various groups that trust each other. However, the default UNL is the "officially" recognized version of the ledger? Others can run and validate, but their work may be ignored because they're not part of the official group. That would let them still stay in sync and have access to transaction history for business purposes. However if they want to submit transactions they would have to do so with one of the default UNL validators. Do I have that right?

So Ripple created the default UNL out of necessity and security, but if people didn't like the way they managed it, they could take it away from them by starting their own and getting enough validators to join it?

If you have competing groups of UNLs what makes that different from a PoW fork?

(this can wait if you're not feeling great. I have a couple of videos to do before this one)

[BobWay]

7 hours ago, SamIam said:

P29:

Quote

According to BitMEX Research, XRP’s Ledger is unable to achieve distributed consensus: “For example, one user could connect to five validators and another user could connect to five different validators, with each node meeting the 80% thresholds, but for two conflicting ledgers. The 80% quorum threshold from a group of servers has no convergent or consensus properties, as far as we can tell. Therefore, we consider this consensus process as potentially unnecessary.”

This is where I'm confused about the whole consensus mechanism overall. I understand you can have different pools (UNLs), but how do they all stay in sync? If one validator or group gets out of sync or behind, does it just grab a current ledger close and pick back up? How does this sort itself out?

I think I addressed this in my previous post. Their astonishment is based purely on bad presumptions. If I specify 5 validators I will stay in agreement with them. If you specify 5 validators, you will stay in agreement with those. There is no underlying presumption that I want to stay in sync with the people you want to stay in sync with. (Think test net vs main net vs other net)  Nor is there a presumption that I want to accept consensus proposals from individuals anonymous to me, even if they may be known to you.

So suppose that your node (validator or not) crashes and falls out of sync with the others. When you bring it back up, it will simply begin doing what it always does. It looks for consensus proposals from the other nodes on its UNL. Once it sees a proposal that matches its consensus rules (80% of the UNL proposes the same thing) it accepts that as the next ledger.

It then starts to look backward to see if it is missing any prior ledgers from its local database. If so, it begins downloading them to close any gaps in the record.

[BobWay]

9 minutes ago, SamIam said:

That clarifies a lot. I knew there could be various groups that trust each other. However, the default UNL is the "officially" recognized version of the ledger? Others can run and validate, but their work may be ignored because they're not part of the official group. That would let them still stay in sync and have access to transaction history for business purposes. However if they want to submit transactions they would have to do so with one of the default UNL validators. Do I have that right?

Think of the Ripple suggested default UNL as two independent things.

1. It is a Validators ID == Public Key to node operator name map.  This is what makes any particular validating node "known" and assures that any given UNL has only one "unique" entry for that node operator. Technically, Ripple as a validator operator has not necessarily had a single "unique" entry on the default UNL. But that has been an operational compromise the company is working to remove.

2. It is an attestation by Ripple that the particular validators on the list are reliably operated. Meaning they have consistent uptime staying insync with the others on the list.

Nothing about inclusion on the UNL attests to the character of the rippled nodes operator or their business honesty. Nor does it consider whether or not those operators have any particular value stake (e.g. XRP holdings) in the network itself.

it simply says, here are who these people are. Include them or remove them at your own discretion. If you start with a UNL of 100 and remove 95. Well that is likely bad. If you remove 2 or 3 you won't notice any effect at all.

 

Now very interestingly (and like bitcoin) you don't submit transactions to validating nodes at all. Transactions are simply broadcast to every other rippled node. Those broadcasts include validating nodes as well of course. But in general, if you run your own rippled node (validating or not) you would sign and submit your transactions to your own node. It would then in turn broadcast them to the other nodes it is connected to (via IP addresses). Those nodes broadcast it further. During this process your transaction will make it to every rippled validator. However, by design to avoid DOS attacks, there is no proscribed validator --> IP address map.

[SamIam]

Okay, so the validators in a sense are organized like resistance cells. They don't all know each other, but each cell (UNL) works together, some may overlap and have connections/contacts to members of other resistance cells (UNLs). By broadcasting to all validators known to you, and the process repeating, eventually everyone is informed?

[BobWay]

27 minutes ago, SamIam said:

So Ripple created the default UNL out of necessity and security, but if people didn't like the way they managed it, they could take it away from them by starting their own and getting enough validators to join it?

Think of it the other way around.

Anyone can make a UNL list. They don't have to ask permission from the validators to do so.

So if you don't like Ripple's list, you just publish your own with the edits you want. It is then up to you to convince everyone else that your UNL starting list is better than Ripple's UNL starting list. If there is significant overlap between the two than they can easily coexist without consequences.

If on the the other hand you propose a dramatically different UNL (worst case zero overlap), then you are simply proposing that a new transactional fork is being created.

27 minutes ago, SamIam said:

If you have competing groups of UNLs what makes that different from a PoW fork?

Yes, as you point out, like with BTC based new coin airdrops, anyone could create a new transactional fork of the XRP Ledger. It just becomes up to you to make everyone else care.

[BobWay]

5 minutes ago, SamIam said:

Okay, so the validators in a sense are organized like resistance cells. They don't all know each other, but each cell (UNL) works together, some may overlap and have connections/contacts to members of other resistance cells (UNLs). By broadcasting to all validators known to you, and the process repeating, eventually everyone is informed?

Yes exactly! In practice it works really well.

However, it must be configured within the spirit of what you've written. It is pretty easy to show that if you have zero overlap, or minimal overlap in network participants then their ledgers will diverge. 

Edited August 20, 2019 by BobWay

[BobWay]

8 hours ago, SamIam said:

This is the first I've heard of ripple holding private validator keys. Is this an encrypted default UNL list or something more? Either they're misrepresenting how the keys are used, or this is a pretty solid claim.

I can't for the life of me think of what they have misunderstood here.

I'm sure the default UNL API call is referenced through an HTTPS based URL to avoid tampering. But I don't know of any other downloaded keys or certs. I don't know of Ripple signing other's certs either.

[SamIam]

Okay, I found it, the public keys became "private keys" because that sounds more mysterious:

https://blog.bitmex.com/the-ripple-story/

Quote

 

The image depicts some complexity in the process and the BitMEX Research team is unable to understand the detailed inner workings of the system or how it has any of the convergent properties necessary for consensus systems.
(Source: Ripple wiki)

In January 2018, the BitMEX Research team installed and ran a copy of Rippled for the purpose of this report. The node operated by downloading a list of five public keys from the server v1.ripple.com, as the screenshot below shows. All five keys are assigned to Ripple.com. The software indicates that four of the five keys are required to support a proposal in order for it to be accepted. Since the keys were all downloaded from the Ripple.com server, Ripple is essentially in complete control of moving the ledger forward, so one could say that the system is centralised. Indeed, our node indicates that the keys expire on 1 February 2018 (just a few days after the screenshot), implying the software will need to visit Ripple.com’s server again to download a new set of keys.

 

With BitMEX being a partner, hopefully someone at Ripple can reach out to get this corrected.

Edited August 20, 2019 by SamIam

[BobWay]

8 hours ago, SamIam said:

They seem to go completely off the rails with this one:

Quote

xCurrent’s peer-to-peer structure is similar to the Lightning Network discussed in The Crypto Research Report March 2018 edition.If Bank A wants to pay Bank B with US dollars, but Bank B wants to be paid in euros, the xCurrent protocol layer could route the transaction. Bank A would submit a transaction to convert the US dollars to euros(in the form of an IOU) to a global order book. xCurrent then acts as a path-finding algorithm to find the cheapest route for the US dollars amount to be exchanged to euros.

Not at all like lightening network, Banks provide their own liquidity, still uses Nostro/Vostro, and xCurrent is simply tracking/directing/updating private ledgers of the movement/release of funds between the two or more institutions involved. After reading a bit more, seems they're bringing issued currencies and gateways on the XRPL into the mix, and that's mostly what they're referring to here.

Ripple from its origination in classic RipplePay has had "trust lines" (accounts) in multiple currencies. It has often used the term IOU in reference to these accounting relationships.

Bitcoin traditionally has not considered anything like this as part of its blockchain. However, with lightning, people have been discussing payment channels as if they were IOUs or trust lines that are settled later. So now I often hear bitcoiners rippling concepts as "like lightning". Of course it is generally futile to point out that these concepts predate lightning by 15 years or more.

 

[BobWay]

5 minutes ago, SamIam said:

Okay, I found it, the public keys became "private keys" because that sounds more mysterious:

That is really old information. It was true that the recommended UNL contained only 5 ripple operated validators for quite some time. But that changed one more people became able to reliably operate their own rippled validators.

Currently the recommended starting UNL seems to be downloadable from here https://vl.ripple.com. I'm presuming that it is a signed blob so that it can be verifiably hosted elsewhere as well.

This page documents who owns and operates those validators (UNL column). https://xrpcharts.ripple.com/#/validators

 

[SamIam]

I asked this question of Alex from Nugget's news and he talked about BTC wrapped in an ETH ERC-20 token. He also talked about another side chain that exchanges will use to allow customers to move BTC between exchanges in something very similar to a payment channel. Of course this will just help whales arbitrage and not allow the privacy claimed, because there is no exit ramp without going through an exchange's KYC/AML choke point.