- From: Evan Hubinger <evanjhub@gmail.com>
- Date: Wed, 16 Mar 2016 13:07:04 -0700
- To: Evan Schwartz <evan@ripple.com>
- Cc: Interledger Community Group <public-interledger@w3.org>, Jehan Tremback <jehan.tremback@gmail.com>, Xavier Vas <xavier@tr80.com>, mark.germain@germain.consulting
- Message-ID: <CADPXkOF7SS5PkJuwvmqw7fWnvNSWGH7XqwRNDRHkW_R-fjEDNA@mail.gmail.com>
I have a couple of concerns with the nested transfers spec as written. It seems to me that it might be very desirable for a ledger or connector to who else is in the path they're participating in, and precluding that from the spec seems like it might leave out a lot of use cases. Consider the scenario where I am a large bank, and am required by the government to check the credentials of all entities in the path I am participating in. In a layered encryption scenario, that's not possible. Getting rid of the encryption from nested transfers helps, but then you're providing too much information: I only need to know who's in my path, not necessarily all the details of each transaction. The other problem is that I can no longer see the entities before me in my path--one could argue that this is already true, since one could just use two transactions, one to the connector right before me, then one through me--but I think that's missing the point, which is that while one could try to do that, the ledgers and connectors should have the ability to see it and reject it. Another thing that's nice about a proposal phase is that I can request whatever information about a path I want, and then reject the whole thing before anybody has to put any money on hold. In a nested transfers scenario, it would be up to the sender to make sure that the constructed nested transfer will meet the requirements of each party. If one of the entities doesn't approve of the path for whatever reason, instead of failing in the harmless proposal stage, the transaction fails (atomically, of course) after a potentially large number of connectors have already committed funds. That isn't necessarily a bad thing, since ILP is designed to fail nicely in that scenario, but it's still worse than failing in the proposal phase, since there were connectors that had to put funds on hold before the transaction failed. Finally, I think non-source-based routing makes both of these problems even worse. For the first issue, now even if I'm not using encryption, I have no idea what other connectors might come after me in the path since the path hasn't even been fully decided by the time it gets to me. And for the second issue, now not only does the sender have to make sure to check that all the necessary criteria are met, every individual connector has to also, which would likely significantly increase the number of transactions that fail after funds are already put on hold. I think the reasoning behind nested transfers is obvious (speed, statelessness, simplicity, etc.), and I don't think either of my problems is a deal breaker, so I'm not sure what the best solution is. Maybe leave an optional transaction negotiation phase as an option, but not include it as part of the spec? Maybe offload the responsibility of meeting everybody's criteria for participating in a transaction to the pathfinding system, and make sure everybody trusts the pathfinding system? On Wed, Mar 16, 2016 at 12:15 PM, Evan Schwartz <evan@ripple.com> wrote: > Thanks all for the input. I'm convinced that it would make sense to at > least support a variety of pathfinding approaches and you all might be > right that non-source routing will end up being the best option. > > Looking at the original Internet Protocol RFC > <https://www.ietf.org/rfc/rfc791.txt> it's actually interesting to note > that there are fields that allow the source to specify routing information > (look for the "Loose Source and Record Route" and "Strict Source and Record > Route" options). > > Regarding what we called the proposal phase, that's already being removed > from the reference implementation (see five-bells-sender/pull/37 > <https://github.com/interledger/five-bells-sender/pull/37> and > five-bells-sender/pull/43 > <https://github.com/interledger/five-bells-sender/pull/43>). Now, the > sender will still do the pathfinding but it includes the path in the memo > field as described in this Nested Transfers spec > <https://docs.google.com/document/d/1zTLQLBx0p6-Ds9Ki8nCaVBdXUK4mbJZDQOaz83n6VY8> > . > > Supporting non-source-based routing protocols would require additions to > the connector. Anybody want to weigh in on what the best approach for this > would be? > > -- > Evan Schwartz | Software Architect | Ripple > [image: ripple.com] <http://ripple.com> > -- “The true logic of this world is in the calculus of probabilities.” – James Clerk Maxwell
Received on Wednesday, 16 March 2016 20:07:52 UTC