02:55:38 <M0x1zxq7896lp2ze> which one is most hard to implement in monero protocol full zero knowledge proof system to shield not only amount but everything else too or implementing strong p2p level network default privacy like noise protocol and others that make even ISP level threat model harder to detect monero SPV nodes
04:25:35 <chesterfield[m]> <M0x1zxq7896lp2ze> "which one is most hard to..." <- might interest you - https://github.com/monero-project/monero/issues/7078
08:05:12 <M0x1zxq7896lp2ze> i saw that
08:05:41 <M0x1zxq7896lp2ze> their was video in monero talk too
14:06:27 <tmoravec[m]> Hi, how do I enable BP+? For context, I'm testing the multisig fixes (PR 8149) which require BP+. Thanks!
14:09:11 <UkoeHB> tmoravec[m]: you could run it on the current testnet
14:09:54 <tmoravec[m]> UkoeHB: Just running the same binary on testnet instead of stagenet will do?
14:11:55 <tmoravec[m]> Does that also mean that it's not possible to run code from branch UkoeHB:multisig_signfixes on mainnet before the fork in July?
14:12:43 <tmoravec[m]>  * Does that also mean that it's not possible to run wallet with code from branch UkoeHB:multisig_signfixes on mainnet before the fork in July?
14:16:54 <UkoeHB> tmoravec[m]: yes and yes
14:17:14 <tmoravec[m]> All righty. Thank you very much!
15:10:09 <sgp_[m]> is there a reason why fee/weight isn't printed in `print_pool_stats`
15:11:29 <sgp_[m]> `weight` is used to calculate the fee right? Or am I misunderstanding
15:25:08 <sgp_[m]> I think I'm misunderstanding, looking more
15:26:02 <sgp_[m]> the goal is basically some Auto-like mode for priority selection, but one that targets inclusion in the next block. What would be the simplest ways to achieve this currently?
15:51:49 <moneromooo> It probably wasn't interesting to know. It's esaily available.
15:52:50 <moneromooo> Easiest way is probably... get all txpool txes, sort by fee/byte, accumulate from the best till you reach the current block size, do it again, discard the first set.
16:12:12 <UkoeHB> moneromooo: what is the wallet2 policy if a reorg hypothetically went past a checkpoint? throw an exception?
16:13:24 <moneromooo> It does not care I think. It's the daemon's side. Not 100% sure though.
16:16:36 <moneromooo> In practice though, if your reorg hits a checkpoint, it'll hit the default max-reorg first.
16:16:44 <UkoeHB> Does wallet2 care about checkpoints at all? I'm trying to decide the best way to handle reorgs in the context of output scanning (for seraphis). The simplest way is just trust whatever block height/id pairs are sent in to the scanner, then roll back as far as the restore height if new pairs sent in look like a reorg.
16:17:02 <moneromooo> As I said, I'm not 100% sure. Try git grep.
16:17:52 <moneromooo> It should be fine to not care if people did not stick their wallets into any random daemon they find lying in the internet gutter :/
16:18:37 <UkoeHB> yeah good point lol
16:31:36 <hyc> what is a checkpoint, in the context of the wallet?
16:32:51 <moneromooo> I assumed the same as the daemon for the purposes of my reply.
16:48:53 <UkoeHB> Yeah sorry, was wondering what an output/enote scanner can do if it gets 'outputs-to-be-scanned' from blocks that don't match with checkpoints. However, the scanner should just trust the output set source, and the output set source should be responsible for handling trusted/untrusted chain data (e.g. wallet2 vs daemon).
16:58:47 <hyc> for the daemon I assumed it meant the hardcoded hashes in the daemon binary
16:59:24 <moneromooo> Oh, no. Checkpoints are in src/checkpoints/checkpoints.cpp, very sparse.
16:59:35 <hyc> do we have a max reorg depth? and the daemon rejects any reorgs deeper than that?
16:59:42 <hyc> ah ok
16:59:44 <moneromooo> The wallet does. The daemon does not.
17:00:26 <moneromooo> I think someone added that to the wallet as a sanity check for asshole daemons.
17:01:58 <hyc> would think a limit in the daemon would be a good deterrent against selfish mining, 51% attacks
17:02:37 <UkoeHB> could that cause a netsplit?
17:03:26 <hyc> I don't see how. legit reorgs are only 2-3 blocks deep
17:03:48 <hyc> if you've been mining on the wrong chain for 10-20 blocks, you already had a netsplit and just didn't notice yet
17:06:54 <UkoeHB> I mean a netsplit between nodes that do/don't impose a reorg limit (tbh my understanding of node implementations is very shallow).
17:08:04 <hyc> sure it's a consensus level change, you'd only roll it out during a hardfork
17:12:46 <moneromooo> A limit in the daemon would cause a fork yes. It's been tried before as a stopgap. It is thought to work very well, until it doesn't, and then it's worse than the cure.
17:13:27 <hyc> oh? it was tried in monero, or in some other chain?
17:13:29 <moneromooo> Like, if a country gets dropped from the internet for enough time.
17:13:53 <moneromooo> Some other chain. Usually as a short term defence against 51% attacks.
17:14:20 <moneromooo> And it works. It makes attacks harder. But the attacks, when the succeed, have more impact, because you *stay* on the bad chain.
17:14:42 <hyc> hmm
17:14:47 <moneromooo> "bad" being the one with least cumulative work.
17:15:07 <hyc> well, the attack succeeded because it had more work, didn't it? so it would be quite hard to get off that chain
17:15:36 <sech1> if there is a limit for reorgs, a carefully executed 51% attack (for the exact number of blocks) will cause the netsplit
17:15:48 <sech1> not just "country blacking out"
17:16:08 <moneromooo> Yes, it's an attempt to prevent "hidden mining chains" from winning.
17:16:25 <moneromooo> But it'll fuck over large amounts of the network being "offline" for a while.
17:16:35 <sech1> they can win on half the nodes if broadcasted at the right moment
17:16:41 <moneromooo> Though if that part has little hash rate, it might end up ok. Depends on hte details really.
17:17:14 <moneromooo> Yes, if you can time stuff well, it would, true.
17:18:31 <hyc> an isolated segment of the network is hosed regardless. if/when it gets connectivity back it still loses out on anything it mined while isolated
17:18:59 <moneromooo> Yes, but it recovers automatically at least. With a reorg max depth, it doesn't.
17:19:06 <hyc> yeah ok