W3C home > Mailing lists > Public > public-interledger@w3.org > October 2015

Re: Vetting connectors (was Interledger and Privacy)

From: Evan Schwartz <evan@ripple.com>
Date: Thu, 29 Oct 2015 09:04:28 +0900
Message-ID: <CAONA2jW+--7iaWn6BmT4wkMH0wZrzZdR=9ZjXdgA=ZmSNkCYWg@mail.gmail.com>
To: Lucas Huber <lh@codoo.io>
Cc: public-interledger@w3.org
Both Atomic and Universal modes ensure that the connectors cannot steal the
sender's money. (Note that connectors are the intermediaries facilitating
cross-ledger payments -- that does not include intermediary ledgers) The
worst that a malicious connector can do is a) run away with the fees (which
I anticipate will be a very small fraction of the payment's value) or b)
delay the payment by causing the sender's first attempt to fail and making
them retry with another path.

Re: who the "user" is, I would separate bank to bank use cases from ones in
which we're talking about individuals acting directly as the sender.

For bank use cases, I would imagine that they will primarily use Atomic
mode using notaries that are run by well-known institutions (financial
institutions, governments, industry associations). Connectors will likely
all be financial institutions. In this case, I would guess that vetting the
parties will happen in somewhat similar ways to today. The main difference
would be that banks should actually have to do less due diligence on
connectors than they do on correspondent banks today because, unlike in the
current system, they can inspect individual payment paths before money
moves to ensure they are compliant. Real-time compliance checks should
allow banks to accept more connections with slightly less trusted entities.

For non-bank use cases, I would guess that most payments will use the
Universal mode, without notaries involved. Data on the past performance of
connectors would help senders avoid picking connectors that are likely to
try to run away with their fees or simply fail and make the sender retry
their payment. I wonder how serious a problem this will be, or if it could
be something handled by whatever service the sender uses for pathfinding
(maybe built into the client for their payment system). What do you all
think?

On Tue, Oct 27, 2015 at 4:58 PM, Lucas Huber <lh@codoo.io> wrote:

> Yes trust has to be related to the notaries in the atomic mode and not
> from the connectors. As I understand connectors are merely relaying  the
> informations to one trusted entity to another (sender ledger -> receiver
> ledger). But they can charge fees what is in some way a mean, that is
> normally performed through trusted entities. Nevertheless connectors will
> in reality often be highly trusted entities, but this trust is not grounded
> in the protocol but from other aspects eg. as kind of organisation they
> represent.
>
> The first question that is important to me is how ledgers, connectors and
> notaries know from each other and from where they get the information of
> who is connected to whom? From my point of view we should have an idea
> about this matter before we are going to deep into others. ILP needs, as
> the internet does, a kind of name-service (DNS).
> My opinion about that is using a distributed ledger among all the
> participants (ledgers, connectors, notaries) and using public keys as
> identity provider.
>
> So far I would see that this ledger could contain the following
> information:
> (speed and reputation are optional and need smart algorithm to work
> properly!)
>
> *Items*
>
> *Type*
>
> *keys*
>
> *IP/port*
>
> *Remarks/name*
>
> *speed*
>
> *reputation*
>
> *connections*
>
> Sender ledger (A)
>
> exchange
>
> key-A
>
> 234.011.002.121:?
>
>
>
>
> key-x
>
> Recipient ledger (B)
>
> exchange
>
> key-B
>
> 034.211.102.141:?
>
>
>
>
> key-z
>
> Connector X
>
> conn
>
> key-x
>
> 123.011.042.211:?
>
>
>
>
> key-A,..y
>
> Connector Y
>
> conn
>
> key-y
>
> 241.011.302.116:?
>
>
>
>
> key-x,..z
>
> Connector Z
>
> conn
>
> key-z
>
> 189.111.002.121:?
>
>
>
>
> key-y,..B
>
> Notary N
>
> notary
>
> key-N
>
> ?
>
> For escrowed transactions
>
>
>
> Key-A,..x
>
> Regulator
>
> regulator
>
> key-R
>
> ?
>
> Optional if needed
>
>
>
> key-z
>
> note:
> Using a distributed identity ledger would not mean that there is only one
> global ledger as such. Different types of ILP networks can or should use
> different identity ledgers.
>
> * <http://moneygrid.net>*
> Am 26.10.2015 um 21:56 schrieb Brian Walden:
>
> I second Yassin, could we clarify terms? I'm sorry, I'm new here and may
> have missed some of the background conversation, but I thought the whole
> point of ILP is to connect ledgers in such a way that the connectors do not
> need to be trusted? Is the vocabulary slightly different here than in the
> whitepaper? Does connector refer to any ledgers traversed as a payment goes
> from sender to recipient?
>
>
>


-- 
Evan Schwartz | Software Architect | Ripple Labs
[image: ripple.com] <http://ripple.com>
Received on Thursday, 29 October 2015 00:05:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 00:05:27 UTC