<sgp_> "If the attacker doesn't include honest workshares in his first private block, achieving a 10+ reorg is nearly impossible. However, I can't think of any way to prevent it. Note that increasing w doesn't help much against this strategy."

<sgp_> "It" means reorgs deeper than 10 blocks right?

<sgp_> In your testing, is the frequency of 10+ block reorgs always lower (vs nakamoto) for all α values ≤50%?

sgp_: "it" means "the attacker including honest workshares", I clarified the comment.

sgp_: Yes, although with α=0.5, the effect is quite small (10+ reorg period goes from 45 minutes to 1.5 hours).

<venture> Hi tevador: thanks for the proposal.

<venture> Is the reason for having uncles and workshares cost-related? For example increasing the workshare ratio from 8 to 100 and no uncles would be too much verification cost for nodes? I'm wondering because I think the h <= t - 10*w fallback could still be applied

<venture> 8 -> 24 rather.. not 100

<venture> ah, I overlooked the tx_extra implications.

If these are included as part of the merge mining tag most solutions out there that do Tari mining could take it

Including p2pool, to verify would need the work shares and well, the merkle proof for that merkle root

<venture> so, with the version_minor modification, miners would split there hashrate by 8 and mine shares. Eventually one of the shares also meet the target for being a block

<venture> and includes all shares with the same prev_id and unique (probably just picks one) version_minor + potential uncles

<venture> I'm otherwise not sure how ascending version_minor shares and increase the version-number works with share_seen - block_seen <= d

<venture> avg time for a share would be 120s/8 = 15s, so having d=5s is maybe too low for shares?

<venture> hmm never mind. block_seen references the containing block (thought it references the last block the shares are mining upon).. so this is somewhat unrelated to mining-rate

<venture> tevador: should the condition in table 5 read: block_seen - share_seen <= d ? instead of share_seen - block_seen <= d

venture: Yes, fixed. Thanks.

Uncle block are inherited from PoP. Notice that SoP with w=1 becomes PoP.

blocks*

*Nearly becomes PoP, except for the partition reovery condition, which is slightly different.

<venture> ah nice :) The typo quite derailed me and I first thought block-seen was referring the previous one.

<venture> tevador: "Uncle block are inherited from PoP. Notice that SoP with w=1 becomes PoP."

<venture> Is the general assumption correct that with a higher w, eg, 24, orphans/uncles would be less of an issue?

<venture> sorry. you mentioned it already in the GH-comment "Note that increasing w doesn't help much against this strategy."

<venture> So, version_minor solution looks promising. Getting close to 5-6 years for 10+ reorg with 33% hashrate would be awesome

A few observations after improving the attacker strategy (stubborn mining and some tweaks): 1) W=16 is probably worth it. 2) Uncle blocks have to go. 3) The version_minor rule is a must.