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

Connectors may want to charge additional fees on top of the spread they
make if the payment goes through just to cover the cost of locking up their
liquidity. If a payment is rolled back the connector may have incurred some
cost or missed out on facilitating other payments with that money that was
escrowed. They may also want to discourage people or potential attackers
from tying up too much of their liquidity in payments that may fail by
charging for the service of escrowing the funds. Connectors could even set
the fee to lock up funds higher and then "refund" some of it by charging a
lower spread. In any case, I would expect these fees to be orders of
magnitude less than the value of the payment and if connectors can figure
out other ways of handling these risks they may make themselves more
competitive by not charging.

For ILP money must be escrowed for a specific transaction because we
wouldn't want a connector to offer to facilitate lots of payments and then
be unable to if all of them go through. Connectors could get credit from
their ledgers if they want to be able to facilitate more payments than they
have in deposits with the ledger.
On Mar 1, 2016 2:59 PM, "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>
>>
>
>