Like all good lies, there is a kernel of truth behind them. However, like all good lie, they omit or distort some specific information which are key. Like all good lie, they get repeated so often that they may end up looking like truth. Let’s go over some of them.
SegWit solves malleability
SegWit only solve malleability for transaction which spend ONLY SegWit UTXO. All other transactions remains malleable. This fix is enough to enable technologies like Lightning network. This comes at the cost of reduced fungibility, because only some coins can be locked in the lighting network.
SegWit solves quadratic hashing
SegWit solves quadratic hashing for some specific transactions just like it solves malleability for some specific transactions. However, quadratic hashing is an attack vector and solving it in some specific case is about as useful as being partially on birth control: none at all. SegWit absolutely fails to solve anything related to quadratic hashing.
SegWit allows blocks up to 4MB
That is technically true. However, while block can be up to 4MB, this is not really what people require bigger block were asking for. To illustrate, let’s imagine your friend got a kid and tells you he needs a bigger car than his 2 seaters. How do you think he will react when you propose him a car that is twice as big, but still only has 2 seats? Well that’s what some are trying to sell to you.
Considering current usages, we can estimate that SegWit will increase the amount of transaction which can be processed by a factor of 1.7x to 2x. The fact that SegWit allows blocks up to 4MB while delivering only a 2X capacity increase is not something to be proud of. It adds a new attack vector, as one could start producing bloated blocks and ultimately reduce the long term scaling capability because the adversarial case just got twice as bad.
People do not want bigger blocks for the sake of bigger blocks, but for the value they bring to users just like people do not want bigger car for the sake of bigger car but because they can transport more people or stuff in it.
Lightning network can go world scale
Lightning network, or in short LN, is a technology which allow users to lock funds into a channel, then do transactions offchain and only settle the end result in the blockchain. This is all great until you look at the fine prints, which are for some reason always omitted.
The first one is that is changes the security model. With LN, the person you are transacting with can steal your funds at any time and it is up to you to publish a proof that you are being stolen from, within a given time frame. This is a drawback in itself, but something one could work with considering the benefit brought by LN. However, in the case where the chain is running at capacity, it may be very expensive, or even not possible at all for you to publish the proof within the required timeframe. In the world of LN, full blocks equals stealing.
The second problem is that it require an ungodly amount of capital to operate. If you want to be able to pay up to $100 using LN, you need to have $100 or more locked into a channel. If you want to be able to receive $100 , this amount or more needs to be locked on the opposite side of the channel. If we imagine an extremely centralized network with only one hub in the middle, processing payments for 10 millions users (which is the order of magnitude of the number of Bitcoin users today) and allow these users to send payments up to $100 , the users collectively would have to lock up at least $1B in channels, and the hub itself would have to also lock $1B in all the channels with its users, and yet, be less useful because of the $100 limit. Yes, that’s $1B, to create a LN the size of the current Bitcoin network. Growing to a billion users and up to $1000 in payments require a trillion dollars from the hub.
But we imagine we won’t have one giant hub, instead we will have several hubs interconnected with each others. Let’s imagine we can find routes for Alice to send a payment to Bob in an average of 3 hops, then we need to have the amount Alice’s send to Bob or more locked up in each channel along the way. The inevitable conclusion is that LN strongly incentivize centralization as longer routes require operators to lock up even more fund that in the centralized scenario.
Schnorr signatures will provide addition capacity
Schnorr signatures are very cool and are indeed both cheaper to validate than currently used ECDSA, and are also more compact, so you can fit more of them in a block. However, signatures go into the witness section of the block, and, with current use cases, and if we keep the same block size limit, the expected witness usage is of about 1MB when it is possible to have up to 3MB of witness data in a SegWit block. As a result, Schnorr cannot deliver any extra capacity because it is optimizing the wrong thing.
When someone is lying continuously to you to sell their tech, rely on censorship, be sure they have ulterior motives. Do not buy or you’ll get scammed.