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

Yup, that's right. It'll be interesting to see how necessary this type of
fee ends up being.
On Mar 1, 2016 6:25 PM, "Jehan Tremback" <jehan.tremback@gmail.com> wrote:

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