00:41:33 <m-relay> <b​oog900:monero.social> has anyone noticed there seems to be a miner not filling blocks as much as they can, sometimes leaving them empty when there are plenty of txs.
00:41:53 <m-relay> <b​oog900:monero.social> they seem to be merge mining.
00:42:32 <m-relay> <b​oog900:monero.social> for example: 3416870, 3416869, 3416868
00:43:07 <m-relay> <b​oog900:monero.social> and there are more I can see just going back from those heights
00:48:59 <m-relay> <b​oog900:monero.social> add 3416871 to the list
00:51:41 <m-relay> <b​oog900:monero.social> `3416868` was from https://www.supportxmr.com which is the one that acctually contains txs, although they didn't fill the template as much as they could. The others have no txs
00:52:45 <m-relay> <b​oog900:monero.social> 3416872 finally has txs
00:55:08 <m-relay> <b​oog900:monero.social> https://monero.hashvault.pro/en/blocks
00:55:26 <m-relay> <b​oog900:monero.social> its those guys^
00:56:39 <nioc> there was a pool that had a large % of the blocks it found had no txs because there was something wrong with their implementation which they corrected  
00:57:02 <nioc> this is to say that it is not always intentional
00:57:27 <nioc> I assume hashvault and support are set up correctly 
00:58:38 <nioc> well they used to be set up correctly b4 merge mining
02:25:59 <m-relay> <m​onero.arbo:matrix.org> it was also happening with MoneroOcean but seems fixed now
05:46:48 <sech1> Tari's merge mining proxy had a bug, so some pools had to mine empty blocks for a while.
13:50:02 <m-relay> <b​oog900:monero.social> well lets hope they update soon, all their blocks from the past day have had no txs
13:50:48 <sech1> XMR empty blocks        : 19.9 %
13:50:49 <sech1> not good
13:50:55 <sech1> in the last 360 blocks
13:51:36 <sech1> more tx fees for p2pool though
13:52:12 <sech1> I think it can only hurt the network if >50% of the blocks are empty. Then dynamic block size will not work (median size will be 0)
13:52:59 <sech1> paradoxically, 20% empty blocks _increase_ the median block size. Because the other 80% blocks are more full now
13:59:58 <m-relay> <o​frnxmr:xmr.mx> I was thinking about that the other day. Why do we use median instead ofmean
14:00:50 <sech1> to cut off outliers? Median is more reliable to show the most common value
14:28:08 <m-relay> <a​ntilt:we2.ee> in bitcoind a single empty block would increase your ban score +100, blocking the peer for 24h ...
14:28:56 <m-relay> <s​yntheticbird:monero.social> What about 1 tx block huh?
14:29:06 <m-relay> <b​oog900:monero.social> what really? surly that could cause netsplits
14:29:27 <sech1> how would it even work
14:29:38 <sech1> blocks are propagated by all peers in the network, including empty blocks
14:30:07 <m-relay> <a​ntilt:we2.ee> tbh - depriciated. But see:
14:31:50 <m-relay> <a​ntilt:we2.ee> https://par.nsf.gov/servlets/purl/10407054
14:32:00 <m-relay> <a​ntilt:we2.ee> "The Security Investigation of Ban Score and
14:32:02 <m-relay> <a​ntilt:we2.ee> Misbehavior Tracking in Bitcoin Network"
14:33:51 <m-relay> <a​ntilt:we2.ee> (table of ban rules p.3)
14:34:04 <sech1> no empty blocks in that table
14:35:23 <m-relay> <a​ntilt:we2.ee> emty != invalid ? # mea culpa...
14:35:24 <m-relay> <a​ntilt:we2.ee> *empty
14:36:22 <m-relay> <b​oog900:monero.social> https://xmrchain.net/block/3417277
14:36:34 <m-relay> <b​oog900:monero.social> just means no txs other than the miner tx
14:38:45 <sech1> empty blocks are perfectly valid
14:39:06 <sech1> imagine there is not transactions in mempool, then empty blocks must be valid for the blockchain to keep going
14:39:20 <m-relay> <a​ntilt:we2.ee> sry, i see.
14:42:13 <m-relay> <a​ntilt:we2.ee> maybe I was triggered because I research statistical abnormality detection atm ...
15:42:30 <m-relay> <a​ntilt:we2.ee> ... and this rise in (merge mined) hash rate is a little bit too quick, for my taste.
18:57:15 <m-relay> <g​ingeropolous:monero.social> yeah. maybe its the x6.... dun dun dunnnnn