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

Interesting to hear this opinion. RPR
<https://github.com/jtremback/reactive-payment-routing> is specifically
designed to preserve the privacy of the sender and the receiver. The sender
sends the receiver a routing message with the payment's amount, and release
condition (or "hashlock"). The receiver gossips it out to the rest of the
network, who pass it along, updating the amount to add their fee. At some
point the sender gets it back, and sends the actual payment (the
preparation phase) along the path that offers the best rate.

In this scheme, no intermediary node even knows who the sender and receiver
are. And the sender and receiver don't know any of the intermediary nodes
except for their immediate neighbors. Clearly, this is not good for anyone
who needs to comply with regulations! But it could be useful beyond
privacy. Since nodes are determining the path in real time, they will be
able to give the best possible price. This could be good for distributed
exchange type things, where nodes might be moving large amounts of their
liquidity in and out of different asset types.

The tradeoff, of course, is a very high volume of routing traffic as
routing messages are gossiped around the network.

For a node to determine the best path with a source routing type setup
(either the nesting or non nesting proposal phase), they need to be kept up
to date on prices being offered by all the nodes in the network. This could
be done with a central server, or a gossip system. It's hard to say whether
the approach I outlined above would be better or worse than source routing
in different situations.

Anyway, I'm glad that ILP will be made flexible for different routing
approaches. This way it can support anything from a full proposal phase,
with the sender contacting each intermediary node, to a nested proposal
approach, to a fully distributed gossip based approach.

On Wed, Mar 16, 2016 at 1:07 PM, Evan Hubinger <evanjhub@gmail.com> wrote:

> 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
>