CHIP 2021-07 UTXO Fastsync

CHIPs Standards Track
,
#21

Interaction between UTXO commitments and a proposed excessive blocksize adjustment algorithm has been bugging me because the internal state of the algorithm would also be part of “current state”, but commiting the algo’s state would make the algorithm a new consensus rule, and any tweaking of algorithm’s parameters would require messing with the commitments code.

Thankfully there’s a way around that: commit only actual mined block sizes. Then clients can get the whole block sizes dataset (about 9MB now) when they do IBD, validate it against the commitment, and then compute the algo’s current state. This way, in case of need be, we could revert to flat limit, tweak or change the algo, and there wouldn’t be any baggage of the old algo.

Could the specification be extended to add the block size data?

3 Likes
General Protocols: Opinions and considerations on a maxblocksize adjustment scheme
CHIP 2023-04 Adaptive Blocksize Limit Algorithm for Bitcoin Cash
#22

I support this idea to extend the committed data to include prior block sizes.

1 Like
#23

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.

#24

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.

#25

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
#26

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

#27

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.

2 Likes
#28

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.

#29

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.

3 Likes
#30

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?

2 Likes
#31

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
#32

you misread. That was not claimed by anyone.

#33

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.

#34

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.

2 Likes
#35

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.

#36

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

#37

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

#38

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.

#39

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
#40

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.
Thanks.

5 Likes