03:06:54 <br-m> <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."
03:06:54 <br-m> <sgp_> "It" means reorgs deeper than 10 blocks right?
03:06:54 <br-m> <sgp_> In your testing, is the frequency of 10+ block reorgs always lower (vs nakamoto) for all α values ≤50%?
06:48:11 <tevador> sgp_: "it" means "the attacker including honest workshares", I clarified the comment.
06:48:34 <tevador> sgp_: Yes, although with α=0.5, the effect is quite small (10+ reorg period goes from 45 minutes to 1.5 hours).
07:54:57 <br-m> <venture> Hi tevador: thanks for the proposal.
07:54:57 <br-m> <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
09:22:09 <br-m> <venture> 8 -> 24 rather.. not 100
11:07:53 <br-m> <venture> ah, I overlooked the tx_extra implications. 
11:10:17 <DataHoarder> If these are included as part of the merge mining tag most solutions out there that do Tari mining could take it
11:10:55 <DataHoarder> Including p2pool, to verify would need the work shares and well, the merkle proof for that merkle root
12:06:48 <br-m> <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
12:08:49 <br-m> <venture> and includes all shares with the same prev_id and unique (probably just picks one) version_minor + potential uncles
12:19:10 <br-m> <venture> I'm otherwise not sure how ascending version_minor shares and increase the version-number works with share_seen - block_seen <= d
12:40:36 <br-m> <venture> avg time for a share would be 120s/8 = 15s, so having d=5s is maybe too low for shares?
12:52:19 <br-m> <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
15:53:27 <br-m> <venture> tevador:  should the condition in table 5 read: block_seen - share_seen <= d ? instead of share_seen - block_seen <= d
16:31:50 <tevador> venture: Yes, fixed. Thanks.
16:34:10 <tevador> Uncle block are inherited from PoP. Notice that SoP with w=1 becomes PoP.
16:34:37 <tevador> blocks*
16:35:50 <tevador> *Nearly becomes PoP, except for the partition reovery condition, which is slightly different.
17:41:35 <br-m> <venture> ah nice :) The typo quite derailed me and I first thought block-seen was referring the previous one. 
17:42:41 <br-m> <venture> tevador: "Uncle block are inherited from PoP. Notice that SoP with w=1 becomes PoP."
17:42:41 <br-m> <venture> Is the general assumption correct that with a higher w, eg, 24, orphans/uncles would be less of an issue?
18:50:24 <br-m> <venture> sorry. you mentioned it already in the GH-comment "Note that increasing w doesn't help much against this strategy."
18:50:24 <br-m> <venture> So, version_minor solution looks promising. Getting close to 5-6 years for 10+ reorg with 33% hashrate would be awesome
21:36:25 <tevador> 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.