selsta shared my opinion and reasoning on the best path forward for 7798, and opened an additional issue that shows that extremely recent spents are likely identifiable in rings: monero-project/monero #7807

yes, thanks for the writeup

I'm fine with only fixing the divide by zero

Thanks for bridging, I would have missed

Is there a good reason not to just roll out both changes at once

It's not like selection is enforced by consensus anyway

There are a couple reasons:

1. Not 100% certain yet on the exact correct fix for 7807, and 7798 makes sense to patch ASAP because of the divide by 0 bug.

2. All wallets that delay in updating would be using a different algorithm, which would then cause 2 puddles of rings to form and potentially introduce privacy implications as a result of breaking tx uniformity.

I see not moving forward with a fix as a worse privacy choice, but I understand patching divide by zero asap

I agree, once the fix for 7807 is known it should also probably be applied ASAP in terms of benefit and cost to privacy (the risk of potentially breaking tx uniformity in a small number of cases is *probably* vastly outweighed by continuing to compromise real outputs in some known cases). And considering tx uniformity would already be altered from

a change to 7807, it probably makes more sense to go ahead with the fix in 7798 as well

maybe we slap a ringsize bump on it for good measure

gingeropolous: that will require a hardfork. That's not explicitly required for the other changes

sgp_: lol. is blockfolio alerts the new monero mailing list?

jberman: I definitely appreciate your concern for uniformity, but that's something we need to fix later when there's a common spend condition whereby users accidentally reveal the real wallet spends

M5M400: I put out notices where I can; I can't send emails to the main distro haha

So this is what y'all get :p

fair enough :) thx in any case

Good to know those notifications work

sgp_ ya I'm agreeing with you, 7807 should probably be patched ASAP once the correct fix is known regardless of its impact on tx uniformity

All things considered, we've been pretty nonchalant (relatively) at enforcing ring sig selection anyway as I'm sure you're aware

I know for certain pushing the algorithm out 1 block would alleviate the issue immediately, it would just take more time digging into the paper's numbers to be certain that is the correct thing to do

Not that it's necessarily a good thing haha, but still, we're not losing much

Or rather, assuming the gamma distribution starts 120 seconds earlier

It seems I'm not getting everything via Matrix either. If anybody has a task for me or sth. similar, please message directly.

yeah i know its not required for the other changes, but a hardfork is one way to ensure tx uniformity

although i guess folks could mod their wallets to bump ringsize but not the other things

Hi all👋

We are hitting 120 tx a block, how does the bug affect privacy now ?

Its 120 outputs per block that is the threshold and it's a trailing avg of the last year -- we're still well below that.

imgur.com/a/I1bOnsv - yellow: vout >=120, green: vout < 120

(no, each point doesn't mean "one block", but rather "one time the collector look at `monerod` and saw the last block)

<sethsimmons "Its 120 outputs per block that i"> 👍

(whoops, yellow is <= 120)

Is the bug just on the wallet?

Excuse my ignorance?

* Is the bug just on the wallet?

Excuse my ignorance

Yes, just the wallet.

Is there a wallet with a different implementation, or coin control at all?

Not sure if coin control is a thing that can be done in monero

that's better for #monero as it isn't dev related (CLI and Feather have coin control)

Yes, monero-wallet-cli can freeze/thaw outputs, and Feather wallet can do the same.

But if you're spending >1h after receiving funds you're fine.

No need to coin control everything because of this bug.

Yes, not worried :) my spending habits not affected

How do you do that on the GUI or should be it CLi?

I don't think the "official" GUI has coin control -- have to use the CLI or Feather wallet (which is a GUI wallet, and my favorite wallet to use, #_oftc_#feather:matrix.org )

odd

Website is featherwallet.org

.merges

#_oftc_#feather:matrix.org

#feather:matrix.org

<MonerolionX[m] "#_oftc_#feather:matrix.org"> Clicking this worked

utxobr[m]: which Ubuntu version? Which cmake version?

utxobr: which Ubuntu version? Which cmake version?

slstmd: `cmake version 3.16.3` `DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"`

Did you tree a fully clean build?

try*

yeah I thought I might've had something weird under `build`, so got rid of everything and started from a fresh clone (did fetch the submodules etc)

is it all good over there? if so, I can try double checking the dependencies I have here

(I noticed github actions didn't finish yet - no worker picked the builds up still - so not sure if a regression/not)

It's this PR, it passed all CI including Ubuntu 20.04 so I'm confused why it fails on your system.

hi

It's possible that Github actions deactivated our account for whatever reason.

interesting, no worries, that's helpful already, thanks slstmd

hi atoc_ :p

hi man

utxobr: will take a look at your issue

Did you just do "make" or did you use custom cmake paths?

slstmd: oh thanks! no, just plain `cmake ..` from a build dir followed by a `make -j12`

I wonder if the concurrency there messes it up

utxobr: can you try this paste.debian.net/hidden/f70b726b ?

sure

utxobr: next try paste.debian.net/hidden/21425af9

slstmd: a-ha. that seems to have done it - past that target already

sweet, that did it slstmd 👍️

thank you!

utxobr: thanks, could you please also check if the patch in monero-project/monero #7813 works and then approve it if you have a github account?

rebuilt fresh from your fork's branch, works great! i'd need to ping luigi to get the permissions there first, but lgtm

luigi1111: github.com/cirocosta in case you're around

.merge+ 7813 7814 7815

Added

utxobr: github actions works again for newer PRs, probably a bug?