<razor[m]> "image.png" <- Is this related to Monero development in some way?

<alex[m]123456727> "Credit cards, for example..." <- I agree with that 100%

mj-xmr[m]: actually, Rpi4 comes with a 64bit OS. it's the first time raspberry has supported that

which is why #7953 is about rpi4.

Yeah yeah. it's all clear now.

hyc my rpi3 runs 64-bit os too. I had to install it manually though

right

as I said - rpi4 i the 1st time raspberry supported it. 3rd party was available before

sech1: I didn't know that the 64-bit os was available for RPi3 as well. Too bad, because it does give some kick.

armbian distro is pretty easy to install

I tried to DM luigi about CCS, but Matrix is now telling me "User is not online or does not exist. Message not sent.", so I'll ask here:

I submitted a merge request for a new Idea, and it actually shows up in the Ideas section. However, the text doesn't show up like with other proposals:

Does anyone have any guidance on why this may be happening?

<Rucknium[m]> "Does anyone have any guidance on..." <- When I compare repo.getmonero.org/monero-project/c…roposals/-/merge_requests/255/diffs with repo.getmonero.org/monero-project/c…roposals/-/merge_requests/252/diffs , there are some formatting differences. This is all I can tell.

it probably won't display properly because you called them mixins

"it would likely be wise to conceal the mechanics of OSPEAD indefinitely." >>> isn't it likely that an adversary could find a statistician like yourself that could uncover the same thing? I guess thats moot really. The same could be said of an exploit i guess.

> I submitted a merge request for a new Idea, and it actually shows up in the Ideas section. However, the text doesn't show up like with other proposals:

> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/255

Can you also include stats on single input churns (sweep_single), please? (I can't afford to donate, can barely afford food/rent, but if you need any web dev help, I can offer that in return.) Churns are important for many real life use cases, where 1/11 plausible deniability isn't enough to stay safe.

> <@anarkiocrypto:halogen.city> > I submitted a merge request for a new Idea, and it actually shows up in the Ideas section. However, the text doesn't show up like with other proposals:... (full message at libera.ems.host/_matrix/media/r0/do…7f263b6c71679170723322efb28571ac878)

I have no idea what it's about.

Do you mean Rucknium's proposal or churns?

I think Rucknium wants to statistically research decoy selection algorithm and then improve it, so that plausible deniability is better (i.e. the 10 decoys are more realistic and it is difficult for an observer to guess which is the real spend).

Rucknium[m]: Don't you just have to paste it into the issue message?

Thanks. And what about the churns? A link would also be fine.

I churn for safety reasons since 1/11 plausible deniability isn't enough for me.... (full message at libera.ems.host/_matrix/media/r0/do…79652f27d8b2016dd7cf531d07b9c172ef2)

s/increases/decreases/, s///, s///

<gingeropolous> ""it would likely be wise to..." <- Yes. Like I stated, the fuse is lit. I think is is possible that the only benefit of revealing OSPEAD publicly is that other CryptoNote blockchains would be able to benefit from it, since they face the same mixin selection problem if I understand correctly.

anarkiocrypto: I agree that churning is an important object of study, but I want this CCS proposal to remain focused. I (and others) could possibly examine it in a future research effort.

Surely churning is related to decoy selection? But I understand if not.

anarkiocrypto: Yes it is related, but my proposal has a very specific & narrow goal in mind.

Perhaps churning should take into consideration how many times your outputs have been used as decoys in other transactions as well? (Not sure if it's actually a useful parameter, just throwing the idea out there)

endor00: There has been some recently-published research that, I believe, examines questions like this.

This is behind a paywall, but available for free via "other means"

It's a tough read, for me at least. So groking it is on the backburner

moneromooo: Can I share my HackerOne submission with sgp_ through end-to-end encrypted means?

sgp_: Maybe it would be good to give your rationale for seeing it. I'm not sure a rationale is necessarily needed, though

I've done a lot of work on ring signature research in the past and hope that I can provide a quality review

sgp_: That would be awesome. As I stated in my CCS proposal, I am pulling together a scientific review panel for the execution of the (sketch of) the plan that is in the HackerOne submission, and I think you would be a good person to be on the panel if you have the time and inclination to serve.

Rucknium[m] I have a question about your HakerOne submission. How sensitive it this to a change in ringsize from 11 to 21 vs say 16 or 25

Ultimately it's your research, but "because I want to assess it" doesn't strike me as a good reason or everyone interested will see it. I'm not asking you not to though.

If this is for this channel I can provide a pgp email

if this is too sensitive

moneromooo: I see. I also feel like it may be wise to restrict access to only those who may actively work to improve what I'm doing. That so far includes jberman, isthmus, and another applied statistician in the Monero community.

Feel free to ask some core team members for a second opinion though. I may have a bias.

moneromooo: I intend to share something of a somewhat -- but not deeply -- sensitive nature with ArticMine . I assume that's OK, his being a Core member after all. Let me PM you, I think...

(Request was approved)

ArticMine: Yes, please provide an end-to-end encrypted means of communication. I have a Protonmail account, if that makes it easy.

FWIW I do not wish be the decider of who gets to see what. I can only give my opinion.

Pm you proton mail

me

moneromooo: Ok. I feel like I need to ask for second opinions since this vulnerability work is all new to me, however. Much of this feels "above my paygrade"

Sure.

My view is that there are strong nuggets in Rucknium 's paper to understanding and improving the algorithm, and I would rather the knowledge on it (and on solutions) be shared/opened up for everyone to be aware and make their own conclusions/draw ideas from it/scrutinize on their own as well

Case in point, the work presented was developed after seeing some of the thoughts/work I shared publicly on the algorithm, and so it stands to reason that making the work public is likely to invite even more qualified eyes and scrutiny

I also think it's better people are aware of the risks they face (and what they may have been exposed to) while using Monero today and in the past

FWIW I also don't feel I'm qualified enough to pass heavy judgment on much of the paper, except in an assessment that the general intuition and ideas presented seem sound and well-supported. It *needs* more qualified eyes in my view to pinpoint any potential holes and drawbacks to the math

Perhaps I am naive in thinking the "good" guys will beat the "bad" in this case, but I think it's closer to the spirit of FOSS/"no trusted 3rd parties" (of which I am biased toward) for yielding a stronger outcome

To be clear, in case not everyone is aware, jberman has seen my VRP submission in full.

I have thoughts on what jberman just said, but I want to give others a chance to respond first.

It's standard practice to publicize vulnerabilities even in much more widely adopted technologies.

After a period of 'hey fix this if you can...'

UkoeHB: I feel like things are fundamentally different with a distributed blockchain. A "patch" doesn't fix past transactions. Also see Monero's VRP:

>HIGH severities will be notified via at least one public communications platform (mailing list, reddit, website, or other) within 3 working days of patch release

>i. The notification should list appropriate steps for users to take, if any

>ii. The notification must not include any details that could suggest an exploitation path

>iii. The latter takes precedence over the former

I think (ii) could be interpreted to mean that full disclosure should not necessarily happen even after a "patch" is applied, depending on circumstances.

re:#7953 "There is no difference in sync between high end server or low end pi , just network connection" this guy is full of shit

Rucknium[m]: I think the problem lies in the culture of FOSS and privacy tech. Image you were working on a different project (e.g. a Monero fork). You privately disclose your attack to them, and secretly concoct a solution for that project. What does your solution then look like to us Monero folk? Completely useless made up nonsense (regardless of its efficacy). Our selection would remain the same, and remain vulnerable, because

we don't have the insiders to vouch for you and your research.

Even if you privately disclose your research to all projects that you can find, what about projects that come later? How can we humans, who excel at incremental progress, build on what you discovered?

By enacting that pattern for us, you are implicitly encouraging that pattern to be used to our detriment. In the long run, I think it is better for all _theoretical_ research to be open, even if in the short term there are costs.

UkoeHB: I may be much more pragmatic. Look, the status quo is the following:

all of this is iterative. let this phase be confidential as it currently is. once an initial patch is released, that doesn't mean the work will stop.

The current mixin (or decoy) selection algorithm was developed by:

1) Non-statisticians who were

2) partially funded by the U.S. Department of Homeland Security, one of whom was

