15:23:41 <Rucknium[m]> Either the minexmr website has just been hacked, or this is huge news: https://minexmr.com/
15:23:59 <Rucknium[m]> "We regret to inform our valued miners that the pool will be closing on August 12."
15:23:59 <Rucknium[m]> Big if true.
15:24:31 <merope> ooooooh
15:24:59 <merope> Or maybe it's their way of solving the centralization problem directly
15:25:24 <hyc> if it pushes the majority of miners to p2pool, yeah that'll be a huge help
15:31:40 <xmrack[m]> Wow, will definitely be interesting to watch. Hopefully the network hashrate wont take too big of a hit
15:32:12 <merope> I just hope they don't all move into the same pool
15:38:16 <HenryHollingwort> I wouldn't mind seeing minexmr release a dead easy, nice gui application which wraps p2pool and then distributes miners across pools appropriately (I imagine they would run these pools, and the gui app would auto-configure p2pool). Would provide an easy experience for them, they can maintain the pools and take a small % via the app (similar to xmrrig). 
15:38:43 <HenryHollingwort> as a stepping stone perhaps
15:44:50 <zoom0ut> much easier to move to a new pool than use p2pool
15:53:50 <xmrack[m]> Can p2pool work with a pruned node?
15:54:16 <merope> yes
17:31:45 <gingeropolous> definitely "fun" right at a hard fork
17:37:38 <tx_extra[m]> hello again! dropping by to announce that this room is now relayed to the Monero blockchain using tx_extra
17:37:43 <tx_extra[m]> follow #monero-research-lab directly from your daemon or visit mrlonchain.net
17:40:31 <gingeropolous> good lord
17:41:08 <plowsof> hello world
17:41:55 <xmrack[m]> I guess thats one way to prove a point
17:44:01 <merope> anyone against kicking the relay bot?
17:56:45 <moneromooo> You're a cunt, but you could be even more of a cunt by spamming txes anyway, since tx extra just takes space, not verification time.
17:57:43 <ofrnxmr[m]> <tx_extra[m]> "follow #monero-research-lab..." <- Why wont she load in tor browser :(
18:01:40 <ofrnxmr[m]> 🫣 now why'd we do that? (kick tx extra) 
18:02:35 <merope> because it's useless bloat
18:03:24 <tx_extra[m]> i think i made my point, i'll turn this off now
18:04:06 <moneromooo> OK, then I take back my comment :D
18:04:17 <moneromooo> (unless you start spamming txes)
18:04:46 <merope> your point being that we can't have nice things because people are assholes? I don't think we needed a reminder
18:05:42 <moneromooo> Though actually, thinking about it, I had it in my list for a while now to move tx pubkeys out of tx_extra.
18:06:11 <UkoeHB> moneromooo: that's what I have done with my seraphis stuff
18:06:20 <moneromooo> This would allow making there is just one, etc, etc. More rigidity. Though smooth made the point that a pubkey is actually optional, whic his a fair point I guess.
18:06:33 <moneromooo> And doing this would allow us to have extra be prunable.
18:06:39 <moneromooo> UkoeHB: good, thanks.
18:09:14 <kayabanerve[m]> <tx_extra[m]> "i think i made my point, i'll..." <- You got my message about the bee movie yet not about ZtM :( 
18:09:28 <kayabanerve[m]> But yes, let's not spam the chain please
18:09:34 <kayabanerve[m]> Thanks for turning it off
18:10:04 <kayabanerve[m]> moneromooo: I support this being delayed to Seraphis, but there is the larger question about what's for Seraphis and what isn't...
18:10:53 <kayabanerve[m]> Guaranteed addresses, which I deprecated my proposal for featured addresses (including GAs), solved a problem from now to avoid Seraphis's wait
18:11:16 <kayabanerve[m]> We obviously have things to improve. I think the question becomes is seraphis the next hard fork or not for our organization
18:11:47 <rbrunner> "i think i made my point, i'll turn this off now" And turn it on again if you don't like the speed of progress in this matter?
18:12:07 <tx_extra[m]> no, i'm not interested in bloating the chain
18:12:32 <tx_extra[m]> (more than i already did)
19:07:29 <plowsof> please keep the on-chain chat inside TownForge!
19:08:30 <plowsof> also, kicking tx_extra will achieve nothing https://libera.monerologs.net/monero-research-lab/20220729
19:18:35 <tx_extra[m]> <plowsof> "also, kicking tx_extra will..." <- i will not continue
19:18:43 <tx_extra[m]> sorry for going overboard with this
19:18:53 <tx_extra[m]> my intention was to get a dialogue going about limiting the degree to which tx_extra can be abused
20:12:14 <BusyBoredom[m]> tx_extra: how would you feel about the idea of making it prunable? That fixes the bloat issue in my eyes, and IMO the tx uniformity issue is not the end of the world because I think people understand attaching arbitrary data to their tx makes it stand out. 
20:21:55 <liamswenson[m]> Can the utility of tx_extra not be provided by off-chain solutions? seems like its just a very niche convenience at the cost of bloat, reduced uniformity, and potentially permanent storage of illicit material on any computer that runs a node.
20:23:54 <liamswenson[m]> I am probably missing something or else I don't see why it would've been added in the first place.
20:25:08 <tevador> the tx fee seems ridiculously low here, 64 cents per 1 MB of bloat: https://xmrchain.net/tx/84f4e9d0cdec1946c9b1a091d4e1c24ed3318d4b07dfbe6d753d5fabb2c87715
20:25:45 <xmrack[m]> BusyBoredom:  I would push back on the privacy implications of non-uniformity. People understood in the early days of Monero that reducing your own ring size would hurt privacy, but Moser et al. found that 64% of transactions still chose to use zero mixins. Non-uniformity hurts everyone.
20:32:01 <Rucknium[m]> xmrack: Agree. There are probably at least a dozen papers so far that conclude on empirical or theoretical grounds that the ring signature privacy model requires tx uniformity for best performance. Careless privacy practices by User A can impact the privacy of unrelated User B.