michielbdejong/testnet-of-testnets.md

## testnet-of-testnets.md

      
    Raw
  

              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:

next connector is trusted (binary decision)
no other route satisfying i. was announced to be shorter
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