CHIP-2025-03 Faster Blocks for Bitcoin Cash

#50

Unsure if asking for my thoughts on something specific in this thread or the CHIP in general.

I do not want to rehash the discussion about the merits of tailstorm so i will focus on the issues i have with the implementation of the tick system outlined in the CHIP. To me it seems his chip seems like a giant trade-off between getting some features of tailstorm and having a tick system spread throughout the codebase vs implementing tailstorm itself and not needing the tick system.

I understand tailstorm itself is a decent amount of work to implement but it does not touch the external systems nearly as much as this tick system. A lot of the tailstorm changes are internal to the tailstorm protocol and would only be preset in the tailstorm section of the code.

As noted in the technical description here, the tick system changes the subsidy schedule, DAA, ABLA, timekeeping in both script and the tx level, coinbase comments, sigchecks, blockheader rate, and rpcs. Tailstorm does not change most of those things in any significant way.

  • DAA, ABLA, timekeeping, sigchecks, and block header rates - All of these are unchanged in tailstorm. They would only update every ~10 minutes when new summary blocks are published. Same as they do now for bitcoin blocks.
  • coinbase comments - i do not think these would change at all either but i would have to check the bch tailstorm testnet code to be sure.
  • subsidy schedule - This would remain the same at the summary block level in terms of blocks mined. no shortfall that would cause it to end sooner. The total amount paid out might be slightly less than the 21M target, but the last block that pays a subsidy is the same.
  • rpcs - yeah, additional rpcs would be needed.
  • As for future proofing… Because there is no need to store all full subblocks after a summary block is formed, changing K should always be a backwards compatible change keeping the calculations that involve K relatively clean. add in some if statements relevant to the fork, post fork remove the if statements and only use the new value. eliminating the need for annoying calculations like this one tick = H_a * 600 + (H_b - H_a) * 60 + (height - H_b) * 30 every time there is a HF to tweak the tick rate

Idk. i find it preferable to keep the changes contained. I am not particularly a fan of the tick system for that reason. it touches too much.

3 Likes
#51

Hey thanks for having a look at the CHIP! (note my orphan rate analysis is off a little, need to correct it)

What makes Tailstorm Tailstorm? Is it the uncle branch merging / reward system, or the faster-blocks-as-a-soft-fork aspect of it?

You could retrofit Tailstorm merging to this tick system, and we could just have faster blocks as “subchains” without the merging system. Basically we have 4 options:

Uncle merging No uncle merging
Target time change Outer Tailstorm Faster Blockchain
Blocks subdivision Tailstorm Subchains

Talked about “outer” Tailstorm here.

So your preference is with the subdivision approach, got it! Uncle merging only affects consequences of branching rate. The inner/outer approach affects impact on downstream software and affected consensus rules. Let’s just assume we don’t want merging and focus on this aspect. Call it subchains.
I already made a comparison table here, but you made me realize there’s more to consider.

Does this mean that with original Tailstorm you don’t get the benefits of increased time granularity in contracts?

Those wanting to consider subconfs still need to switch to some new rpcs. Difference is opt-in vs breaking. Thankfully we can update RPCs ahead of faster blocks HF and encourage switching beforehand so the HF goes smooth. Example:

image_2025-04-22_09-53-35

There’s another way to eliminate it: turn the block time into a state associated with each block like ABLA’s internal state. That would make it possible to have variable block time (like Kaspa and Nervos have), but I think there’s no need for that and has many unknowns on game mechanics.
Anyway, it’s a simple calculation easy to extend a bunch of times, we don’t expect to make more than a few adjustments.

#52

This is an excellent point!

2 Likes
#53

Yes, and by implementing Avalanche we will remove the incentive for big miners to centralize because of high orphan rate. Because under Avalanche it will no longer be up to the miners which block they can build on.

#54

This isn’t the status quo, though. They’re not centralizing because of high orphan rate because we don’t have high orphan rate, and 1-2% if switching to faster blocks will still not be high enough to have meaningful centralizing effect.

2 Likes
#55

Indeed, you are correct my friend :slight_smile:

2 Likes
#56

Tailstorm subblocks are not blocks. The blockchain is only updated when a summary block is published. You can use the depth of a subblock in the tree to calculate the probability that a tx will be included in the next block. for example, if you issue a tx right after a summary block is issued it should show up in the first subblock. every subblock after that increases the odds that your tx will be in the next summary block. under the current bitcoin model you have to wait for the next block to be mined to know if your tx got mined. i have the formula for that somewhere…
But subblocks themselves are not a new block in the blockchain. This is why it does not affect any of tx time stuff or other things i mentioned earlier.

I guess it is also worth mentioning that in the implementation of tailstorm we wrote that two subblocks with competing transactions (spent the same inputs in different ways) were not allowed in the same subblock tree. if two subblocks like this were mined then the node keeps track of two trees, three if there were 3 competing subblocks, and so on. Only one tree in this forest would become the next summary block. subblocks not in the tree that got completed to become a summary block were entirely discarded and they had no affect on the mining rewards the summary block paid.

3 Likes
#57

And to just reiterate, faster blocks with tailstorm would theoretically see lower orphan rates than faster blocks without tailstorm, correct? The more subblocks the lower the orphan rate (though iirc there are diminishing returns (but the returns are less diminishing as you go to faster block times - i.e. as block times shorten, you benefit from a greater quantity of subblocks)).

