CHIP 2021-07 UTXO Fastsync

Cool! I think it could be implemented as just one hash – of the list (could be varints serialized in order) of blocksizes, just 1 more EC point to add to the multiset (subtract old 1, add new 1 on each block). Optimization: keep the hash stream open, just add blocks and dump the function’s output instead of rehashing the whole list every block, cache internal states of the hash function for last 100 blocks so can reorg easily.

So we have freetrader, a person that doesn’t want to talk on anything but text, backing up BCA, who also refuses video or voice chat. Text only.
And they both support a project that is not supported by any of the actually known full node developers, this project is explicitly stated to introduce the one thing that killed BTC.

Lets keep the blocksize properties to the free market, please. Then you don’t need to track the historical size of blocks. Simpler is better.

Did you forget the part where EB is still free to be set by other nodes according to your own scenario? If the market is free to adjust the flat EB, then it is free to automate it, too. Even if BCHN would ship with the algo, other nodes could set it to some flat EB above what’s getting mined.

1 Like

this is off topic on the Fastsync topic. Please don’t rehash previously answered questions on unrelated topics.

So is your comment re. text only, which is completely out of place.

It’s neither not supported, it’s is research, and if we can demonstrate it is good, then maybe it will get more support? Not from you obviously, because you have your fantasy CHIP where everyone magically decides to adjust a consensus-sensitive parameter at their own leisure and everything somehow works out… and I don’t expect you’ll let go of it, so let’s continue talking in circles please.

This is just pure FUD. The objective of the algo is exactly to minimize the risk of getting dead-locked on a flat value ever again.

1 Like

Dude, what’s wrong with you. I’d propose to go on a video chat and figure out why you are not understanding the dynamic of it, but this kind of toxic statements are really not Ok. Being biased for your own idea is fine, but calling a competing idea “fantasy CHIP” is just not Ok.

Not ok dude.

What if it is you who is not understanding?

You’re being toxic in FUDDing this as “the one thing that killed BTC” and bringing my privacy preferences into the discussion.

You’re being biased to your idea of everyone magically somehow communicated when/how to move EB. Same like Javier Gonzales was fantasizing about miner’s BMP chat - got 0.1% hashrate to participate. The market decided alright - not to participate. “fantasy CHIP” is accurate, like it or not.


This argument is complete nonsense.

The reality is that when you want to remain at least semi-anonymous in today’s Internet, you need to remain text-only.

It is way too easy to make a mistake if you make a Video and too hard to scramble your voice properly with also completely nullifying the background noise (including noise from, for example, some AC-powered devices that can give you out because the electrical hum of such devices is strictly dependent on your location, every huge AC transformer gives slightly different hum, which allows law enforcement to find people even if they did not make other mistakes) .

What exactly were you trying to achieve by posting nonsense here?

1 Like

This argument also seems nonsense.

Can you explain precisely how UXTO commitments can kill BCH the same way they killed BTC?

I don’t remember BTC ever implementing anything even remotely resembling UXTO commitments.

1 Like

you misread. That was not claimed by anyone.

That was directly claimed by you. Maybe you miswrote.

Let me remind you, you said:

So we have freetrader, a person that doesn’t want to talk on anything but text, backing up BCA, who also refuses video or voice chat. Text only.
And they both support a project that is not supported by any of the actually known full node developers, this project is explicitly stated to introduce the one thing that killed BTC.

In the topic about UXTO commitments / EDIT: UXTO fastsync.

If this is not what you meant, maybe you should edit your post because it is highly unclear.

Tom seems to be saying that BTC introducing adaptive block sizes like in this proposal (which I support, for now) is what killed BTC.

Ignoring that

  1. BTC didn’t introduce adaptive block sizes

  2. BTC hasn’t been “killed” or even died naturally yet

  3. Full node developers such as BU’s devs - who are also BCH developers - are evidently supportive of adaptive blocksizes, so much so that they just implemented virtually this exact proposal in NEXA (compare Design and operation of the adaptive blocksize feature - credit to BCA for noticing that it’s basically identical)

  4. Tom does not supply any links to statements from other full node developers to back his claim that they do not generally support what’s being proposed here. Maybe it’s because it’s just too early for them to comment, this is a research work in progress after all… But I did not see any other full node developers backing Tom’s “do nothing and leave it to the market” CHIP either.

  5. It isn’t clear which known full node developers do not support this proposal. This thread is there for them to speak up at any time.


