Re: Vetting connectors (was Interledger and Privacy)

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