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](https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/)
* it allows two peers to keep a channel open for longer