Re: Vetting connectors (was Interledger and Privacy)

Thanks for the input and clarification, Evan. *The bank to bank case* is
pretty much what I was imagining where, as you said, connectors are
imagined to be enterprise-grade, well known, and able to handle large
amounts of volume. Atomic mode for connectors would be great for this use
case.

*For non-bank use cases*, I see a role for using *public* distributed
ledgers that are *AML/KYC compliant* and with *verified* users directly
engaging in transactions on the network (basically wallet to wallet
transfer). Ripple Consensus Ledger (RCL) is an ideal candidate for such
usage. If I'm a verified individual sending funds of any type to another
verified individual, then I don't see a need for a connector if we are both
on the RCL ledger. The problem here of-course is how to get critical mass
of individual users to use RCL in the first place. This is a business
development problem, not a technical problem, nor is it a security/legal
problem (since the ledger is public, transactions are traceable, and users
verified). There are a whole host of ways to solve the business development
problem. I wrote a personal analysis on that.

If my understanding is incorrect, please correct me.


On Wed, Oct 28, 2015 at 7:04 PM, Evan Schwartz <evan@ripple.com> wrote:

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