- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Mon, 19 Sep 2016 11:33:27 -0700
- To: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CABG_PfRLEZ27JpcY4h9HvTaKAML_H2_J_+hM8Pd_A6w0jHh6tQ@mail.gmail.com>
---------- Forwarded message ---------- From: Ken Griffith <kengriffith@gmail.com> Date: Mon, Sep 19, 2016 at 9:18 AM Subject: Re: ILP - a critical analysis To: Jehan Tremback <jehan.tremback@gmail.com> Thanks for these comments, Jehan. That is a very good explanation. I am assuming that Alice is the user with an account with ledger A who is initiating the transaction, and Bob is the user with account at ledger D who is receiving the payment. One question I have is how does Alice know what the total transaction fee will be, if the funds must transfer in reverse order from D back to A? In the original escrow payment instruction to 1, presumably the amount paid to D must be specified as an exact amount. This in turn requires an exact amount paid to 1 which includes all the premiums or fees for 1-3 and A-D. So to make the first payment, we must have exact knowledge of the rates down the entire chain. I presume this is why the protocol has a "quoting" component that precedes the transaction instruction. This requires the connectors to make offers that remain valid for a certain period of time, irrespective of changing market conditions. This exposes the connectors to exchange risk if Alice gets the quotes and then waits until the last second to execute her payment. I see a simpler and cheaper way to achieve this by paying in forward order, with no escrow, using market-based clearinghouses in the place of 1, 2 and 3. Alice would not be able to get a firm price quote in advance, she would only be able to get the current market price and maybe an average over the previous X minutes or hours. Alice could limit her exposure to gouging by placing a limit order, meaning her payment would only be fulfilled at the same or better price that she has specified. But it might take longer to fill the order, or if her limit is too tight, her order might stall at some point along the chain. A second advantage of this method is that all fees are treated as premiums, so you don't have to deal with both transaction fees and exchange premiums. A forward paying arrangement is no more risky than the reverse order payment. A clearinghouse/connector could still default. But the risk would fall entirely on A not one of the counterparties in the middle of the chain. Dispute Resolution The legality of a funds transfer across multiple jurisdictions is a nightmare in today's world of highly regulated financial institutions. Any ledger that exists in meatspace, like a bank, will be subject to regulations concerning identity of recipients of funds. That can be solved with an arbitration contract. Without such a contract to bring the entire payment chain under one dispute resolution framework, there cannot be any effective dispute resolution because each party is in a different jurisdiction. This has proven to be the real achilles heel of internet payment platforms over the past 20 years. It probably deserves a longer conversation in its own right. As for Bitcoin solving the trust problem, I disagree with you, Jehan. Yes, it uses keys for payments on the ledger. But it requires a more classical financial institution to provide exchange portals to the rest of the economy. People in the Bitcoin community have failed to understand the Five Parties Model, so they build and use exchange portals and platforms that require far too much trust in one person and have no transparency or accountability. Thus the vast majority of Bitcoin theft has been through and by exchange portals. This means that Bitcoin as an ecosystem has a gaping flaw that has not been adequately addressed to date. The five parties model is pretty simple, and would work well with tools like multi-sig. Ripple/ILP is proposing/building a network of connectors which are basically exchange portals or clearinghouses. This has been the achilles heel of the digital currency sector, so it stands to reason that this problem needs to be thoroughly thought through, or else we will see more of the same - exchange failures. Ken Griffith On 9/19/2016 6:42 PM, Jehan Tremback wrote: > You raise some good points, but I don't think that you understand ILP. I > don't blame you, as the white paper is very dense and not especially > concerned with human readability. I didn't understand ILP either, until > I came to see it as a type of multi hop payment channel. > > First of all, ILP works with escrows, in the broad general sense of the > word. I'm not familiar with the intricacies of the banking system, but > wikipedia defines escrow as "Escrow generally refers to money held by a > third-party on behalf of transacting parties". > > I'll try to explain ILP's "Universal" mode. "Atomic" mode is the one > with the notaries. I think that Universal mode is much more fundamental > and important. > > 1 2 3 > / \ / \ / \ > A B C D > > The numbers are ledgers and the letters are connectors. Let's say that A > wants to send $10 to D. > > A places the $10 in escrow with 1, along with the instruction "Release > this $10 to B, if B shows a signature from D to you and A. If 1 day goes > by and B has not shown the signature, give the money back to A". > > B and C then also place $10 in escrow with 2 and 3 respectively, with > similar instructions. > > Now D is notified that the transfer has been set up. D sends his > signature to 3, claiming the funds. 3 shows the signature to C, who uses > it to claim the funds from 2. 2 shows the signature to B, who uses it to > claim the funds from 1. > > In this transaction, every connector only needs to trust the ledgers > they are directly connected to. Let's look at some failure scenarios. > > Let's say that 2 is dishonest. B places the $10 in escrow with 2, but > when C shows the signature, 2 refuses to release the funds to C. Now C > is out $10. C shouldn't have trusted 2. > > Further down the chain, if B got the signature even though C didn't get > the funds, B can use it to get the funds from 1. In this scenario, A has > paid $10 and D has still received $10. > > On the other hand, if B doesn't get C's signature, then B can't release > the funds. The escrow that 1 has for A expires after 1 day, and the > money is given back to A. In this scenario, D has still received $10, > but A has not paid $10. 2 has stolen $10 from C, and A has benefitted > from this as well. > > But, in both scenarios, the only people who were affected by 2's failure > are B and C. ILP insulates every step in the transfer chain from the > others. Trust connects every link in the chain, without anyone having to > trust the whole chain. > > If you can point out a way in which this mechanism could be subverted, > it will make headlines, as this is the same mechanism used in many > different types of multihop payment channel, such as Bitcoin's Lightning > network and Ethereum's Raiden. Here's a slightly more involved > explanation from my > blog: http://altheamesh.com/blog/universal-payment-channels/. > > > To address some of your other points: > > [...] 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 [...] > > Wrong. Bitcoiners have solved the trust problem. If you use Bitcoin as > intended, with your own wallet and a strong passphrase, it will not be > stolen. The problem that Bitcoiners have not solved is the usability > problem, and it's such a pain in the ass to deal with those wallets and > passphrases that people send their money to be held by a third party > exchange or wallet, who then steals it. > > 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. > > 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. > > 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? > > These are actually good points, and maybe someone can get to work > defining a legal framework, or record keeping system or something. But > the beauty of ILP is that each link in the chain only trusts those that > it is directly connected to. Because of this, one ILP transfer could > cross over several jurisdictions and legal systems. This means that it > is inappropriate to bake any one regulatory regime into the low-level > cryptographic ILP protocol. > > -Jehan > > On Mon, Sep 19, 2016 at 7:01 AM, Ken Griffith <kengriffith@gmail.com > <mailto:kengriffith@gmail.com>> wrote: > > 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 > <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 > <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 > <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 > <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 > > On 9/19/2016 2:24 PM, Melvin Carvalho wrote: > > > > On 19 September 2016 at 13:04, Stefan Thomas <stefan@ripple.com > <mailto:stefan@ripple.com> > <mailto:stefan@ripple.com <mailto:stefan@ripple.com>>> wrote: > > 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. > > > Agree with most of this, however im not convinced that ILP is the > simplest protocol. Webcredits is IMHO simpler. I do however > like the > move to modularize it into more simple pieces. But it might > come across > better if if you continued your narrative along the lines of "we > believe > that ... " > > I have slight reservations about the scalability of ILP (e.g. > can you > send to and from an email address, a mobile phone, a web page, an > IM > account, irc etc.). What I really love about it is the concept of > connectors. As you point out much more will be clear when real ILP > payments are live, which Im confident is an achievable goal. > > > > 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. > > On Fri, Sep 16, 2016 at 6:13 PM, Christopher Bartley > <morelazers@gmail.com <mailto:morelazers@gmail.com> > <mailto:morelazers@gmail.com <mailto:morelazers@gmail.com>>> > wrote: > > Sorry to chime in out of place but I think that this > post by a > Ripple employee may help to clarify > > (http://www.xrpchat.com/topic/1991-a-big-update/?do=findComm > ent&comment=18189 > <http://www.xrpchat.com/topic/1991-a-big-update/?do=findComm > ent&comment=18189> > > <http://www.xrpchat.com/topic/1991-a-big-update/?do=findComm > ent&comment=18189 > <http://www.xrpchat.com/topic/1991-a-big-update/?do=findComm > ent&comment=18189>>) > My understanding is that ILP among the banks is not > RCL-enabled > and serves as an internal subledger for each bank to escrow > funds prior to transfer. Because the transactions are not > submitted to RCL they are private and do not appear on the > public ledger. My understanding is that the publicly > announced > banks are already using it to transfer fiat or will be > will be > very soon. Deploying ILP privately will allow them to > integrate > with other private networks or public ledgers should > they chose, > but for now it's effectively a private and permissioned > ledger > using ILP within network. > > I'd still appreciate a response from Stephan and Adrian, > especially if I'm way off here. > > Best, > > Chris > > Sent from Das Fone > > > On Sep 16, 2016 10:01 AM, "Roger Bass" > <roger@traxiant.com <mailto:roger@traxiant.com> > <mailto:roger@traxiant.com <mailto:roger@traxiant.com>>> > wrote: > > Stefan or Adrian: > > are you able to say publicly which banks will be moving > transactions over ILP come October 1? > > Presumably, this means that a version of Ripple > Connect with > ILP as a "protocol switch" is already shipped and > deployed > to those banks, right? > > Best, > Roger > > > On Thu, Sep 15, 2016 at 8:21 PM, Daniel Bateman > <7daniel77@gmail.com <mailto:7daniel77@gmail.com> > <mailto:7daniel77@gmail.com <mailto:7daniel77@gmail.com>>> wrote: > > Thank you for this clarification Stefan. > > Is this information published on the Ripple website > and/or Ripple wiki? If not, may I ask why not? > > Best, > Daniel > > On Sep 15, 2016 7:05 PM, "Stefan Thomas" > <stefan@ripple.com <mailto:stefan@ripple.com> > <mailto:stefan@ripple.com <mailto:stefan@ripple.com>>> wrote: > > What the article is referring to is that > Ripple's > bank customers will be moving real money > through > ILP-powered Ripple products starting Oct 1st. > > Note that we were developing ILP internally > for some > time before we decided that it should become > open > standard and released the white paper. For > now the > commercial implementation of ILP inside of > Ripple > products and the open-source work happening > in this > group are pretty separate. We're getting > really good > ideas and feedback from the banks using ILP > and that > feeds back into the community group work. And > of > course the end goal is to have it all > interconnect > some day. > > It'll take quite some time (and a lot of > community > traction) before the banks would even consider > connecting to a public Interledger. Hence the > importance of the work this group is doing > that's > unrelated to Ripple. For it to be a true > standard > there has to be lots of activity around it that > isn't directly tied to us or our customers. > > On Thu, Sep 15, 2016 at 2:22 PM, win than aung > <winthan@chomeaye.com > <mailto:winthan@chomeaye.com> <mailto:winthan@chomeaye.com > > <mailto:winthan@chomeaye.com>>> > wrote: > > Hi guys, > > I just saw this news > - > http://www.afr.com/technology/nab-westpac-part-of-ripples-ne > w-global-payments-network-20160915-grgz81 > <http://www.afr.com/technology/nab-westpac-part-of-ripples- > new-global-payments-network-20160915-grgz81> > > <http://www.afr.com/technology/nab-westpac-part-of-ripples- > new-global-payments-network-20160915-grgz81 > <http://www.afr.com/technology/nab-westpac-part-of-ripples- > new-global-payments-network-20160915-grgz81>> > > Ripple has created Ripple Connect, new > technology to allow banks to talk to > each > other, and is developing its > "interledger > protocol", which will go live on > October 1 > and provide the foundation for banks to > directly connect their ledgers with > each > other without an intermediary. > > > Is that ready to go live on Oct 1? Which > ledgers > are going to try out at live on Oct 1? > Gatehub? > any hints? > > Thanks, > Winthan > > > > > > > >
Received on Monday, 19 September 2016 18:33:58 UTC