3) a member of the board of Zcash (Andrew Miller)

They did not explain in their paper how they chose the gamma family of distributions. They basically just said, "Based on our human eyeballs, it looks gamma"

I do not trust human eyeballs. Only robot eyeballs are trustworthy ;)

Sure, but human eyeballs aren't much better than 'trust me I did the math'.

To be specific, this is their rationale, given in Moser et al. 2018:

"We heuristically determined that the spend time distributions, plotted on a log scale, closely match a gamma distribution."

better/worse

There's that word again, "heuristic" 🧐

Look, I am pulling together a scientific review panel. They will review my work.

'trust us we did the math'

Same thing lol

Yes, it will require trust. Better than spilling an attack to CipherTrace and their ilk.

I address this issue in my CCS proposal text, for anyone who is wondering. Since I fully anticipated it would be a sticking point.

UkoeHB: I think your suggestion is based in ideology rather than a practical look at risks.

A cryptocurrency is not simply a practical thing

A dozen people have seen or will soon have seen this. It'll be out at some point anyway.

moneromooo: To clarify, given the people that have seen it so far as well as the people who will soon see it, am I still technically following the VRP? In other words am I "abid[ing] by the VRP for responsible disclosure"?

we usually don't follow the VRP in a super strict way

just do what makes sense

selsta: Ok. The main concern that I have is I don't want there to be a conversation later that goes, "Rucknium didn't follow the VRP." I don't really care about any possible bounty. I just want to do the right thing -- and, I suppose, not be accused of doing the wrong thing later.

Like I have stated, this is a new type of process for me, so any guidance is useful

Well, you asked, so it's not like you just plastered it across the internet.

So there is evidence that you tried to do the right thing, if nothing else. Or at least, that you tried to make it look like you were :P

<sech1> "use sweep_single to churn a..." <- if you churn multiple inputs in one tx, do you reduce "only" your privacy, or others' as well?