seems both people just had things misconfigured

Inge permaban, yeah. I haven't even logged back in there since

but nice to see more folks using LMDB's encryption support

<j​effro256:monero.social> @Inge genuinely asking: what kind of value does LMDB encryption bring to the usecase of storing a public blockchain? Anyone who gets physical access to your computer can probably tell that you are running a Monero node based on the LMDB file type and the sizeof the file, plus the `monerod` executable sitting around. If you enabled full disk encryption on the drive that you do all <clipped message>

<j​effro256:monero.social> your monero stuff, that might actually hide your activity at rest. Also, in terms of tamper resistance, Monero already has that by virtue of being on a blockchain. If you have the top block hash, you can validate every single byte of on-chain data

<j​effro256:monero.social> Oh I might have misinterpreted "daemon" in this tweet as a monero daemon

he's not talking about a monero daemon. and encryption was added to LMDB to be used by a monero wallet.

the work to migrate the wallet to LMDB has never been done thouh

<s​trawberry:monero.social> someone asked this earlier but is randomx v2 still planned, and what exactly will it change?

whenever the next monero hardfork is scheduled,

it will make verification faster

<s​trawberry:monero.social> is it not also meant to disadvantage the X5?

that's a side effect, not a main goal

<s​trawberry:monero.social> is it a full rewrite or mainly a change of parameters?

parameter change (perhaps) + outer hash for quick verification (merged and exposed in API, not used in Monero atm)

<j​effro256:monero.social> @hyc I think I'm of the opinion that it should be forked in before or after the FCMP+SA+L consensus update, but not with it

<j​effro256:monero.social> There's too much already changing with that update IMO to also change the block structure

<j​effro256:monero.social> Especially since it is a completely orthogonal change

<s​trawberry:monero.social> don't we want to do big changes all at once?

<j​effro256:monero.social> Not necessarily since big changes can come with big issues that need to be resolved, and multiple big changes can have big issues which compound one another

<j​effro256:monero.social> Making big changes all at once makes sense when batching them together causes less work / less thrashing in the long run

<j​effro256:monero.social> Don't think this would be the case for FCMP+SA+L in addition to RandomXv2

<j​effro256:monero.social> Besides the fact that people would have to update their nodes twice

<s​trawberry:monero.social> we shouldn't be doing forks that come with big issues that need to be resolved anyway

<j​effro256:monero.social> easier said than done. if I could see into the future and know which bugs would arise in my code, I would simply fix them before they became a problem. unfortunately I am not psychic

Hey, that's what testnet is for, right? Right?

<s​trawberry:monero.social> that's what I was thinking, but testnets have less usage and no economic incentives

<s​trawberry:monero.social> although that's what wownero is for, right?

<s​trawberry:monero.social> about wownero, is there anything monero can do to incentivize solo/p2p mining?

<s​trawberry:monero.social> the way wownero bans pools seems to necessarily break p2p pools too, so if applied to monero the hashrate would collapse

<s​trawberry:monero.social> but we don't need to outright ban centralized pools, only make them less profitable than p2pool

<s​trawberry:monero.social> actually isn't it already the case that p2pool is more profitable? the real question is why most miners still don't use it