phillipsjk

I am not holding my breath.

Correction: that was simulated testing, using scraped channel data and a LNBig blog post (about traffic statistics) to validate the results.

I guess I stand corrected on that one.

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

Compact block were heavily inspired by Bitcoin Unlimited's "Thin Blocks".

I disagree that the LN paper made conservative assumptions.

A "black swan" event like a major lightning hub going down may force more channel closings than the network (as currently implemented) has time to process before time-out.

The LN simply does not work if the base layer is congested.

Unlike the base layer, the LN uses source routing: which was abandoned years ago. Requiring the endpoints to know the structure of the network graph leads to intractable routing problems at scale.

Of course the fees would drop after raising the blocksize.

The current fees are well above the marginal transaction costs of processing and storing those transactions. (I estimated it was 3cents/kB, assuming GB scale blocks on ~1000 4U (36 bay) servers with 10Gbps networking distributed world-wide.) Other analysis I have seen erroneously assumes the POW is a marginal cost: which is only true with a tiny, limited, block-size.

During the September 1, 2018 "stress test" on the BCH network, the average transaction cost actually went down. All while the network processed 2 million transactions in a day.

It is called BRD wallet. (originally Bread Wallet)

Also, BSV seems to be a parody of Bitcoin Cash (BCH).

You wanted large blocks? We'll give you large blocks!

Since you read the Lighting whitepaper, you know that an uncongested base-layer is assumed. The paper suggests something like 133MB blocks at scale.

On-chain scaling does not prevent that. In fact, it reduces complexity by removing the Lighting requirement.

Tangent: I would not recommend running lightning on such hardware. State is local to the node, unlike with on-chain scaling. That implies you need server-grade (read: redundant) hardware.