In Monero's current state, assuming OPSEAD is not implemented, when probablistically de-anonymizing a transaction, is information that is gathered pertaining to the amounts and the wallets involved, or just the amounts?

Thanks for your time as well. Sure you're being overloaded with tons of questions/criticisms/praise

s/Thanks for your time as well. Sure you're being overloaded with tons of questions/criticisms/praise/Thanks for your time as well. I'm sure you're being overloaded with tons of questions/criticisms/praise/

entry1[m]: You can say that again lol

<entry1[m]> "In Monero's current state..." <- Just traceability. So, the "true spend" might be able to be identified. In other words, the mixins may be able to be distinguished from the true output that the user actually spends. So nothing involving the amounts, unless of course an exchange has information about how much you withdrew and is able to trace your transaction further along. Does that clarify things?

<Rucknium[m]> "Just traceability. So, the "true..." <- Interesting, thanks for the clarification. Not to get in the weeds of course, but would this theoretically apply to each instance on the block explorer when analyzing individual transactions? I remember this instance from fluffypony

Unsure if you saw this thread and if OPSEAD wasn't implemented, that this instance would be more probabilistically traceable

It wouldn't be deterministic.

Gotcha, just able to eliminate more of the mixins? selsta

you could say with e.g. 40% certainty it's this output being spent

(making up a number)

Great, thank you both.

at least I'm quite sure that's how it would work as it's a statistical attack, not broken cryptography

The attack is definitely probabilistic. I refer to it as a "statistical attack".

I know that you are all concerned. I feel that. We are working as fast as we can.

So these are the capabilities Ciphertrace alleges to have currently. Would be interesting to know if they are aware of this proposed implementation or if they are using other "methods."

I'd recommend watching breaking monero series on youtube (im not the only one waiting for new episodes!)

Oh I'm good, I'm just reading up! I've seen those plowsof and will probably rewatch because there's always portions you pick up again watching it lol. For sure

My favourite is the one on remote nodes

There will be an ep. on OSPEAD when its all said and done i bet

s/OPSEAD/OSPEAD/

Lol I joked with someone recently that I might end up writing a chapter for Zero to Monero before I even finish reading it.

please use different 4 times in a sentence

I imagine that different txs have different probabilities as different txs have different circumstances

using that mixin word again I see :)

**different probabilities of narrowing down the true spend

nioc: Yes, that's the basis for my comment above:

>I can also imagine a scenario in which the full mechanics of OSPEAD are not released, but the devs, MRL, Core, etc develop an advisory about past transactions in which it is clarified what types of txs may be vulnerable to attack, ex post

Sound warning for headphone users^

is there a reason why Sarang Noether was not asked if he would like to work on seraphis/other protocols for monero?

was the halo2 protocol from zcash ever considered for monero?

atomfried[m]: Tentatively, I think we should take a serious look at it. In fact, I basically suggest as much in my Vulnerability Response Process submission. With ring signatures, Monero's "statistical attack surface" is kind of huge.

<atomfried[m]> "is there a reason why Sarang..." <- Doesn’t he work for cypher stack ? we should ask diego if they have time 😅

nikg83[m]: yeah why not 👍️

That's not to say that the issues with statistical attacks cannot be fixed -- I think they can be mitigate to a significant degree -- but we really have to build up our capability for checking the "surface" for weaknesses and fixing any that we find. That might be a lot more work, and a lot riskier, than just implementing Halo2 or something.

afaik halo2 isn't a complete transaction protocol

And much of the detail needed to build out an instantiation of it is hidden for 1y after release.

Due to some dumb license they've placed on it.

AFAIK there would be no way to even explore using it clearly until 1y+ after their own release of it, and many details are not public now.

I can see it being something to consider after Seraphis / Lelantus Spark

but in the short term, no

selsta: Yup.

sethsimmons: that realy sucks

selsta: i agree with that now that i know the license bullshit :D

I think Zcash itself didn't even figure out halo2 with recursion yet

and they fund the researchers on it

before they got it ready its not something we can consider

selsta: Do you think in any future scenario it may be seriously considered for implementation in production? I continue to worry about the ring signature model. In the meantime, of course, we can work to shore up the ring sig shortcomings and explore the theoretical limits of ring sig obfuscation, w.r.t. statistical attack.

I think it's extremely unlikely short term, long term no idea, if it's possible to adopt in a way that doesn't harm UX, why not.

Zcash, with tens of millions in funding barely has things like mobile wallet / hardware wallet support for shielded transactions.

<selsta> "I can see it being something..." <- So somewhere around 2024

There is a reason they haven't switched to shielded only.

decoy-based approaches are always going to be largely inferior to accumulator-based ones. My personal opinion is Monero, once trustlessness and security can be assured, should look into accumulator-based options for the privacy protocol in the long term.

selsta: a lot of that reason is for things like getting listed on Coinbase and other exchanges and not being willing to give up the liquidity and notoriety that comes from that.

