@cypherdoc You might want to start using archive.is to preserve comments before they can be deleted.
[doublepost=1460764118][/doublepost]I was asked to give a more thorough explanation about how LN could lead to fractional reserve hubs.
There are five basic step to operating a micropayment (such as the ones LN is built on):
- Two (or more, hypothetically) parties agree on a script where the channel funds will be stored.
- The parties agree on a refund transaction and all sign, but do not broadcast it.
- One or more individuals fund the channel by creating an output with the designated script and amount.
- The parties adjust the theoretical balance of of the channel by agreeing on and signing new versions of the refund transaction.
- Presumably someday a version of the refund transaction will actually be broadcast and mined (although depending on which LN proponent you talk to, this is apparently optional).
LN didn't invent micropayment channels - it's basically a protocol for identifying a set of channels to revise in order to make a payment (routing), and a method for atomically (or at least safely) updating all members of the set.
Imagine that Coinbase and Bitpay are LN hubs. The idea is that they'd probably have a channel open with each other which they can adjust, and Bitpay would have channels open with the merchants they service. A user can then open a channel with Coinbase, and as soon as this was complete they'd have the ability to perform instant, low-fee payments to any merchant which Bitpay serves.
The first thing to note is that both opening and closing a micropayment channel has a minimum cost of one on-chain transaction fee. Keep this in mind when ever anyone talks about intentionally pushing transaction fees to levels which will give people an incentive to use LN. The cost of opening and closing channels has a significant impact on the LN operation.
Bob is our example user, and he's going to buy his very first bitcoin. He downloads a LN client onto his phone. Then he goes to coinbase.com, registers for an account, links his bank account/debit card, and purchases 1 bitcoin. When this purchase is complete, he withdraws his bitcoin to his LN client. His client cooperates with Coinbase to create a micropayment channel, which Coinbase funds (Bob can't fund it himself since he doesn't own any bitcoins yet).
The available balance on this channel is the amount which Bob receives in the first version of the refund transaction, which is 1 btc - 1 on-chain transaction fee.
Unless Coinbase contributes some its own working capital to this channel, then as soon as Bob opens it it will be immediately "full" in terms of his ability to receive funds - he can't receive any payments on this channel since the refund transaction already sends the entire balance back to him. Coinbase may contribute some of their own working capital to the channel to enable bidirectional payments. This is a risk for them, since that portion of their working capital is hot rather than being safely secured in cold storage. One way or another, Bob will end up compensating them for this risk in addition to the time value of money, most likely via the fees he pays for using the channel.
Let's assume that Coinbase contributes 1 bitcoin of their own when they open the channel. In that case the first version of the refund transaction will send (1 btc - 1 on-chain tx fee) to Bob, and 1 btc to Coinbase. This means Bob can spend almost 1 bitcoin using the channel and can receive 1 bitcoin using the channel.
Life is pretty good for Bob as long as his usage of this channel (sending vs receiving) remains in balance +/- 1 btc. If at any point the channel fills up in a particular direction, the only way to keep sending or receiving (depending on the direction in which it filled up) is to open a new channel. This will cost 1 on-chain transaction fee.
This creates a terrible user experience for LN. Imagine being the support representative tasked with explaining to customers why they can't receive money from their grandchildren any more without paying a relatively-large fee because their channel is full. In fact, once a channel is full it become uneconomical to send any more transactions in that direction whose value is less than the cost of an on-chain transaction.
There is a solution for this - LN wallets just need the ability to add and remove new inputs to a refund transaction. So going back to the first example, as soon as Bob purchases his first bitcoin, his friend Alice immediately wants to send him another 2 btc. Since this is more than the available liquidity it's not possible to do this while adhering strictly to the micropayment channel protocol, but Coinbase has decided that they don't like dealing with awkward support calls so they've altered the protocol slightly for their customers.
Rather than opening a new channel, whenever somebody tries to send Bob bitcoins when his existing channel is full Coinbase selects an input from their own wallet and adds it to the refund transaction. Bob's wallet accepts this either because he's using a Coinbase-branded LN wallet rather than a generic one, or else because even the generic LN wallets have been convinced to add this capability.
There's nothing wrong with this necessarily, however since that new input isn't part of the Bob-Coinbase micropayment channel, Bob has no way to confirm the input has only been added to his refund transaction. Coinbase could have overcommitted that input to 10, 100, or 1000 other refund transactions - nobody knows until somebody decides to close a channel. As long as Coinbase is confindent that most of the channels won't attempt to close at the same time, they don't have to worry about it too much. Whenever the first channel which includes an overcommitted input closes, they just update the other channels with a new input.
Coinbase doesn't actually do this, of course. When they rolled out their "liquidity protection" feature they explicitly promised to never overcommit inputs, and since they are regulated, law-abiding businesses we just have to look at the track record of financial regulations and their outcomes to know we have nothing to worry about.
Also they bribed a bunch of "Bitcoin journalists" to label anyone who points out the potential for, and strong incentives to create, undetectable fractional reserves as a "conspiracy theorist."
There's another way that Bob's wallet can apparently make his life easier while reducing his security. Remember that step 3 of the micropayment channel creation process requires an on-chain transaction. There's nothing about step 4 that inherently requires that transaction to confirm in the blockchain prior to adjusting the refund transaction. After all, until it's broadcast the refund transaction is a purely private contract between Coinbase and Bob.
If his client is being as safe as possible, it will wait to allow him to use the channel until the funding transaction has confirmed. However, this is another UX problem that Coinbase has a strong incentive to avoid. In order to be as convienient as possible, his LN client could allow him to start using the channel immediately. In fact, in keeping with user interface trends the app designer might decide to never show Bob the confirmation status of the funding transaction at all (it's a low-level detail he doesn't need to worry about).
What if the funding transaction never confirms at all? How long could Bob's wallet work for him before he notices a problem?
The answer is - he'll never notice any problem whatsoever until he tries to close the channel.
What if channel closure is highly discouraged by high on-chain transaction fees, and eventually becomes so uncommon that LN apps actually drop that functionality entirely? Bob could use his LN client for the rest of his life blissfully unaware that he doesn't actually own any bitcoins at all.
