> 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.
According to a recent study, the privacy properties of the lighting Network are weak.
The problem with lightning privacy is that to get good privacy you need more than about 2 hops. The problem is that every hop locks up money equal to the amount transferred: increasing the cost of the transaction.
The study also finds that the LN is currently subsidized, and based on the capital costs alone, fees should be comparable to on-chain (BTC) transactions. BCH transactions are currently subsidized as well, but not to the same extent (I estimate 3cents/kB would pay for processing and storage).
Around fork time, there was a coordinated push, including websites, subreddits, youtube videos (title of video by jimmy Song interviewing Roger Ver was first known use), and the censored 'bitcoin' forums all calling the fork 'bcash'. One week later, Samson Mow even did a guest column for Forbes magazine[a] mentioning the term. Adam Back later Chastised Cobra for not calling it bcash.
The goal appeared to be two-fold:
1. Strip Bitcoin Cash of the name
2. Frame it as a scam, especially if we take back the name.
"The newly created Bitcoin Cash (BCH) is a rushed spinoff of Bitcoin (BTC), a clonecoin of which there have been many in Bitcoin’s past. Because the name is confusing, many have taken to calling it “Bcash” to avoid buyer confusion."
The fact that in Bitcoin we took the time to fully think through, write a clear and complete specification https://github.com/bitcoin/bips/blob/master/bip-0152.mediawi... , and thoroughly test and review the implementation before deploying it while BU has been occasionally abused by the BU organization and their supporters to dishonestly claim that compact blocks came later (or were somehow derived) from their work.
Users on the sidelines were easily deceived by this marketing because BU rushed their implementation into production while Bitcoin took a more deliberative process.
BU's "thinblocks" implementation was, in fact, severely flawed both due to an implementation vulnerability that resulted in almost every BU node on the network being crashed near simultaniously, and due to a design error introduced because BU's "chief scientist" strongly believed that it was computationally intractable to produce a collision in the first 64-bit of transaction IDs (a sha2 hash), even though one can be computed on a fast desktop computer in seconds.
So the history is that: Bitcoin developers proposed and tested an idea for faster block propagation using filters and found it lacking. Later, it came up again as a possible way to mitigate segwit's bandwidth increase, so I wrote a design to address the known issues and we started working on implementing it. A few weeks later BU developers picked up the old work and started improving it. Within a couple months they had it deployed it in public and announced 'mission accomplished', but their deployment was unspecified and ultimately faulty. As a result of those issues and the superior relay latency of compact blocks thinblocks was replaced in the Bitcoin Cash network with the protocol from Bitcoin.
There is no common protocol feature in BU's xthinblocks that wasn't also in Bitcoin's original work that inspired both efforts. There could have been no influence on compact blocks' design by xthinblocks because it would have been physically impossible for there to be due to causality. That hasn't seemed to stop BU developers and people like you from repeating this lie.
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.
Many source routed networks work fine, including Tor. All MPLS usage is source routed. Source routing isn't used for _IP_ (generally) but for reasons which have nothing to do with 'scale'.
Not a problem if you don't intend to have nodes sufficient to actually be considered "at scale" and your plan from the very beginning is a centralised hub and spoke network.
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.
Pretty much this. I don't think greg has read any economic theory, let alone introductory microeconomics where you would see the idea of 'marginal analysis'. I mean his reply suggests that demand is entirely static, or inelastic, which would be interesting to study, but certainly shouldn't be assumed, and is likely completely false.
