Can you TLDR me, what is going on here? How can I best contribute to the discussion? Is it productive to discuss the merits of Tailstorm here? I think we have done that excessively in another thread.
@bitcoincashautist should consider adding the benefit for node operators since each block will require less memory and CPU cycles.
1 Like
Absolutely. Just high level!
In terms of the above couple comments (two brief points below):
- Could the deterministic tiebreaker
be a way to assume most of Tailstorm in a simpler matter?
2. Would uncle+orphan rate on Tailstorm for x second blocks be the same roughly as orphan rate for x second blocks, and very high level what the actual end difference would be if any.
Sorry yeah I know largely discussed but in this context just curious to hear from your perspective!
1 Like
Deterministic Tie Breaker. My understanding is that whenever honest miners see two competing chains on the same height, they will deterministically select one of the chains as preferred chain. This is in contrast to the current solution where miners prefer the chain first received. This change ensures that all honest miners agree on the tip of the chain, in cases where it is ambiguous.
In a benign network, where everybody acts honestly, this would reduce unfairness. But as a pool operator I would certainly modify the software to prefer my own block instead of discarding it. If all pool operators think like me, weāre back at square one regarding fairness.
Regarding selfish mining: I assume youāre familiar with the attack models of Sapirshtein/Sompolinsky/Zohar or Bar-Zur/Eyal/Tamar. They give the attacker some means to reorder messages: if one block of height n shows up, they can send their own block of height n (if they have any) with the MATCH action. Fraction \gamma of the defenders will continue mining on the attackers block. If you now add your hash-based tie breaker, this reordering will work in 50% of the cases and should be at least as bad as assuming \gamma = 0.5 in the other model. I say at least as bad because the attacker knows in advance whether the MATCH will work and probably can adjust his strategy based on that.
Uncle+Orphan rate. Iām not sure what you mean with uncles, as Tailstorm does not have any. It has trees of k subblocks between each pair of summary blocks. It discounts rewards based on the height of this tree. Probably you mean, if the subblock tree has height k - i, there are i uncles on this tree? Then the uncle+orphan rate in tailstorm with subblock interval n seconds should be about the same as the orphan rate in BCH with n seconds block interval. Assuming propagation times of Tailstorm subblocks and BCH blocks are the same.
1 Like
Itās assuming youād do this, so dominant pool hash-rate wise still has its advantages. However, it would use the tie-breaker on blocks received from others, so pools with higher ping would still have a chance of winning races.
Wouldnāt expected ROI be negative? E.g. you had a valid block with no competition and you withheld it then in doing so you allowed someone else to mine a block that will flip yours with 50:50 chance.
What if we donāt give attackers the time? Independent researcher zawy was suggesting to enforce block timestamps to be monotonic (each block must advance at least by 1 second) AND have nodes have very strict future time limit (e.g. max. 6 seconds ahead of their local clock).
It has whole uncle branches, we could call it branch rate or something. Anyway, thanks for confirming that the branch rate is the same no matter what you do on a branching event (orphan or merge).
All these schemes rely on changing the impact of branching. We canāt remove branching at the lowest unit of PoW.
Yes, thatās right.
The mentioned papers make it clear that the ROI is positive for strong miners and \gamma = 0.5. Itās even positive for \gamma = 0 (no reordering possbile). I argue that your change achieves something similar to \gamma = 0.5. Whether this an improvement or not depends on whether you find \gamma = 0.5 a realistic network assumption.
Well, withholding gives the attacker more time to mine the next block. Your flip scenario applies if the attacker is unlucky and cannot mine a block in time. But if he is lucky, he now has a private chain of height n+1 while the defenders are still indecisive about height n. With the deterministic tie breaker they are decisive about height n, but this does not help with respect to the n+1 chain.
2 Likes
I support this. It does not add any barriers for implementing proper economic security through Avalanche down the line. An argument that seems to be missing in this debate, is that faster blocks increase censorship resistance since itās easier for solo miners and small pools to find a block. As long as orphan rate is reasonable and you donāt centralize because of this.
3 Likes
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) * 30every 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
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:
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.
This is an excellent point!
2 Likes
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.
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.
3 Likes
Indeed, you are correct my friend 
2 Likes
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
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)).
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!
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.
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.
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