Re: Pathfinding and data collection (left-over question from the workshop)

> In a multihop payment channel this is not possible, as the fee simply
consists of the connector receiving a higher payment from the source than
it pays to the destination.

True, if you neglect the value of money over time. If these transactions
are very large, which is what atomic mode is meant to be used for, then
putting a million dollars on hold can be costly for a connector, because it
severely limits what other transactions it can take part in while it's
required to put such a large amount of funds on hold. Thus, a connector
might require an upfront fee for very large transactions, and it is this
fee that a malicious connector could run away with.

> A connector could also resolve hashlocks on a first come first serve
basis, not holding funds in reserve.

No, because the hashlock is created on the _ledger_, not on the connector.
If a ledger wants to able to guarantee its hashlocks, it needs to require
that the sender put the necessary funds on reserve first. This is a key
feature because it means that no connector ever need trust any other
connector, only the intermediate ledgers. That being said, the ledger would
likely behave similarly to how you describe, in that it would set up
hashlocks on a first-come-first-serve basis, but, in atomic mode, no
further hashlocks in the chain would be created until the one before it had
been set up, ensuring any failure occurs before funds start moving, and
thus making the transaction fully atomic (why it's called atomic mode,
after all).

On Tue, Mar 1, 2016 at 11:59 AM, Jehan Tremback <jehan.tremback@gmail.com>
wrote:

> > Second, if the connectors charge fees, a malicious connector could run
> off with the fees.
>
> Can you explain this a bit more? In a multihop payment channel this is not
> possible, as the fee simply consists of the connector receiving a higher
> payment from the source than it pays to the destination. If the destination
> is not happy with the amount it is receiving, it can withhold the hashlock
> preimage.
>
> Of course, the connector risks setting up a hashlocked payment, possibly
> making some funds unavailable for some time, and then not getting the
> hashlock secret. However, this is a choice by the connector to "set aside"
> funds that are to be used in a currently unresolved hashlock payment. A
> connector could also resolve hashlocks on a first come first serve basis,
> not holding funds in reserve. This would result in the connector having a
> higher failure rate, but having all its funds available at all times.
>
> On Tue, Mar 1, 2016 at 11:41 AM, Evan Schwartz <evan@ripple.com> wrote:
>
>> Wouldn't the connector that does the least risky pathfinding be the
>>> largest connector with the most data about other network paricipants
>>> behavior?
>>
>>
>> ILP reduces the risks posed by faulty connectors down to the following
>> two. First, a connector can cause a payment to roll back, forcing the
>> sender to try again with a different path (likely excluding that faulty
>> connector) and delaying the successful completion of the payment. Second,
>> if the connectors charge fees, a malicious connector could run off with the
>> fees. Effective pathfinding approaches/services need to keep track of
>> connectors' past performance in order to route around bad ones.
>>
>> As with all pathfinding questions, the best way to approach this depends
>> on the topology of the network. If there is a relatively closed network
>> with few connectors operated by the same parties as the ledgers, I wouldn't
>> expect this to be much of an issue. If it's a very open network with many
>> connectors to choose from this will be an issue for pathfinding protocols /
>> services to address -- and that's a problem I'd love for us to have.
>>
>> --
>> 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