#58

Screenshot 2025-04-25 at 10.37.27
Screenshot 2025-04-25 at 10.37.27998×736 38.8 KB

Yeah, just pulled up my old recalculation of orphan rates (original table had some flaw) and I believe what I stated here is accurate. Basically, as block times shorten, the delta between orphan rates, as subblock quantity increases, remains higher compared to the same subblock quantities with longer block times. But confirmation still would be helpful!

#59

Hm, now that I’m thinking about this, I should create a new table that actually lowers the blocksize as the block interval shortens. That would give an even clearer picture. I believe the above is actually keeping 32MB blocks even at the shorter intervals. Let me do this and post a new table.

#60

The problem with Tailstorm is that it’s still just PoW.

PoW will never provide much economic security at the tip of the chain, and this is still true with a massive amount of tail emission.

#61

Screenshot 2025-04-25 at 11.00.27
Screenshot 2025-04-25 at 11.00.271228×1376 218 KB

Interesting! So when I update for block size diminishing returns does come back at faster block times. Which actually makes sense.

Now, these are high orphan rate maxes but this is also assuming a latency of 5 seconds (per the tailstorm paper). I can update for a more realistic one if requested.

1 Like
#62

yes but it’s an accounting trick

you see same forking rate, you just don’t count subblock forks because they get merged, right?

w/o talstorm: fork rate = orphan rate
w/ tailstorm: fork rate = orphan rate + uncle rate

#63

@bitcoincashautist Is there a reason you are using the orphan rate cap calc you have in the CHIP vs the one used in the tailstorm paper? The tailstorm paper formula was derived from Peter Rizzun’s orphan rate calc ( Peter R. Rizun. Subchains: A technique to scale bitcoin and improve the user experience. Ledger, 1:38–52, 2016.), which provide the below orphan rates at different block times (I adapted one to represent 1min blocks).

Screenshot 2025-04-25 at 11.54.04
Screenshot 2025-04-25 at 11.54.041188×394 78.2 KB

There are notably lower orphan rate limits. Tho perhaps I’m missing something.
Also, this paper might be a great reference for other things if you haven’t already lookedSubchains_A_Technique_to_Scale_Bitcoin_and_Improve.pdf|attachment (1.3 MB)

#64

I think the CHIP uses basically the same formula as k=1, just a bit rearranged, and different latency and bandwidth (or impedance, if you will, which is 1/bandwidth) estimates.

#65

Is it, though? I’m not certain, as I recall from reading the paper because of the parallel PoW mechanism, there might actually be less overall waste. But, I could absolutely be wrong here and as I’m not an expert, I’ll drop that here haha
The other benefits of tailstorm are irrelevant here so I’ll look back and mention on another chain.
Also, none of this CHIP would prevent tailstorm from being implemented in the future, if deemed necessary, so again, mostly irrelevant discussion for here beyond orphan rates.

1 Like
#66

yes there is less scrapped work, so network gets more bang-for-the-buck, but is that really the thing to optimize for? saving some % in orphan rate “buys” us that much % more hashes per unit of block revenue, that’s it - just few % more hashes per block. We can just wait for the price go up for that much % and we’ll get that much more hashes, too.

One more thing, just reducing to 1-min blocks should be compared to tailstorm of T=10min and k=10, so 0.887% vs 0.089% (for 0.5s latency)

#67

Well because that’s not the only benefit, the other (which idk is relevant to this topic) is making mining more fair and punishing selfish miners (amongst others like weak PoW which could have some benefit, and reduced confirmation latency, censorship resistance to varying degrees (which lower block times also help with!)) at the same time. Tailstorm is a nice wrap-up of general improvements.

I don’t believe so. The 1min block times without tailstorm should be compared to 1min block times with tailstorm. But I suppose that depends on the angle you’re looking at it from. I would compare 1min with to 1min without. Not a major difference but a bigger one.

1 Like
#68

The 1min block time with tailstorm k=15 will have 4second subblocks and a huge uncle rate, which is not seen in the table, can’t just sweep that under the rug. Game mechanics of 4s subblocks and all those uncles and uncle trees haven’t been analyzed enough IMO + there’s the issue of 0 block subsidy, what then? How does the “fair” feature work out then?

1 Like
#69

I think part of the analysis is that k-15 is too great anyways. Diminishing returns with more subblocks. k=3 or k=5 would obtain most of the benefit. Perhaps the mechanics have not been analyzed enough yet, but gaming is less fruitful when the rewards are discounted. The point of 0 block subsidy in the far future which I believe is why attack vectors considering transaction fees (which I can’t imagine would be worse with tailstorm, just equivalent (though perhaps this itself would need to be further explored)) were outside the scope of the original tailstorm paper.

But sure, let’s say 12 second subblocks (though given the tree structure not sure 12s is necessarily accurate across all cases since you could have multiple branches with discounted rewards), that certainly would increase the “uncle” rate but how drastic, I’m not actually sure. Back to the gaming of it, absolutely, further analysis would be needed.

Either way, this all makes me excited for Nexa’s implementation of Tailstorm with their 2min blocks. Perhaps not apples to apples, but should be very close for us to examine!

2 Likes