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

Yes, got it, sorry. In channel terms, this fee could be seen as a fee for
creating the channel in the first place (as Interledger transactions are
similar to a one-time-use channel).



On Tue, Mar 1, 2016 at 3:11 PM, Evan Schwartz <evan@ripple.com> wrote:

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