02:06:16 <m-relay> <g​ingeropolous:monero.social> i wonder if the things have been worked out regarding miners creating empty blocks in an attempt to keep the medians artificially low.
02:08:16 <m-relay> <g​ingeropolous:monero.social> like if the 2 top pool right now just said "nope, we're just gonna keep on making 300 kb blocks, even though there's a txpool backlog"
02:09:16 <m-relay> <g​ingeropolous:monero.social> i guess the bleedover of the txs paying to try and get into the major pool blocks that end up in the minor pool blocks would eventually shift the median
02:10:12 <m-relay> <g​ingeropolous:monero.social> though the majors could perform some block withholding....
02:12:01 <m-relay> <g​ingeropolous:monero.social> and if its the top 3 pools, thats damn near 75% currently, so the minors could barely shift the median. Though there is the possibility (or really, the pooled-mining panacea) that the miners will migrate. Though if its paying more in rewards, would miners move?
02:31:11 <m-relay> <g​ingeropolous:monero.social> i wonder if that could be detected. Like if you have a consistent looking window for that median analysis, and it doesn't change (it stays top heavy, if the window  is 100, the first 75 are 300 kb, and then the remaining 25 are are 300+ ... and it stays this way for like n windows of 100,) then that means that this particular artificial capping attack is occuring
02:31:38 <m-relay> <g​ingeropolous:monero.social> a normal drive in tx volume would cause the median to "tick over"
02:32:02 <m-relay> <g​ingeropolous:monero.social> maybe. I wonder if our larger median takes care of this, the higher time rolling one
02:33:45 <m-relay> <g​ingeropolous:monero.social> though this could occur at whatever penalty free zone is. doesn't have to be the default 300kb
02:34:40 <m-relay> <g​ingeropolous:monero.social> well they'd still be incentivized to drive it down to 300 i guess.
03:06:43 <m-relay> <g​ingeropolous:monero.social> i thinki broke gemini with this one
03:16:28 <m-relay> <g​ingeropolous:monero.social> dude its still going
03:16:37 <m-relay> <g​ingeropolous:monero.social> i've probably used like 2 cities worth of power
13:33:43 <m-relay> <m​onero.arbo:matrix.org> Need one of the major pools to make miners build their own block templates
14:27:15 <m-relay> <g​ingeropolous:monero.social> that just kicks the can to a different attacker, the miner themselves. A large hashrate miner could still mine on artificially capped block templates
14:42:24 <m-relay> <g​ingeropolous:monero.social> if anyones interested in the AI slop output, its here: https://gingeropolous.github.io/xmr_blocksize_suppression/block_suppression_cl.html
14:42:50 <m-relay> <g​ingeropolous:monero.social> gonna make me an AI slop smoothie
14:44:27 <m-relay> <g​ingeropolous:monero.social> currently gemini is choking on revisions to the report and a request to analyze the mitigation strategy i proposed. I think i need to restart with the 1st report in the primary ingest.
18:48:18 <m-relay> <e​longated:matrix.org> Divisor are off the table or will be researched further ?
19:03:30 <m-relay> <r​ucknium:monero.social> Probably researched further. AFAIK, that question will be discussed at the next MRL meeting Wednesday.
19:48:19 <Pyongyang_cutie> https://ibb.co/B2p8FgNd
19:48:42 <m-relay> <s​yntheticbird:monero.social> plowsof
19:53:48 <ofrnxmr> luigi1111
20:30:46 <m-relay> <m​onero.arbo:matrix.org> yeah but at that point it's a classic 51% attack, just not one that tries to double spend