Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> 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.

Today sending a transaction communicates 10 messages for each of ~100k nodes in the network. Once its confirmed, that transaction will additionally be sent once to every new host to join the network, forever.

Lightning sends a couple of messages back and forth among the nodes directly involved in the transaction... maybe 4. (The average shortest path length is about 2.8 currently).

So the marginal communication cost for a transaction is literally hundreds of thousands times lower-- even ignoring the cost to future nodes joining the network-- and this advantage grows as the number of nodes increases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: