Metadata subtree for Bitcoin

The block header of Bitcoin has a couple of flaws; some of them being in the way of highly desirable innovations such as UTXO commitments. Unfortunately, fixing those flaws isn’t an easy task because most “easy” solutions end up not only breaking backward compatibility with most of the software ecosystem, but also end up bricking most mining devices. Hence, those “easy” solutions aren’t exactly on the table. Yet, a simple solution is needed, because complexity is the enemy of both security and scalability in a project like Bitcoin.

Merklix tree for Bitcoin

Last summer, I had the opportunity to meet with the Bitcoin ABC folks, and we revisited the pain points which needlessly complicate on-chain scaling for Bitcoin. The Merkle tree flavor as originally implemented in the Satoshi’s codebase comes with its own complications, some of them clearly accidental - as they do introduce unintended vulnerabilities. The Merklix tree angle addresses the scalability challenge as well as fixing the unintended complications of the original design.

Salient bits of CashDB

Designing CashDB has been an interesting task, and beyond pure performance benchmarks, I would like to share some of the most salient aspects that went into its design. Choosing C#/.NET: CashDB is implemented in C#/.NET. This might appear as a surprising choice for a high performance project, however, .NET Core is performant, surprisingly so, even. High quality C# implementations (eg xxHash) basically exhibit performance aligned with C. Then, productivity-wise, C# - just like Java or Python - is plainly superior to C++.

Alpha release of CashDB, high-perf backend for UTXO storage

The alpha version of CashDB has been released. CashDB is a fork and the successor of Terab which has unfortunately been discontinued. CashDB is an effort (disclaimer: this is not a regular open source project, there is a BCH restriction, check the license) of Lokad to support the on-chain scaling of Bitcoin. It’s a blockchain-centric key-value store specifically tailored for the UTXO set of Bitcoin - the set of unspent transaction outputs.

The Sozu table, a blockchain-centric data structure for the UTXO dataset of Bitcoin

The UTXO dataset is the set of unspent transaction ouputs in Bitcoin. This dataset represents who own’s what, and it is the only part of the blockchain that actually need to be persisted to keep Bitcoin working (well, almost, block headers are needed too, but they are much smaller). Earlier this year, when I started to work on the UTXO challenge challenge, I realized that generic key-value stores were not exploiting all the angles that could be leveraged in the specific context of Bitcoin.

On compact proofs for token protocols

Bitcoin can operate a large variety of tokens1 through trust-but-verify schemes. Apps supporting such tokens are part of cashland2: those apps interact with the blockchain, but they are not required for Bitcoin to operate as cash. Trust-but-verify differs from the code-is-law approach where the validation of the correctness of the token transactions is the responsibility of the participants in charge of securing the blockchain itself. As far tokens are concerned, trust-but-verify is superior to code-is-law in terms of blockchain economics and also happens to be more practical3.

Canonical Transaction Ordering for Bitcoin

Bitcoin should and will scale. However, the scaling process can be made a lot easier if some hurdles are lifted. In particular, the path toward blocks as large as 1 terabyte requires every part - within Bitcoin - to be made as lean as possible. The canonical transaction ordering is a modest change, yet, I see this evolution as one of the most desirable changes in Bitcoin to clear the path to scalability.


It is the nature of radical discoveries to be wildly misunderstood by their contemporaries. It is inevitable to some degree. If most well-prepared minds were already expecting something similar to be discovered, chances are that those discoveries would have been made earlier, and would not have appeared as radical as they did. I believe Bitcoin to be a radical discovery. I argue that Bitcoin and its peers cannot be understood from the classical perspectives, thus, I am rolling my own.

4-byte prefix guideline for OP_RETURN on Bitcoin

Back from the CoinGeek conference in Hong Kong, I could feel that the extra capacity of OP_RETURN increased to 223 bytes on Bitcoin has tremendously energized the community. Tons of talented people are now back to work, building cool stuff on top on the Bitcoin infrastructure. Yet, the blockchain is a shared resource, and while scalability is a very solvable challenge, the community needs principles to avoid needless complications. In particular, as the OP_RETURN data space is shared among all participants, an opt-in mechanism to avoid “dumb” collisions is highly desirable.

A taxonomy of the Bitcoin applicative landscape

Nothing like a good initial confusion on dialog terms to trigger hours of sterile discussions; and possibly a few hundreds of tweets as well if attempts are made to have the dialog carried through Twitter. As Bitcoin was - still is to a large extent - a rather radical innovation, its early terminology wasn’t without flaws. Unfortunately, the confusion that followed turned out to be rather extreme, and was ultimately solved through a major fork: Bitcoin Cash vs Bitcoin Core.