Re: Non-source routing (was "failures during the preparation phase")

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