that doesn't explain why the shielded transaction ecosystem is so bad, like mobile wallets

It's not all technical. There's a lot of ecosystem reasons why they haven't switched (misplaced imo obviously)

DiegoSalazar[m]: but sure, a large part of it is business reasons

DiegoSalazar[m]: do you know why Firo doesn't use a Zcash like system?

"once trustlessness and security can be assured" <-- is that not fully the case yet?

Diego Salazar: What does "accumulator-based" mean?

they were originally ZeroCoin on the ZeroCoin protocol, no? Or Zcoin, whatever it was originally called

it was a purposeful decision to use ZeroCoin over ZeroCash

ended up being a bad decision, but totally different team then

selsta: Fully shielded might be catastrophic if another mint-what-you-want bug is discovered in Zcash. AFAIK their plan, as in the past, to deal with it is to implement turnstiles just in case. This is probably another reason that they don't go fully shielded.

selsta: Firo is kind of a pseudo-accumulator system.

I mean Lelantus Spark, which seems similar to Triptych / Seraphis

Rucknium[m]: Zcash uses an accumulator, or basically one big pot for all of their privacy stuff to fall into. It makes one massive (theoretically) crowd to hide in

I see. accumulator = shielded pool.

selsta: Yes, but this is an underlying proving system, not a complete privacy protocol.

Firo puts transactions into "buckets" of 30k other transactions each and then makes a new bucket once that one is full, the subsequent bucket seeded by other transactions in the preceeding bucket

Whereas Monero, if implementing something like Spark, would use this proving system to increase mixin count.

The differences are subtle, but present, and extend beyond "ringsize 30k" for Firo.

Firo sits in this in-between between decoy-based and accumulator-based.

I guess the biggest difference, if I was to put a finger on it, is that, as it sounds, accumulator-based systems constantly accumulate more and more, whereas Monero's decoy selection is static, predetermined, and unchangeable once selected.

The dynamic nature of an accumulator-based approach, when used correctly and by-default, can throw a few wrenches in some heuristic analyses.

This is the prevailing theory, anyways, and it's ill-defined what is "correct" or "good enough" usage, similar to Monero's "good enough" problems with churning or ways to circumvent an EAE attack

> Monero's "good enough" problems with churning or ways to circumvent an EAE attack

Do you have more information about this, please? 1/11 plausible deniability isn't enough for me (in case of colluding senders/recipients) so I churn single inputs a few times (over some hours/days) before spending. My hope is that each churn decreases the probability to 1/11^x but I don't know if this is true either theoretically or in practice.

anarkiocrypto: Churning is emerging as a research priority for MRL. It's unclear who could actually do the research, but there is increasing recognition that the research should be done.

Thanks Rucknium, very happy to hear this. :)

anarkiocrypto: If you can do something to drum up support for it, like secure some funding for it, for instance, I think that would be useful.

Sadly I earn less than $400/month and need to pay for food and rent... also don't have any connections or network and only a few people read my posts in Twitter and Noise.cash.

I can only recommend another CCS specifically for churning, or a bounty (bounties.monero.social) or use Plowsof's wishlist software (github.com/plowsof/xmr-wishlist-aaS).

People are starting to become curious about my origin story. I've sort of typed it up here:

Rucknium don't bother yourself with internet trolls

^this, reddit is full of bullshit

sech1: How is my CCS going to get funded if I don't put these concerns to rest? It's community-funded. I have to engage with the community, after all.

I've seen multiple time that CCS gets funded with 1-2 huge donations and usually quite quickly

people who do them ("whales") are, I think, better informed

it's better to concentrate on actual work, we have plenty of active redditors to engage :)

Reddit basically exists to waste your time.

I hope something like that happens with my CCS. I don't feel like I can risk it, though. My suggestion to conceal the full mechanics of OSPEAD (which I am open to giving up on, BTW) has generated a huge amount of controversy.

Hmm maybe. I found it interesting, though, to go back to those IRC/Matrix logs and see just how prophetic they were.

"Interested parties" will figure out the mechanics anyway, sooner or later. That doesn't mean we should spoon feed it to them :D

or maybe they already have

sech1: Precisely. They will catch up eventually. Maybe we don't need to give them a head start; not sure.

Rucknium: would you say the exploit is obvious to someone with a cursory understanding of Monero transaction mechanics and a background in statistics

ajs_: What is "obvious" I think is that the current mixin selection algorithm leaks statistical information.....

The exact form of that leakage, and how to exploit it, are not at all obvious, however.

It required many flashes of insight on my part -- as isthmus said, a "fundamental breakthrough".

What we should worry about is a Rucknium doppelgänger, so to speak, working for the other side.

<Rucknium[m]> What we should worry about is a Rucknium doppelgänger, so to speak, working for the other side.

hah. right on.

<ct[m]> "no doubt. But odysee is usable..." <- Is the odysee front-end open source?

<t-900-a> "Is the odysee front-end open..." <- Yes-ish, they plan to make odysee downloadable which are open sauce