# Last edited on 2016-02-26 18:42:36 by stolfilocal
# NOT SENT

It *is* insanely convoluted.

The goal started out the same as bitcoin.  Namely, to allow people to send payments by exchanging fully signed but unconfirmed and unbroadcast transactions (let's call them "cheques"), in such a way that no one can cheat by paying with non-existing coins, or payning twice with the same coins -- but without depending on a central authority to enforce that.  Then:

* To make sure that the coins exist, any user (alice) who intends to pay someone  must lock enough coins (5.00) in advance in the blockchain, for that purpose, with proper conditions for release; and wait for the locking transaction to confirm, so that the receivers can check them;

* To avoid the need for a central registry, those locked coins must be addressed to a specific receiver (Bob) who will know about them; and they can be used only to pay that receiver.  That is, the network will consist of a number of payment channels, each channel consisting of some coins locked for payments between two users.

* When sender Alice wants to pay receiver Bob 0.60 BTC, she sends him (not to the miners) a signed transaction that enables him to unlock those 5.00 BTC, sending 0.60 BTC to himself and the return change of 4.40 BTC back to Alice.  If Bob wanted, he could broadcast the transaction  to the miners and get his 0.60 BTC.  That would close the channel.  But Bob can wait for further payments instead.

* When Alice wants to send another 0.90 BTC to Bob, she instead sends another signed transaction like the first one, only that it gives 0.60 + 0.90 = 1.50 BTC to Bob, and return 3.50 BTC to Alice.   This transaction (cheque #2)  is incompatible with the one that Bob already has, because they unlock and move the same coins.  So Bob can get only one of the two confirmed. So of course he would keep only cheque #2, and discard cheque #1.

* Alice can use the same process to send Bob many more payments, up to the 5.00 BTC limit that she locked beforehand.  These payments don't use the bitcoin network (BN) or the blockchain, but are sent through e-mail, Tor, or other direct connection from Alice to Bob.  Therefore they can be as fast as sending a few internet packets between them.  Fast enough to allow micropayments, such as paying per minute of a video stream.

At this point the inventors got all excited, sensing that they had invented a payment system -- that they called the Lightning Network -- that would replace PayPal, Western Union, VISA, and all the banks of the world in one swoop.  They called the press and TV, got interviewed by Oprah, and put their names on the candidate list for the Economics Nobel.  

Meanwhile, the guys at Blockstream were in a tight spot since, since they had promised their investors that they would get billions of bitcoin users with Sidechains, only to find that Sidechains would not scale. When they learned of the LN,they pounced on it, and started to demolish the p2p bitcoin network to make room for it.

But there were still a few problems.

* Alice would only get her 3.50 BTC change back when Bob decided to close the channel.  If she needed those excess coins for some other purpose (e. g. to open another channel with some other user), she would have to ask Bob to please close the channel. She could not be allowed to do that on her own, because she could cheat on Bob by closing the channel with any of the earlier cheques.   But Bob may be lazy and take his time to do it, or may demand ransom to do it, or may be turned into a toadstool by a witch and never close the channel.  So, it was necessary to give an expiration date for the channel: Bob failed to close the channel until a certain date, all the 5.00 BTC would be automatically unlocked and would return to Alice.  That required a new special time-lock intruction added to the bitcoin protocol, and Blockstream promptly obliged with OP_CLTV (aka OP_HODL, aka OP_DARN_I_TYPED_2106_I_MEANT_2016).

* The expiration date in turn created a slight dilemma for Bob.  If he waited until the last minute before the expiration date to close the channel, he might miss it, and lose all of Alice's payments, because of a computer malfunction, or a traffic jam on the BN -- or because the bitcoin transaction fee that Alice included in the last payment, while OK at the time, was no longer sufficient.  On the other hand, if he issued the closing transaction two days before the expiration date, he would be unable to receive any payments from Alice in those two days.  (Any LN payments that Alice tried to sent him after that point would be invalid, and he would have to notify her of that.)  This dilemma was considered to be a small inconvenience not worth fixing.

* However, in order to make the LN worth the trouble, and expand usage to billions of users with 1 MB blocks, each payment channel had to be used for many, many LN payments.  So their expiration dates had to be set well into the future -- say, six months for a grocery store, ten years for the landlord, etc..  And users would have to lock up in advance enough money to cover all payments in that interval -- six months of groceries, ten years of rent, etc..  That might have displeased some users.  But that problem was temporary,  because soon the entire economy of the world would be on the LN, and then everybody would receive their monthly salaries through it, so they would not need more than one month's worth of funding buffer.

* Still, one small technical problem remained.  Even if Alice worked for grocer Bob, and spent all her salary buying food at Bob's,  she would be unable to use her salary to pay her purchases.  The 50 BTC of her salary would be a cheque drawn on the funds of the Bob-->Alice channel, while her 45 BTC of purchases would be a cheque on the funds of the Alice-->Bob channel.  There would be no way to use the first cheque to refill the second channel; both channels would have to be funded with 300 BTC to work for the next six months.  

* The solution of that problem was to make payment channels bidirectional.  Namely, instead of Bob paying 2.60 BTC to Alice through a separate Bob-->Alice  channel, he would just strike out 2.60 BTC from the payments that she already made through the Alice-->Bob channel.  If he thought that he might need pay more to Alice than Alice wil pay to him, he should contribute his own funding at the opening of the channel -- say, another 5.00 BTC.  So, for example, to pay Alice 2.60 BTC after Alice paid 0.60 and 0.90 BTC to him, he would send her a transaction (cheque #3) that Alice could use to recover 6.50 BTC from the 10 BTC funds, and send 3.50 back to Bob.

* But that created another problem: as payments went back and forth, either side may end up holding cheques with higher value than the net balance of payments, that could be used to cheat on the other party.  In that example,  after sending the 2.60 BTC to Alice (with cheque #3), Bob could close the channel wIth the previous cheque that Alice sent him (cheque #2), thus getting 6.50 BTC out of the 10 BYC funds, instead of only the 3.90 BTC that he is entitled to.  Or with cheque #1, to get 5.60 BTC.  

* To solve that problem, all the cheques had to be made slighttly more complicated.  First, all cheques needed to have their own time-lock of (say) 2 days.  That is, if Bob or Alice sent a cheque to the miners, to close their channel, its output coins would be frozen for 2 days after the cheque was confirmed in the blockchain.   Second, wenever a payment X from Bob to Alice left Bob with a cheque Y that he could use for such fraud, he would have to send to to Alice a second "boobytrap" cheque, that Alice could use to thwart that fraud.  The boobytrap transaction would immediately send all 10 BTC of the channel to Alice, but only if the blockchain included a cheques for that channel earlier than cheque X.  And similarly for payments from Alice to Bob.

* For the boobytrap transaction to work, however, Alice had to constantly monitor the blockchain, watching out for those earlier cheques that she had sent to Bob.  If she took too long to spot the fraud and get the boobytrap confirmed on the bitcoin network, Bob could move the stolen coins away from her reach.  If Alice happened to be cut out from the BN for more than 2 days, and Bob knew it, he could do the fraud impunely.

* The solution found to that problem was to add to the boobytrap transaction an extra output that sent a small reward to the address of a "bounty hunter" chosen by Alice.  Alice would then give the boobytrap transaction to the bounty hunter, who would watch the blockchain for her and issue the boobytrap if needed.  Of course, the hunter had to be a trusted professional, who would not even think of proposing a deal to Bob, even though that could pay a lot more than Alice's bounty.

* Bidirectional channels would help reduce the severity of the channel funding problem, since they could carry unlimited amount of BTC, as long as they were roughly balanced -- that is, the net balance, at any moment, did not exceed the initial funds put up by each party.  But, in a network with more than 2 participants, the different channels could still get quite unbalanced.  If Alice received her salary from Carol but spent it on several dozen different merchants, rather randomly,  she would still have to open that many channels, and lock in each channel enough coins to cover her *maximum* purchases from that merchant over the next six months.  And Carol would still need to lock enough coins in the Carol-->Alice channel to pay Alice's salary for several years.

* To solve that problem, it was necessary to assume that there would be large "hubs" in the LN that would serve as intermediaries between ordinary users.  These would need to open only one channel to a hub, funded with enough coins to cover their expected payments for the next month or so.  The hub, conversely, would fund the channel with enough coins to cover the user's expected revenue for that period.  All LN payments then would be  through these user<-->hub channels.  To pay 0.60 BTC to Bob, Alice would send an LN payment of 0.60 BTC to the hub, and the hub would send the same amount to Bob.    

* Those hubs would need lots of coins to fund the outgoing direction of those channels, especially to large merchants like Walmart or Stabucks.  To reduce that problem, channels to those  large companies would have to be settled daily, or even every hour.  Even so, the hubs would have to borrow many thousands of BTC from bitcoin magnates, paying interest. 

(At that point, the janitor had to be called in to mop up the saliva from the floor, in the corner where the big holders were seated.)

* However, without further precautions, the hub could cash Alice's cheque without sending the same amount to merchant Bob.  Conversely, if Alice demanded the hub to pay Bob first, she could cheat on the hub by failing to send her cheque.  So, special cyptographic tricks must be used to link the two payments, so that either both cheques are received, or neither one is received. 

* Even so, Alice and Bob would have to trust that the hub will not censor their payments.  The hub can always refuse to handle Alice's payment to Bob, or any payment from her, or any payment to Bob.  In theory, Alice could simply use another hub, or open a channel directly to Bob.  However, a large merchant, like Bob's Grocery, will not want to bother with managing payment channels from individual customers.  Bob will require them to use one or two specific hubs. 

* Those big hubs of course would have to comply with money transmission laws, woudl have to get the proper licenses in all jurisdictions, and would have to comply with AML/KYC regulations.   That meant 

* The investors who lent coins to the hubs would also have to trust them not to