“In theory, a blockchain could learn from UTXO commitments to forget …”

The Bitcoin-Cash developer Tomas van der Wansem recently put a UTXO commitment into the test. We talk to him about the solution discussed as a milestone of scalability.

Tomas van der Wansem is a developer of Bitcrust, a not yet finished implementation of Bitcoin in the programming language Rust. Tomas is one of the most active developers of Bitcoin Cash (BCH) and he seems to be a busy spirit that falls on a wide variety of topics. He is currently working with the other BCH developers on UTXO commitments, a tool that can help to scale a blockchain. He recently wrote the first implementation in the blockchain on the testnet. With the Amsterdamer, we have gestkypt to find out what it is all about.

What is the idea behind UTXO commitments?

UTXO is the abbreviation for “Unspent outputs” and means the coins at Bitcoin that can be output. The UTXO set is the entirety of these coins, it is the condition of all coins, i.e. all credit of addresses. It is needed to validate new blocks and new transactions. The idea of ​​utxo commitments is now to calculate the hash of the UTXO set and to put it in every new block. There are different methods to do that.

What would that have?

There are two reasons why UTXO commitments are useful. First, a new Full Node has to download the entire blockchain, but only the UTXO set. Today he has to load the entire blockchain to validate and build the UTXO set. If there is a UTXO commitment, you have a proof of whether a UTXO set is correct. So you can just download and check it. This allows you to start a node much faster, and theoretically it would even be fine if the historical blockchain is “forgotten”.

The second benefit is that in Utxo commitments you can prove that a utxo is part of the set. To check today whether the inputs of a transaction are valid, you have to compare them with the entire UTXO set. If we have proof that a UTXO is part of the set, you no longer need the entire UTXO set for this test. That could help develop a whole new type of light client.

The UTXO set at Bitcoin Cash is currently about 2 gigabytes. I can imagine that it does a lot of work to keep and check that ..

Oh yes, it’s a lot of data and it takes a few minutes to have it to be. The challenge is that you form the UTXO commitments in such a way that it does not have to be recalculated completely for each block, but that after it has been formed, it is simply updated.

The idea is not new. The problem is that there are many methods to do, and so far there has been no agreement which is the best of them. We build on a proposal by Core developer Pieter Wuille, whom we improve. The method does not use Merkle Trees or other cryptographic trees, but is “flat”. We simply take the hash from every utxo, connect them and calculate the sum of it. Instead of a normal addition, however, we use group surgery of elliptical curves, which has a very similar effect, but is safer.

Do you know why the core developers have not developed the Pieter Wuille proposal?

I don’t know exactly, but I suspect that they were worried that it won’t be fast enough if the UTXO set continues to grow. But we have found a method to improve it. I also think it has something to do with priorities. Conceptively, UTXO commitments go better with the Roadmap from Bitcoin Cash.

You recently wrote a UTXO commitments in the testnet of Bitcoin Cash. How far has the development advanced?

The code is currently still in the peer review with the developers of Bitcoinabc and Bitcoinxt. Bitcoin Unlimited will also look at it soon. The commitment in the testnet was just a first test, and it is not yet part of the consensus rules in the testnet. In order to achieve the idea of ​​quick synchronization, we have to go a few steps further. The first is the development of the committees themselves, on which we are currently working, but in order to synchronize quickly, we still need P2P messages that allow UTXOS to transfer, and we also have to develop the synchronization mode ..

And the new type of light wallet, when is it to be expected?

The version we are currently working on is only suitable for quick synchronization, but not for the light wallet. There are designs that can both, such as the Merklix Trees proposed by Amaury, but they are still in an early phase of development and demand a lot of computing power to the nodes. We all think that new Light Wallets would be great, but the quick synchronization is currently more important. So we first concentrate on it.

Can you estimate when it will be possible to synchronize quickly?

Oh, roughly estimated … in November we will upgrade Bitcoin cash via Hardfork, and I hope that we will bring UTXO commitments to the chain. So far I have written it into the coin base on the testnet, but we still need the rule that all miners and nodes validate the utxo commitments in the coin base. If we bring that to the Chain in November, that would be an important step. The next would follow afterwards.

What do you think, how far can you scale with utxo commitments?

That is a difficult question. It is currently quite annoying that you have to download more than 100 gigabytes from data. There is a load to start a node, and an important bottle neck in scalability. At first glance, it only helps with synchronizing a nod, but when you look at what the nodes give their bandwidth, such as the upload, you can see that a large part is used to distribute the old blocks to new nodes. UTXO commitments can therefore also help. But I cannot give specific information on how far you could scale.

Tomas, thank you very much for the many information!