-
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
-
chesterfield[m]
<M0x1zxq7896lp2ze> "which one is most hard to..." <- might interest you -
monero-project/monero #7078
-
M0x1zxq7896lp2ze
i saw that
-
M0x1zxq7896lp2ze
their was video in monero talk too
-
tmoravec[m]
Hi, how do I enable BP+? For context, I'm testing the multisig fixes (PR 8149) which require BP+. Thanks!
-
UkoeHB
tmoravec[m]: you could run it on the current testnet
-
tmoravec[m]
UkoeHB: Just running the same binary on testnet instead of stagenet will do?
-
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?
-
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?
-
UkoeHB
tmoravec[m]: yes and yes
-
tmoravec[m]
All righty. Thank you very much!
-
sgp_[m]
is there a reason why fee/weight isn't printed in `print_pool_stats`
-
sgp_[m]
`weight` is used to calculate the fee right? Or am I misunderstanding
-
sgp_[m]
I think I'm misunderstanding, looking more
-
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?
-
moneromooo
It probably wasn't interesting to know. It's esaily available.
-
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.
-
UkoeHB
moneromooo: what is the wallet2 policy if a reorg hypothetically went past a checkpoint? throw an exception?
-
moneromooo
It does not care I think. It's the daemon's side. Not 100% sure though.
-
moneromooo
In practice though, if your reorg hits a checkpoint, it'll hit the default max-reorg first.
-
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.
-
moneromooo
As I said, I'm not 100% sure. Try git grep.
-
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 :/
-
UkoeHB
yeah good point lol
-
hyc
what is a checkpoint, in the context of the wallet?
-
moneromooo
I assumed the same as the daemon for the purposes of my reply.
-
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).
-
hyc
for the daemon I assumed it meant the hardcoded hashes in the daemon binary
-
moneromooo
Oh, no. Checkpoints are in src/checkpoints/checkpoints.cpp, very sparse.
-
hyc
do we have a max reorg depth? and the daemon rejects any reorgs deeper than that?
-
hyc
ah ok
-
moneromooo
The wallet does. The daemon does not.
-
moneromooo
I think someone added that to the wallet as a sanity check for asshole daemons.
-
hyc
would think a limit in the daemon would be a good deterrent against selfish mining, 51% attacks
-
UkoeHB
could that cause a netsplit?
-
hyc
I don't see how. legit reorgs are only 2-3 blocks deep
-
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
-
UkoeHB
I mean a netsplit between nodes that do/don't impose a reorg limit (tbh my understanding of node implementations is very shallow).
-
hyc
sure it's a consensus level change, you'd only roll it out during a hardfork
-
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.
-
hyc
oh? it was tried in monero, or in some other chain?
-
moneromooo
Like, if a country gets dropped from the internet for enough time.
-
moneromooo
Some other chain. Usually as a short term defence against 51% attacks.
-
moneromooo
And it works. It makes attacks harder. But the attacks, when the succeed, have more impact, because you *stay* on the bad chain.
-
hyc
hmm
-
moneromooo
"bad" being the one with least cumulative work.
-
hyc
well, the attack succeeded because it had more work, didn't it? so it would be quite hard to get off that chain
-
sech1
if there is a limit for reorgs, a carefully executed 51% attack (for the exact number of blocks) will cause the netsplit
-
sech1
not just "country blacking out"
-
moneromooo
Yes, it's an attempt to prevent "hidden mining chains" from winning.
-
moneromooo
But it'll fuck over large amounts of the network being "offline" for a while.
-
sech1
they can win on half the nodes if broadcasted at the right moment
-
moneromooo
Though if that part has little hash rate, it might end up ok. Depends on hte details really.
-
moneromooo
Yes, if you can time stuff well, it would, true.
-
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
-
moneromooo
Yes, but it recovers automatically at least. With a reorg max depth, it doesn't.
-
hyc
yeah ok