Uh, are we all going offtopic now?

This thread is about UXTO Fastsync, not “Asymmetric Moving Maxblocksize Based On Median

This is why pointed out to Tom that his response does not make sense.

This may be confusing ,but since you speak specifically about “this thread” I conclude you are asking people supporting UTXO fastsync to speak up? I think most people support it in principle, waiting for the details.

Here is my voice of support; Supporting UTXO Commitments

move it here => CHIP 2023-01 Ensuring safe permissionless block growth

There is no point.

Your CHIP also does not make sense. The same as Javier Gonzales’ BMP did not make sense.

This topic has been beat to death like 10 times already. It will not work because miners do not make decisions in this ecosystem, they are not active players. They will not be setting any parameters because of network conditions at all, unless some serious catastrophe happens.

What we are doing here is already very offtopic, so I will not explain it more here.

Back on-topic,

Upon re-reading im_uname’s original proposal, I realized I have re-discovered the problem, he had covered it already:

A: This proposal adds additional requirements for any fast-sync schemes: in additional to hash of the UTXO, blocksizes need to be committed and verified as well. Fast-syncing clients should download blocksize commitments and use them to determine consensus maximum blocksize limit for new blocks.

even though he didn’t specify where and how often to commit. I brainstormed it with Josh & Andrew on Tg, in conclusion, quoting myself:

so really the blockiszes commitment could be an entirely separate thing from the utxo commitment, but it would be maybe more practical if they coincided and one could find them in the same block

Also, on Slack, @dagurval told me that Bitcoin Unlimited’s new blockchain has addressed this by including block sizes in their block headers, which is not an option for BCH.

1 Like

This thread received some flags. I invite you to keep focused on the topic in discussion and avoid anything that may look like a personal attack or directed misinterpretation (intentional or not).
For the sake of BCH, let’s focus on what unites us and try to smooth things over with respect.


Do you think it would make sense to split the UTXO buckets using sorting based on locking script instead?

I’m not very sure of the possible implementation, but something where the UTXO set would be sorted by their locking script and then split such that all 128 buckets are of uniform size or close to it.

Here, the snapshot SubBucket Metadata may then look like:

Field Name Byte Count Format Description
public key 33 public key, big endian The secp256k1 point of the EC multiset for this UTXO snapshot sub-bucket.
start lockingScriptByteCount 1-4 compact variable length integer The number of bytes in the starting** locking script of the SubBucket (as a compact variable length integer).
start lockingScript ? big endian The starting** locking script of the SubBucket (“scriptPubKey”, “pk_script”).
byte count 8 integer, little endian The number of bytes within this UTXO snapshot sub-bucket. The sum of these must equal the byte count of the snapshot bucket.

** The ending lockingScript of a SubBucket is the starting lockingScript of the next.


  • This can foster a new kind of light wallet that can easily query their UTXO set from nodes. The wallet can query extra SubBuckets or SubBuckets from different nodes to circumvent nodes omitting UTXOs by not following the ordering. By checking the ordering in the SubBucket and its EC mutliset, the wallet can determine if the node follows the UTXO ordering.
  • The wallet may maintain the privacy of the user by downloading extra SubBuckets to obfuscate the intended locking script query. These extra SubBuckets can also be used to check the UTXO ordering of the node.
  • Such wallets won’t have to build a history of transactions over the blockchain or query the entire UTXO set. This gets even safer if the EC multiset is committed to the block header.
  • Since such UTXO set is generated once per block, a node does not need to generate additional filters for each wallet subscribing to a locking script (or maybe my understanding of SPV is at fault).


  • Will add overhead of splitting the UTXO algorithmically. However, clever schemes of passing UTXO sets from one SubBucket to another can leverage the O(n) operation of generating EC multiset.
  • Nodes may not follow the UTXO ordering so closely, and will lead to omission of UTXOs.
  • Increases the size of P2P UTXO Commitments (“utxocmts”) message.
  • The UTXO set may be flooded by UTXO with the same locking script to make the ordering and SubBucket formation difficult.
1 Like

I don’t know what the current state of these UTXO committment ideas are, but Tadje Dryja of Lightning Network fame did a whole talk about block size increases and a “proof of inclusion” UTXO system to scale on-chain on BTC. Interesting idea to observe.

1 Like