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
@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).
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 looked
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.
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
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)
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
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
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