Stefan Thomas, Ripple Inc. CTO, on ILP adoption

[Guest Dizer]

Like many of you, I'm part of the W3C Intergledger community email list. In a response to a question on which banks are going to be using ILP on October 1st and whether or not RCL will be used in the first ILP transactions, Stefan Thomas, CTO of Ripple Inc.,  wrote the following response:

" Unfortunately, I don't have any details to share on Ripple's commercial deals. What I can say is that all of our solutions are going to be ILP-capable, because we believe that ILP has by far the best chance chance of being the protocol that powers the Internet of Value. It is also the simplest which tends to be a big factor in standards adoption. We're not opposed to supporting other protocols in addition to ILP if there is demand from our customers.

Speaking of adoption - our next goal is to build all the tools needed for a real-world internetwork involving the most popular crypto-currencies. Seeing is believing - we want as many people as possible to experience real ILP payments. The initial intended use case will be micro-payments. There is also still a lot of work to be done on the reference implementation and on porting ILP to other languages. "

 

Edited September 19, 2016 by Dizer

[thinlyspread]

Soon! 

But seriously, thanks for the info. 

[kanaas]

28 minutes ago, rippledigital said:

Soon! 

But seriously, thanks for the info. 

A Chinese saying .... It's not important how fast you go as long as you keep moving forward.

[thinlyspread]

That's what she said.

[getitdone]

Quote

From Interledger mailing list:

I find it curious that the language used in the ILP document uses financial terms in different ways than they are normally used, "escrow" for example.  And it invents new terms like "connector" in the place of what is historically called a "clearinghouse".

I do not think the multi-step escrow process actually makes it more secure.  Correct me if I am wrong, but a malicious connector could simply agree to a transfer and then fail to execute it, or reverse it after execution.

Introducing a new role called a notary, where there is one notary for each part of the transaction to verify the digital signature, adds another degree of complexity, without really improving security, because a "notary" can also be malicious and in collusion with a connector.

One problem seen with the crypto-currency community in general, of which Ripple is typical, is the belief that the need for human trust can be replaced with cryptographic trust.

What is missed is that the financial system over centuries has developed a system of human governance that works most of the time.  This involves the use of trustees and auditors, and either courts or arbitration. (Courts often do not work efficiently due to corruption, which is what makes arbitration more attractive as an inexpensive way of resolving disputes.)

So we see for example, the Bitcoin community rants fanatically about eliminating the need for trust, even as more than half of all Bitcoin exchanges since 2011 have failed, defaulted or stolen hundreds of millions of USD worth of the users funds.  Clearly, Bitcoiners have not solved the trust problem, and are not using the governance arrangements that have historically been used to mitigate the risk of insider theft.

