it's a pretty naive attack when the alternate, sending two tx with outputs to the same address just a few hours apart, is just as effective but harder to detect

I wonder if some implementations are not using the dummy output correctly when churning. Either sending two outputs to oneself with nonzero amounts, or spending the 0 amount input by accident.

Or it could be people splitting up their balance to facilitate avoiding the 10block spendable age.

koe: I'm thinking of the case where A needs to make a payment to B of X. Sending separate txs would be very odd and perhaps not even processed correctly, but sending 1 TX with multiple outputs adding up to X is just a pure privacy attack

yes, sending to oneself with splitting is a possible self-attack if the end up recombined. Ideally if such a split is needed, one should not split so much as to require recombining, at least frequently

maybe split to a variety of sizes

ah would the typical wallet not make it known to the user if they own multiple outputs from a tx?

e.g. would just be summed into one 'received X'

i wonder what the ring size is where the probability of having two outputs from the same transaction is expected. though, probably doesn't cover the case when its 10 outputs.

Depends what API you use. With the low level output API, you get one record per output. With the higher level one, you get a sum.

We could also change the fake out selection to reuse the same (or close) selection for all rings.

Maybe reuse half of it, sliding across rings.

Reuse the tx pick, so if one ring uses the first output from tx 1, the next ring uses the second output.

Then you'll get a lot of spurious output linking.

And hopefully it doesn't break anything else. We'd have to defer to the clever fellas in MRL.

Are you referring to a form of output binning?

Where time-adjacent outputs (in blocks) are selected in chunks?

I suppose it's related. To rephrase:

Alice sends a tx with two inputs, thus two rings. She picks random fake outs for her first ring. For the second ring, she picks a random half (or whatever we deem appropriate) of the fake outs she selected for the first thing, and uses the "other" output for them for the second ring. For the other half of the ring, she picks new random fake outs.

That is, if she picks output O0 in her first ring, and O0 was created in tx A, which created both O0 and O1, she'll use O1 in her second ring.

I don't think it even skews the age distribution.

It would skew the age distribution, but there is still benefit

The "true binning" approach would be to do age-distribution selection and then choose all outputs from bins located there... which I suppose could be defined by the outputs' "siblings"

kinda sounds like whackamole with the output distribution problem. ringsize 100k ftw!

I don't think it does, if the part of another ring to reuse is taken equiprobably.

Since the original distribution is "right".

you don't necessarily want to obsess over reuse to the point where it weakens every ring. some reuse both good and fake is good, but too much is always an exploitable bias.

anyway, this says little or nothign about the method, just that it requires getting the numbers right

Hi folks.

I've received some messages requesting clarification.

To clarify, to whomever is interested in the stuff I've talked about for a while now (regarding Sekreta/Kovri);

the Sekreta codebase/library that Monero PR #6276 pulls from (and uses) is located at gitlab.com/sekreta/sekreta (as seen in Monero cmake/Sekreta.cmake.in)

The CI pipeline is located at gitlab.com/sekreta/sekreta/pipelines , Codecov is at codecov.io/gl/sekreta/sekreta , and Coverity is at scan.coverity.com/projects/20175

and Sekreta's respective dependencies (including Kovri) are within the Sekreta cmake/ directory (any others are noted in README.md).

Again, no submodules this time; just modern CMake (but it's the same concept of downloading/pulling-in rather than polluting a superproject's tree).

Thank you for your time.

Meeting in #monero-research-lab happening now

Question, so i compiled the monero codebase with the changes I want. I am currently running the daemon and syncing. How do I get it to where it uses the new codebase that i compiled to sync? If that makes sense

I can see two questions that are close enough to what you said:

- how do I get it to use my code ? -> if you compiled it and are running it, it's using your code

did u make some consensus changes and your hoping to see when they happen?

- how do I get my changes to sync ? -> if it's failing to sync with your changes, we have no idea what bug you might have made, so can't comment on specifics

If it's failing to sync, log level 2 will likely get some info as to why.

@gingeropolous, yup thats right

its syncing now so it should be good now. just waiting on it

oh okay, cool. Thanks moo

So it's syncing. Are you saying it's syncing fine, but not using your code, even though you built with your changes ?

i am just wondering if it is using my code. I downloaded the monero codebase and made the changes. Then i compiled it yesterday. Today, I am syncing the daemon.

I typically add a MGINFO("trace"); and look at the output.

sorry if it feels like we are going in circles, still getting the hang of monero