Re: testnet entry/exit nodes and client-side receivers

Hi Adrian,


On Tue, Jul 18, 2017 at 11:37 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> The entry and exit terminology is confusing IMO. Do you mean entry and
> exit into the crypto-currency ledger?
>

No, I actually use the terms the other way around. So I agree then that
it's very confusing. :)


> The nature of ILP means that a receiver needs to be active and online to
> be able to generate the fulfillment for a payment when it is received. The
> only way I see to simplify that is to delegate it to a trusted receiver.
>

There is another way, you can run the receiver on your smartphone. It needs
to receive a network notification when a payment comes in (no need and no
time for user interaction, unless maybe if the user is really quick), and
posts back the fulfillment, generated using a private key that never leaves
the phone.

And you can't (reasonably) run an spsp end-point on your phone, so that's
why I was thinking about other options.

It's not so relevant if the last hop is over five-bells, because then you
can indeed delegate the fulfilling to the party who runs the ledger. But
for blockchain ledgers, you don't know which miner will mine the block
containing your incoming transaction, so you don't have any already-trusted
party to delegate the fulfilling to.


>
> If you are going to delegate it then why not just use SPSP as is and let
> the trusted receiver assign you an address.
>
> As an example, imagine I want to receive payments via Interledger but I
> want them deliver to a Bitcoin address (and only I have the private key for
> that address). I don't want to run an SPSP receiver or even an ILP node.
>
> Instead, I sign up with an exchange like Gatehub for an account and they
> allocate me an SPSP address: adrian@gatehub.com. I log into Gatehub and
> configure my wallet to deliver all my incoming payments to my personal
> Bitcoin address.
>
> Whenever an SPSP payment is made to adrian@gatehub.com, all the SPSP
> receiver functions are performed by Gatehub and when the funds are
> delivered Gatehub pays them to my Bitcoin address.
>
> The same could said for any other integration. I can link any of my other
> online identities to that SPSP address so I can have a Slackbot that accept
> payments or a WhatsApp app or any other disconnected channel. Simply being
> connected isn't enough, the receiver needs to be able to process a payment
> within seconds. If there is a need for a human to accept the payment then
> you lock up all the liquidity of the payment.
>
> Perhaps and interesting idea would be a protocol that explicitly supports
> a delegated receiver model? I have a pre-shared key that I negotiate with
> the sender but I request that they send the key with the payment, encrypted
> using the public key of my delegated receiver.
>
> That way I only need to be online during the setup of the payment not
> during the actual payment itself. I could even use an Interledger Payment
> Request to request a payment that could be paid any time in the future.
>
>
> On 18 July 2017 at 10:45, Michiel de Jong <michiel@unhosted.org> wrote:
>
>> Hi all,
>>
>> I wanted to open up a discussion to you, which some of us were having a
>> few days ago, but for that I first need to provide some background:
>>
>> *Testnet*
>> As discussed in the last community call, we started building a testnet.
>> You can now choose whether you want your node's home ledger to be part of
>> the live network (prefix `g.`) or of the testnet (prefix `test.`). We ask
>> everybody who runs a connector to situate their connector firmly on one
>> side of that divide, so either you connect only between `g.` ledgers, or
>> you connect only between `test.` ledgers. We'll probably add a feature in
>> ilp-kit to make it impossible to violate that rule from the admin UI, but
>> if you run a home-grown connector implementation, or edit your server
>> config via ssh, then please apply that rule manually.
>>
>> *Entry/exit nodes*
>> You may have heard about the 'seven ledger demo' which took place at the
>> last Interledger workshop.[1] These new interledger plugins allow two
>> things: first, they allow two peers to use a ledger-backed HTLA. [2] But
>> they also allow a connector to connect someone's personal ledger to one of
>> the crypto-currency ledgers, as such! So not just one-to-one, but
>> one-to-many (exit) or many-to-one (entry). However, doing this on the live
>> net would mean you need to be careful who pays via your connector from a
>> personal ledger to a crypto-currency (exit node) and who pays from a
>> crypto-currency to a personal ledger (entry node). Running such a connector
>> could have different legal implications in different countries. That's why
>> it's easier for us as a community of researchers and open source
>> enthusiasts to add such entry/exit nodes to the Interledger testnet,
>> connecting the various testnets of various crypto-currencies. That way, we
>> create a 'testnet of testnets'. :)
>>
>> *Connector discovery*
>> On a five-bells ledger, connectors can be discovered by requesting the
>> list of recommended connectors from the ledger. Blockchains generally don't
>> provide this feature. Therefore, I'll soon add a list of testnet wallet
>> addresses for entry nodes per crypto-currency on https://connectorland.
>> [3] You can then use an Interledger client like [4] to prepare an on-ledger
>> payment from your own testnet wallet to the entry node's wallet, and at the
>> same time send an rpc call to the entry node to initiate the Interledger
>> payment to any destination.
>>
>> *Destination discovery*
>> For addressing destinations, ilp-kit relies heavily on spsp (the
>> user@host.com address format that is translated to an interledger
>> address + a uniquely assigned shared secret). This requires the receiver to
>> run an spsp server (like [5] or [6]) and then identify as
>> user@spsp-server.com. They can then specify their wallet address at a
>> crypto-currency ledger as their Interledger address, which would mean any
>> payment to them would reach that ledger via an exit node.
>>
>> *My point - finally ;)*
>> A different identity system, which does not require the receiver to run a
>> server, may be more appropriate for paying out over exit nodes.
>>
>> I like the WebFinger part of spsp, especially because it's an optional
>> extra layer, but IMHO the requirement for the spsp end-point to be
>> publically addressable is a downside of spsp. Why not just add an
>> Interledger address + a public key into the receiver's WebFinger record,
>> and bootstrap things from there?
>>
>> Then, the receiver could run their software client-side (just on their
>> laptop, publishing just that static public key to their personal website),
>> and we can decouple the tight link which currently exists between
>> interledger nodes and internet servers.
>>
>>
>> Cheers,
>> Michiel.
>>
>> [1] http://www.coindesk.com/interoperability-boost-ripple-se
>> nds-blockchain-transaction-across-7-different-ledgers/ ;
>> https://www.slideshare.net/Interledger/interledger-worksho
>> p-berlin-1-june-2017/120
>>
>> [2] https://github.com/interledger/rfcs/blob/51ef3d02e943dcd
>> 3cbac8fe4442f6a5961441cf8/0022-hashed-timelock-agreements/0022-hashed-
>> timelock-agreements.md
>>
>> [3] https://github.com/interledger/connector.land/issues/20
>>
>> [4] https://github.com/interledgerjs/ilp
>>
>> [5] https://github.com/interledgerjs/ilp-kit
>>
>> [6] https://github.com/emschwartz/cicada
>>
>
>