SegWit and technologies built on it are grossly oversold

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.

Variable size integer encoding

It is a known fact of nature that most integers are small. When transferring data over the network, or to/from disk, or pretty much anywhere the IO is slow, keeping data compact is a plus. Obviously, compression is an option, but it is fairly CPU heavy. Taking advantage of the fact that, in practice, most integer values are small is an option to effectively reduce the amount of data for a modest cost in term of CPU.

Continue reading

Using Merklix tree to shard block validation

When scaling a system, there always comes a time when all of the processing cannot be done on one machine. This problem is solved by spreading the workload across several machines. This presents some challenges however, solutions are well known in the industry.

In a trustless system such as Bitcoin, peers generally do not trust each other. Currently this is solved by having all peers doing all of the validation, which obviously doesn’t scale, at all. If we are to shard the blockchain, how can a node trust that other shards are validating properly ?

Continue reading

Efficient mempool synchronization using bloom filters and entropy coding

One of the major challenge to scale bitcoin is that a lot of the work done by nodes is reactive. Nodes receive a block and start validating. This takes time and resources and is right in the hot path. The problem gets worse the bigger the block are, to the point were consensus takes more and more time to be reached. At some point, consensus cannot be reached.

In order to improve scaling capabilities of the network, it is key that nodes do as much work as possible ahead of time. When a block is received, node just have to assert that the node effectively contains what they expected, which speeds up validation significantly.

Continue reading

Using Merklix tree to checkpoint an UTXO set

In a previous article, I introduced Merklix trees as a way to cryptographically describe an unordered set or map. It is possible to produce proof that an element is contained or absent of the datastructure in o(ln(n)), and use these proof to mutate the structure, even without knowing its full content.

I will now explain how this can be used to help handling the UTXO set in blockchain technologies like Bitcoin.

Continue reading

Introducing Merklix tree as an unordered Merkle tree on steroid

Merkle tree are awesome. They allow to hash an ordered set of elements and provide a way, known as a Merkle proof, to prove that a given element is at some position in the set without having to provide the whole set. While this is a very useful tool, the fact that it is ordered can be somewhat troublesome. Inserting or removing an element in the middle of the set will require significant work and, more generally, 2 sets containing the same elements, but in a different order will yield 2 radically different trees.

Today, I’d like to introduce a new tool to the software engineer toolbox, which, as far as I know – and that probably tells more about my searching-foo than anything else, hasn’t been proposed before. The goal is to hash an unordered set in such a way that:

  • The end result is the same, no matter in what way the tree is created
  • Insertion and deletion are ln(n)
  • It is possible to produce a proof that an element is contained in the set without producing the set

Continue reading