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

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

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.

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-
> sends-blockchain-transaction-across-7-different-ledgers/ ;
> https://www.slideshare.net/Interledger/interledger-
> workshop-berlin-1-june-2017/120
>
> [2] https://github.com/interledger/rfcs/blob/
> 51ef3d02e943dcd3cbac8fe4442f6a5961441cf8/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
>