|
|
|
|
|
by nullc
2356 days ago
|
|
> and hope they know someone The system has routing, and it turns out that it doesn't take much for the probability of a graph to be connected with low average diameter. See: The six degrees of kevin bacon. If lightning doesn't work for a particular payment, you can simply make a payment without using it, potentially by splicing out funds from one of your channels. Yes, Lightning has trade-offs. You have to be online (though there is ongoing research into changing that), and some moderately complex software had to be written to create it. But in return you get get massive efficiency increases and instant irreversible payments. For the transactions that it's intended, I think for these are pretty good trade-offs... though if you don't like them you're free to not use it. |
|
No true: due to limited block space on the base-layer.
I am not convinced you get any efficiency increase with the LN: just more difficult capacity planning because everything is suddenly so hard to measure.
Sending a payment, whether on the first or second layer, will take a certain amount of: bandwidth, processing and storage.
Even if fewer nodes are involved with each transaction, the LN seems to rely on a lot of message passing; beyond what a simple broadcast on the base layer requires.
Even is we assume the processing and storage requirements are equal: it will be more expensive on the LN. On the base layer, your data is protected from Byzantine faults by having each node verify the transactions as they come in. With the LN, state is local to each node. That implies you need redundant hardware to protect against Byzantine faults. I have been migrating my machines to ECC RAM and redundant storage: it is not cheap. What I save on hardware costs by buying old servers I pay in extra power use.
The above paragraph did not even mention the capital requirements of maintaining a Lightning node.