Re: Vetting connectors (was Interledger and Privacy)

Yes. ILP can be a gateway for RCL mass adoption eventually, not right away.

In the short to medium term, if all the ledgers are allowed to compete
fairly for the connector/market-maker business, then the ledger that offers
the most efficiency, security, and desired features such as SusPay and
speed at the lowest transaction cost will be used the most. RCL has an
excellent chance of being that ledger, provided of course Ripple continues
developing it and de-centralizing the network through adding additional
validateor nodes strategically positioned in different parts of the world.

Then in the longer term, as RCL gains more and more usage, transaction
volume and liquidity flow through winning the connector race/business, I
see it gradually gaining trust and credibility among the public. at that
point, you might see significant increase in the number of individual user
wallets on the network. These wallets will start sending funds among them
in addition to the institutional usage through ILP/market-makers. As that
happens, user centric gateways will start popping up on the RCL network
recognizing the business potential. The network at that stage will be
teaming with both bank to bank and user to user transaction activity. There
may be a tipping point where user to user activity will eventually exceed
the bank to bank one, but it would take few years for that to happen.

This is all of-course visioning on my part. Nobody knows the future, but I
see it as very plausible from everything I've been reading about this space
in general and Ripple in particular.


On Thursday, October 29, 2015, Arie Y LEVY COHEN <arielevycohen@gmail.com>
wrote:

> Not all banks are created equal and enjoy the benefits of being large
> money center banks with global footprints. These are the institutions that
> might benefit the most from a system that allows them to interoperably
> connect to any other bank using any ledger thru a "trusted" connector w/o
> having to use various correspondent banks to hop thru (fee considerations
> and liquidity constraints included)...So, wouldn't these banks be the types
> that might require a vetting system (at least at first) so they can build
> reputation and trust amongst the big boys and their peers?
>
> As for you observations on RCL, I may have misunderstood, but are you
> looking at ILP as a gateway (no pun intended) for RCL mass adoption?
>
> --
> Heritage & Legacy Advisory | Multi-Generational Wealth Preservation
>
> Arie Y. LEVY-COHEN
> FINANCIAL ADVISOR | INTERNATIONAL CLIENT ADVISOR
> PRIVATE WEALTH MANAGEMENT | NEW YORK
> ECONOMICS | FINANCE | BLOCKCHAIN
> P: 917.692.6999
>
> On Oct 28, 2015, at 9:45 PM, Yassin Mobarak <ymobarak@gmail.com
> <javascript:_e(%7B%7D,'cvml','ymobarak@gmail.com');>> wrote:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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>
>>
>
>