If person A wants to buy something, person B is in the middle and Person C is the receiver, then B first pays C, so he actually 'lends' money to A



But the key here is that average Joe doesn't have a lot of money to finance payments for others (average Joe takes credit, he doesnt give it). So that's a huge problem in the decentralized mesh. I honestly don't see how this could work without any big centralized nodes like banks. In fact I think that's just the natural way it will evolve: people will open payment channels with big parties (=banks) to ensure that they can actually pay people. You don't want to divide your money over 20 channels and only have 5% of your money per channel. So it seems only natural that banks would become central in LN, it's both more efficient and effective.

Just trying to grasp this whole concept. The whole idea of bitcoin was decentralization and now with LN it seems it's going the other way again.

If I funded a channel with say 0.5 bitcoin, how long might it operate independent of the blockchain? because whenever there is a clearing of the transaction routes back to the blockchain, there is a nightmare of a fee to pay.

With a well connected graph, that's not a problem. And based on current use on testnet, it looks like it is going to be a fairly well connected graph.

That's completely untrue. You are then dependent on the wealth of that "bank", how many channels it has open, and how much it owns on each channel. You are not done, and there is no guarantee that said "bank" will be any better than your 4 friends. Suppose that bank is just like friends, but with more channels that lead to dead ends and not the airline you want to pay. Now you're stuck. It's exactly the same as with your friends, and not any better nor any worse.

BTW does BTC even supply for such a mechanism that it can cancel all payments if one fails ? Otherwise nobody would use it (who wants to pay 80% of a product and thus not receive the product) and your example isn't even valid

Yes, there is a mechanism to cancel a payment. Anyways, currently it isn't even possible to have a partial payment. The way that routing works is that the sender chooses the nodes to send through and will only initiate the process if it knows that the payment will happen (barring circumstances involving malicious actors or unforseen circumstances).

No, that's not how it actually works on the technical level.

At the technical level, every node in the route first creates an HTLC offered output and HTLC received output in the channels that the payment is being routed through. This effectively locks in the coins and the order of those outputs being created is not guaranteed. I.e. A could offer the HTLC to B before B offers to C, in which case B owes A money. But just as likely is B offers C the HTLC output before it receives the HTLC from A, in which case A owes B money. In either case, neither party actually gets any money, so no money actually exchanged hands nor is anything actually owed. If B fails to offer the HTLC C, A will get his money back when the HTLC times out and B will not be able to have gotten any of that money at all. When the preimage is passed down the route from D to A (let's add one additional hop for this example), none of the parties in the route is able to get more money than they are supposed to even if they don't reveal the preimage to the next person. With lending money, the lender can steal the money, but in LN, the "lenders" (i.e. nodes in the route) cannot.

The reason for this is slightly complicated. In a route A -> B -> C -> D, D must reveal the preimage R in order to be paid. He can do this by either broadcasting the C -> D Commitment transaction and the HTLC success transaction (so he spends the HTLC output from the commitment tx) or by telling C what R is (and thus keep the channel open). If he broadcasts the HTLC success, then both B and C know what R is since R is in that HTLC success and can immediately broadcast their HTLC success transactions, so they are paid and pay money at exactly the same time.

If D gives C R and they settle off chain (to keep the channel open) but C refuses to give B R, he is actually out money since he has already settled the HTLC offered output but not his HTLC received. C is now short the money that he gave to D. Note that this is different from lending because this is not B refusing to give C his money but rather C refusing to take it. The only way C can take that money is if he gives B R or if he broadcasts the commitment transaction and HTLC success transaction. Either way, B will get R and he will end up paying the money to C as that is how HTLCs work.

The payment of the HTLCs is guaranteed because of the commitment transactions. HTLCs are part of the commitment transaction which is signed by both parties in the channel. In the B -> C channel, B cannot revert his HTLC without C agreeing to revert it. If he chose to broadcast an old commitment which did not have this HTLC, then he will be subject to C's revocation transaction which can take all of B's money. The way that HTLCs work is that if you can show that you know R, then the payment is guaranteed because you can spend that output. So once C knows R, his payment is guaranteed unless he waits too long and the HTLC times out. But then that is still not lending as B did not refuse to pay C but rather C refused to take money from B.

So in no way is this actually lending. No node has more money than they are supposed to. HTLCs are not a promise that you will give them the money (as it is with lending) but rather a guarantee that they will get the money. Nodes must forward R down the route otherwise they will be losing money. There is no situation where a node can get more money than they are supposed.

Note that this only works when R goes from D -> A. If it went from A -> D, then it would be lending and a node could defraud the next node in the route. But LN goes the other way, so that is not a problem.

I think that it will not be a centralized doom scenario like some people think.

Nods do not have to be very big. Most small buy coffee amounts don't need much of backup from supper nodes.

You still can choose to send using the main chain wich have by then lower fee as the load is gone

Right now we have massive mining farms and small home miners that work in harmony to a certain level

Instad of mining pools we should see super nodes that are funded by average john using some smart contracts

I think that development team have think about al this points.

I've been reading some more and there are even more important arguments against decentralization:

1) Users need to be online all the time! If somebody is offline he can NOT process a transaction for you, this means that that person breaks the route, which is a huge problem. Banks on the other hand will of course be online 24/7
2) Monetary incentives for centralization! Everybody who helps processing your transaction gets a small fee. So if there's a route with 10 people in it, then a bank with a direct route can charge 9.99x the fee for one hub and still be cheaper! So the bigger a hub becomes, the smaller the routes will become and the more they can charge. This of course works as a huge snowball for size and is a huge incentive to become as big as possible.

From my understanding when a user is offline he won't even get elected as possible node.

Hmm I find this a weird answer. Of course the guy with just one node can always charge less because he doesn't have to divide the profit.