CHIP 2021-07 UTXO Fastsync

CHIPs Standards Track
,
#81

Yeah, Kaspa already implemented it for their UTXO commitments: CHIP 2021-07 UTXO Fastsync - #75 by bitcoincashautist

#82

Peter Rizun was talking about UTXO commitments on Bitcoin Takeover at 1:57:12. Elaborates a little on compact inclusion proofs.

1 Like
#83

Yeah I did a proof of concept using muhash in bchn.

Advantages; much faster

Disadvantage: the data blob for the set itself is not as compact as 33 bytes for ECMH — but rather is 384 bytes. Not huge but not tiny either. So if you wanted to actually embed the set itself into the blockchain (rather than its hash), it’s a bit heavy.

2 Likes
#84

First the obvious;
commitments can work just fine without it being part of the blockchain. LOADS of work to get that done anyway. So the idea to put it in the coinbase is premature by probably several years. I expect that we will never actually need this as software and bandwidth increase fast enough. Though its a cool idea to develop and make ready if I’m wrong.

But the main thing I’d like to point out in regards to the muhash idea is that you can still trivially add a hash in the client (or later in the coinbase) to prove the commitment. All you need to do is move that 384 bytes content to be included in the actual utxo download. Which will be 10GB or so, therefore the extra bytes will not matter.

4 Likes
#86

I would also add that MuHash provides a root hash as a candidate for committing to the UTXO set in a scalable way. This can be used in UTXO commitments because MuHash by itself doesn’t support Merkle-style proofs or direct filtering, UTXO commitments are still essential for upgrading RPA with ECDH-based one-time addresses (like Silent Payments, BIP352). Without them, wallets would need to scan the full UTXO set to detect incoming payments. A commitment scheme that supports inclusion proofs could allow more efficient filtering, making ECDH-based detection more scalable and usable for light clients.

#87

Wait – are you saying MuHash is more compatible with a merkle proof scheme somehow? Can you link me to any resources on this?

#88

Not at all, thanks to BCA for the correction. I’m saying MuHash can be used as a compact way to commit to the UTXO set. The idea is that if we had an auxiliary structure alongside MuHash (like a Merkle accumulator or an index), light clients could use that for proof-based lookups.

Here’s the Bitcoin Core PR using MuHash for compact UTXO commitment but without proofs:

And here’s Utreexo, a Merkle-like accumulator designed to enable UTXO membership proofs for light clients:

So, MuHash could be one example of a compact UTXO set commitment candidate not that MuHash alone supports Merkle proofs. It efficiently provides a root hash, but to enable filtering or inclusion proofs, you need additional proof structures like Merkle trees or accumulators (e.g., Utreexo) for UTXO Merkle-tree commitments.

#89

Given the impressive progress and standardization of zero-knowledge tech, and knowing that this allows to prove expensive computation in a trustless way, it has been suggested that ZKPs could be leveraged to get a proof for a recent UTXO set.

Instead of trusting peers for a checkpointed UTXO set or to require the protocol to enforce miners to provide a commitment to the current UTXO set, this could possibly be done in a trustless way without the protocol complexity just by leveraging ZKPs and the P2P network

I’d love to see some more discussion on this topic in 2026

5 Likes
#90

See this Tweet from Jason with more information about the ZKP for UTXO commit concept.

Seems like it’s the Starkware guys who are most interested in that. That team is in a weird place where they’ve definitely figured out BCH is far superior, but are still erring on the side of sticking to BTC due to either fear of backlash from BTC guys or for investor requirements.

In any case, I wouldn’t put a lot of stock in them actually coming through with BCH solutions (even if it would benefit everyone immensely, including themselves) so if that happens it’s more of a bonus. But realistically we’ll need to find some actual BCH aligned people to look into all this (hard to do because it’s so specialised of course).

1 Like
#91

I guess it is helpful to give a tad more understanding of the scope of fastsync.

The actual concept itself isn’t too big, some people have already done various test implementations and tried out the idea of a full download of the utxo set.
There are various approaches that makes sense and they can be tried in the basic idea of utxo sync.

But there are various parts of infrastructure that are needed to actually create any benefit to the bigger whole of bitcoin cash. And these are not small since they are so core to the full node design.

  1. The storage of the utxo set itself will have to be changed in order to allow something other than a full backup and share of the database. The incremental nature of the sync ID is to be taken into account here, probably some copy on write structure to allow to have multiple snapshots that can be shared via the p2p network.
  2. The block pruning concept as it is today is incompatible with full node duties of a fastsync node. The full node would need to follow something like the design from the whitepaper to avoid losing information on pruning.
  3. Other nodes should be able to get recent blocks that are partly pruned from any fastsync node, to allow the bitcoin cash p2p system to continue to run. This means a new historical block transfer method that can transfer pruned blocks with an intact merkle-proof.

My suggested approach to get fast sync coded is as a first phase to play with the (merkle) proof concepts of the utxo set itself, on a live full node. The ability for a normally synched full node to reach a utxo proof which is hardcoded in the full node at build time would be a powerful first step to allow the operational basic concepts to actually be tested in the real world.

A big release later of the full node this can be expanded.
The full node shipping a utxo set hash means the full node can be kick started from a downloaded utxo set. The caveat is that that full node would be similar to a pruned node today, it can’t be used for SPV servers (either bloom or fulcrum). So this again is a good step to get wider testing but production deployments will be waiting.
The fact that the actual utxo hash is hardcoded at the time of the full node release is a feature, not a bug. It means that every single release major changes are possible without disrupting existing installations. No need to be super specialized in your knowledge and art, a much wider group of people will be able to work on this. Mistakes in the actual utxo proof code won’t have a disrupting effect.

This alone is a LOT of work, as a result it gets more hazy after that as it is predicting an unwritten future. But the ability to have some actual p2p protocol for fast sync is well after these steps, some hash in a block is even harder to predict how we get to that.

ps. I’m not working on this as I did the math and I don’t expect this feature to ever be in need by the network, the growth of hardware and bandwidth, and improvements in software are enough to avoid IBD to become a real problem for bitcoin cash.