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

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