Re: Vetting connectors (was Interledger and Privacy)

Yassin....of course, all we are doing is sharing POV's in a consensus
styled format.
Your visioning, as I read it would indeed be a very good outcome for the
ripple protocol~!


--

Heritage & Legacy Advisory | Multi-Generational Wealth Preservation

ARIE Y. LEVY-COHEN
FINANCIAL ADVISOR | INTERNATIONAL CLIENT ADVISOR
PRIVATE WEALTH MANAGEMENT | NEW YORK
ECONOMICS | FINANCE | BLOCKCHAIN TECH
P: 917.692.6999

On Thu, Oct 29, 2015 at 7:50 AM, Yassin Mobarak <ymobarak@gmail.com> wrote:

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