The public ledger of Bitcoin and succeeding "blockchain" systems was based on the idea of "triple entry accounting", which is a way of making the public the auditor. (See http://iang.org/papers/triple_entry.html) This does not eliminate the need for an auditor, but allows the public to be the auditor.  You still need the other parties of classic governance, referred to as the "five parties model". (https://bitcoinmagazine.com/articles/five-parties-model-1393673552)

What I see missing in ILP is a way of incorporating the contract of the ledger as well as the inter-ledger rules into the payment, as is done by systems that use Ricardian contracts, which are open source and public domain and can be used by anybody. (https://en.wikipedia.org/wiki/Ricardian_Contract)

Second, we are missing the ability to include an arbitration clause, so that if any of the parties in the chain of connectors default, cheat, lie or fail to execute, the dispute can be efficiently resolved by human judgement in a jurisdiction that all parties agree to.  Ethereum recently demonstrated the necessity of this. (http://financialcryptography.com/mt/archives/001594.html)

Third, clearinghouses have historically taken the counter-party risk upon themselves.  An example would be the Chicago Board of Trade (CBOT) which runs the COMEX.  All members of the COMEX contract with CBOT which guarantees counter-party risk.  This enables them to safely trade with one another, even though they have no way to assess the credit-worthiness of the party on the other side of a trade.

CBOT handles the counter-party risk by requiring bonding and certain levels of liquidity of the members.

The ILP is attempting to build system of clearinghouses (connectors) that uses notaries and cryptography to eliminate counter-party risk.

However, it lacks a dispute-resolution mechanism.

In order to settle a dispute, the court or arbitrator must usually know who the parties are.  And here we see the third missing part of ILP. There needs to be a standard way of identifying an account holder who has agreed to the rules, and therefore can be subjected to arbitration.

I think that if these deficiencies were addressed, ILP could grow into a truly international standard.  But, as I see it now, Ripple are building a standard that works with Ripple.

But, will it really work in the real world of lawyers and contracts and government regulators who require financial institutions to know the parties on both sides of every transaction?

All it will take to expose the weaknesses in ILP is an incident like DAO.  If you create a number of silos of financial value that are connected by a series of rules like ILP or Ethereum, there are many parties who will attempt to use the rules to take as much value for themselves as they can get.  DAO demonstrated this, yet again.

That is even before you entertain the problem of people who break the rules, like Mt. Gox and those who use malware to steal users' keys.

Ripple's system can work between a closed group of banks, because it is a limited entry pool of parties who have to sign a contract with each other to enter and use it.  An open system as ILP proposes is a very different ball game.  These deficiencies need to be addressed before ILP can actually work in the real world.

Ken Griffith

 

Edited September 19, 2016 by tomxcs
clarified quote and source of quote

[cmbartley]

1 hour ago, getitdone said:

The ILP is attempting to build system of clearinghouses (connectors) that uses notaries and cryptography to eliminate counter-party risk.

However, it lacks a dispute-resolution mechanism.

Saw this on the email thread this AM. These are serious criticisms. However, and I need to look at IP more closely, my understanding is that there is a different between atomic mode and universal mode. In atomic mode participants can specificy which ILP connectors they trust (transact with) and further eliminate counter-party risk. Alternatively, this is where what R3 is building with Corda is important. It's the smart contracting layer that will like be able to settle via Ripple or other rails. In that instance, Corda would be responsible for defining the responsibilities of the parties involved and in some instance, in adjudication itself.

Edited September 19, 2016 by cmbartley

[Guest Dizer]

And the response from Evan Schwartz, Ripple ILP lead architect:

Quote

Good questions.

 

I find it curious that the language used in the ILP document uses financial terms in different ways than they are normally used, "escrow" for example.  And it invents new terms like "connector" in the place of what is historically called a "clearinghouse".

 

Connector refers to a category that includes but is not limited to clearinghouses. Other examples of connectors are bilateral credit relationships, market makers, and FX exchanges.

 

We've started using the word "hold" instead of "escrow", because it more accurately describes the behavior.

 

 I do not think the multi-step escrow process actually makes it more secure.  Correct me if I am wrong, but a malicious connector could simply agree to a transfer and then fail to execute it, or reverse it after execution.

 

Multi-step escrow does make it more secure. The sender puts funds on hold with their ledger, which will only be released if the connector presents cryptographic proof from the recipient that the recipient has been paid.

 

A connector that said they could do the transfer but then didn't forward the payment would not be able to deliver the proof and the funds would be returned to the sender. This means a malicious connector could cause a payment to be returned, but they cannot steal the money -- a very big difference! We can easily retry payments that are returned, and we can avoid connectors that consistently fail to complete the payments.

 

Connectors cannot reverse transfers once they have been put on hold. Ledgers will keep the funds on hold until either the condition fulfillment is submitted or the timeout is reached. If you have more questions about this, please ask because this is a very important aspect of Interledger to understand.

 

Introducing a new role called a notary, where there is one notary for each part of the transaction to verify the digital signature, adds another degree of complexity, without really improving security, because a "notary" can also be malicious and in collusion with a connector.

 

Atomic mode relies on being able to trust the notaries. In practice you would either use a highly trusted and impartial 3rd party (the connector is not impartial because they are party to the transaction) or a consensus group involving multiple semi-trusted entities. If you use a consensus group, you are relying on the increased difficulty of having many of the notaries colluding together, so you obviously have to be smart about what group you pick. Atomic mode does add more complexity, which is why it is no longer part of the core ILP, though it can be used between a group of connectors to reduce risk amongst themselves.

 

What I see missing in ILP is a way of incorporating the contract of the ledger as well as the inter-ledger rules into the payment, as is done by systems that use Ricardian contracts, which are open source and public domain and can be used by anybody.

 

A major design principle of ILP is to specify as little as possible about how each ledger should work, so as to enable support for a wide variety of ledgers. The security model of ILP ensures that you are not exposed to risk from participants in a payment other than your ledger. You can choose whatever ledger you like, whether it's a blockchain or not, so we assume that for whatever reasons you do trust your ledger (but no one else).

 

Second, we are missing the ability to include an arbitration clause, so that if any of the parties in the chain of connectors default, cheat, lie or fail to execute, the dispute can be efficiently resolved by human judgement in a jurisdiction that all parties agree to.

 ...And here we see the third missing part of ILP. There needs to be a standard way of identifying an account holder who has agreed to the rules, and therefore can be subjected to arbitration.

 

Your last couple of points focus on the fact that there is no arbitration built into ILP and little to nothing in the way of "scheme rules". This is correct and intentional. Let me explain some of the logic behind this.

 

Interledger is designed to be used in a layered protocol architecture, similar to how the Internet was designed. Getting people to agree on things is difficult so you want to try to minimize what everyone needs to agree upon. Interledger does not include identity information or dispute resolution because these vary greatly by use case, jurisdiction, ledger type, and a number of other factors. If we want a truly neutral inter-ledger payment protocol, it must be agnostic to these details. This also means that on the Interledger layer, payments must be treated as final and irreversible, because not all payment systems support the behavior you would need to implement reversals (see below on how you would implement reversals at a higher level).

 

In most cases you would probably use Interledger within a higher-level scheme. A scheme for retail payments would likely include sender and receiver identity information (and a standard for how that is expressed and rules around what is required). The scheme might also include clauses around arbitration and payment reversals. Reversals would be handled as new interledger payments going from the receiver to the sender, and the scheme rules would determine when these are required/supported.

 

Now, why put all these details into a higher level scheme? What I just described was what you need for retail payments. Large bank-to-bank transfers will require different information, in a different data format. Micropayments, where privacy becomes a bigger issue (because you don't want to tell someone who you are just to send them $0.001), would likely entail much less information. By separating the concerns, we can make vastly different payment systems fundamentally interoperable, and then work later on coming up with the use-case-specific higher level protocols needed to exchange all the other details needed.

 

What Interledger provides is:

• a method for securing multi-hop payments such that the sender gets cryptographic proof the recipient has been paid or their money back
• a model for understanding interledger payments as a series of ledgers and connectors, which can be clearinghouses, bilateral credit relationships, market makers, or exchanges
• a standard for a ledger-independent address format and packet data format that enables connectors to route payments
• a framework for designing higher level use-case-specific protocols

Best,

Evan

 

[mDuo13]

Test your ILP knowledge: Read the original post by Ken Griffith and see how many points you can address without looking at the cheat sheet (Evan's reply)! =)

[tommytrain]

Test your ILP knowledge: Read the original post by Ken Griffith and see how many points you can address without looking at the cheat sheet (Evan's reply)! =)

Link please, I've been on a boat for 6 hours and may have cooked my brains with the sun but will try.


Sent from my iPhone using Tapatalk

[mDuo13]

9 hours ago, tommytrain said:

Link please, I've been on a boat for 6 hours and may have cooked my brains with the sun but will try.


Sent from my iPhone using Tapatalk

the quote in getitdone's post above, vs. the quote in Dizer's post above.