testnet-of-testnets

testnet-of-testnets.md

Faucets:

• btc https://testnet.manu.backend.hamburg/faucet
• xrp https://ripple.com/build/ripple-test-net/
• eth https://www.rinkeby.io/
• ltc http://ltc.makejar.com/
• zcash https://faucet.testnet.z.cash/

baseline: pay to any testnet

• pay a deposit from sender to connector, which will only be used to cover costs of rolled back payments
• that sender now has a balance at that connector, and can make on-ledger conditional (escrow) payments to any receiver.
• no kyc of sender/receiver because it's just testnets
• if a payment fails, you need to make a new deposit
• advantage: simple
• downside: on-ledger is slow and expensive

step 1: baseline connector

• one connector can provide this service
• it can be multi-threaded
  • each thread would concentrate on a ledger probably, to see notifications
  • incoming-prepare -> read packet, forward, store in redis
  • incoming-fulfill -> find way back from redis, fulfill there
• exchange rates determined by the connector's current balance on source/destination ledger

step 2: multi-hop

• add PluginVirtual as one more ledger type
• multiple connectors can now peer over PluginVirtual
• each connector now only needs to support one ledger (but can still support all of them if they want)

step 3: end-to-end

• publish nodejs cli sender
• publish nodejs cli receiver
• peer with two or more ilp-kits
• (option 3a:) set up one cicada on each ledger, for spsp test payment support
• (option 3b:) add psk-dh-webfinger support to ilp-kit, so money actually reaches receiver, not their "dial-up" provider

step 4: routing

• at least two competing connectors on each testnet
• core nodes use route broadcasts
• periphery nodes use quote requests
• route selection:
  1. next connector is trusted (binary decision)
  2. no other route satisfying i. was announced to be shorter
  3. no other route satisfying i. and ii. was announced to be cheaper

step 5: sender-paychan

• sender communicates with connector over server-to-server rpc
• the sender can open a one-directional payment channel to the connector
• pay the first hop by sending claims in response to fulfill
• delivery to the receiver is still on-ledger

step 6: receiver-paychan

• sender communicates with connector over server-to-server rpc
• if you want to become more easily payable, pay a deposit and rent a one-directional payment channel from the connector to you
• the connector will now pay you over rpc with claims, it's up to you to submit them to the ledger when you want to cash out
• some price per dollar-hour of money on hold (channel value - highest claim value)

step 7: bidirectional-paychan

• your own payout has a delay and a locked outlet; when sending a worse claim, you give up your better claim by giving its key
• this is what lightning does
• it allows two peers to keep a channel open for longer

continued in the wiki: https://github.com/interledger/interledger/wiki/Testnet-of-Testnets-design