I have a couple of observations on the Lightning Network.
http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf1. The random value R used for Hashed Timelock Contracts can be replaced by something selected by the sender.
a. Alice is sending to Dave through Bob and Carol
b. Alice has her own secret key, a, and public key, Pa, and looks up Dave’s public key, Pd.
c. Alice uses Diffie Hellman to produce a shared secret, s = H(a[Pd])
d. Alice generates the public side of the lock, Px = s[Pd], and timelocks the contract
e. Later Dave (and only Dave) can generate the private side of the lock, x = s*d, where d is Dave’s secret and * is the product modulo the order of the curve.
f. In this variant Px corresponds to H(R) and x corresponds to R, but Dave is NOT involved until he wants to be (to receive the money).
g. Note that in reality you want s to be unique for each transaction so s = H(a[Pd],m) where m is unique to the transaction. For example the block height.
2. They show transaction graphs with funds being pulled by receiver back up the chain all the way to the sender. A philosophical improvement is to have a protocol that creates a NEW SUB-CHANNEL based on value already locked in the existing channels.
a. Alice is sending to Dave through Bob and Carol
b. The first transaction sets up a sub-channel between Alice and Dave UNDER the values in the channels between Alice and Bob, Bob and Carol, and Carol and Dave.
c. Alice and Dave can now use this sub-channel to transact between themselves (without bothering Bob and Carol) until they decide to close the books and reconcile through the Bob-Carol channels.
d. In the same way normal channels lock value on the main blockchain to enable the channels, sub-channels lock value in channels to enable the sub-channels to transfer value in a trustless manner.
3. I didn’t see any analysis of the limits on total available liquidity that would limit the Lightning Network.
a. Every Bitcoin channel locks up real liquidity. This is unlike modern credit instruments that create liquidity to match demand.
b. With 21 million bitcoins, if every user wanted to create a 1 bitcoin channel, we would be limited to 21 million users. Nowhere near the 7 billion shown on the charts.
c. The only way liquidity can increase is if the value of bitcoin increases, convincing users to lower the values locked in their channels. For example if each channel only locked 3 milli-bits then we could have 7 billion channels.
d. I’m not sure what the implication to the Bitcoin network would be if most bitcoins were locked in channels.
Interesting stuff to think about.
