06:52:09 <m-relay> <o​range_horizon:matrix.org> I guess that would necessitate the block time being more variable.
13:48:00 <m-relay> <m​onero.arbo:matrix.org> I guess monerod would need to keep orphans which I think it currently deletes on restart, cause newly syncing nodes would need to download orphans to verify that difficulty is correct
15:44:57 <m-relay> <v​enture:monero.social> came to the conclusion that selfish-mining cannot be prevented when the pool's share (alpha) is > 33%. 
15:44:59 <m-relay> <v​enture:monero.social> Not sure if it's worthwhile to try to establish that bound (currently, depending on connectivity of the attacker's pool (gamma), less than 33% may also selfish-mine)
16:00:44 <m-relay> <j​ack_ma_blabla:matrix.org> keep running around pow only solutions
16:06:14 <m-relay> <v​enture:monero.social> pos has similar bounds? 33%
16:53:26 <m-relay> <v​enture:monero.social> the thing about PoW attacks is that they come out of nowhere, the hashrate pointed to secret chains is hardly known beforehand (maybe with the caveat that of detective mining and a known attacker).
16:55:26 <m-relay> <v​enture:monero.social> it would be interesting to explore how this changes, if every miner mines at 1/3 capacity and fires up the cylinders when a re-org is attempted, which would need to be ignored with the hope that 1/1 capacity wins the race eventually
16:56:17 <m-relay> <o​frnxmr:xmr.mx> When a reorg is attempted, its too late
16:56:28 <m-relay> <o​frnxmr:xmr.mx> You'll be.. reorged onto the reorg
16:57:47 <m-relay> <v​enture:monero.social> yeah :) requires some changes.. *would need to be ignored until you fall behind too much, or you caught up with 100% capacity
17:01:24 <m-relay> <v​enture:monero.social> but that's a prisoner's dilemma kind of thing. would only work if you knew other's do the same
17:03:48 <m-relay> <o​frnxmr:xmr.mx> I dont see what changes aside from "ignore reorgs" which cant dis<ri"inate between honest and malicious
17:05:21 <m-relay> <v​enture:monero.social> you probably would first want to get rid of gamma (=0), ie. attacker's ability to perform "match", which limits selfish-mine action space to override and wait (table 4/p.14 of the paper "Optimal Selfish Mining Strategies in Bitcoin")
17:06:16 <m-relay> <v​enture:monero.social> you can't discriminate, you need to just choose one. but the rewards of the orphan would somehow need to shared
17:06:50 <m-relay> <o​frnxmr:xmr.mx> that would incentivize selfish mining
17:07:15 <m-relay> <o​frnxmr:xmr.mx> Since you get paid fir your attempts in addition to your success
17:10:00 <m-relay> <v​enture:monero.social> not in addition though. you would be paid less and the other half would go to the orphan. but it's hard to implement in monero
17:16:07 <m-relay> <v​enture:monero.social> this is something else: https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925 I just stumbled upon, not related to the previous discussion, just fyi, haven't read through yet
17:19:27 <m-relay> <v​enture:monero.social> lol, it's a hybrid model