hi everyone, some one mentioned to me a potential ipv6 attack vector. ill paste his comments here:

"Okay let me explain. The ipv6 packet can be tracked via isp each packet can be tagged. They don't need to know what it's carrying just that it's connected rpc port. All of would take would be for an isp to start tagging all Monero network id that's publicly unencrypted. When your CPU unencrypts that data and scans the chain for your inputs and outputs with your keys. Microsoft could log the ipv6 packets and put them in the

cloud

All law enforcement needs to do is coordinate with Microsoft and the back doors they have in the CPU microcode with Intel. And the IP address receiving the IPv6 packet and they got you. They just haven't figured out how to coordinate to do it yet.

They could then match your viewkey to the unencrypted packets Microsoft provided and link it to the ipv6 packets the isp matches to what Microsoft recorded being unencrypted. The isp knows your isp that got the packet... See... It's just unlinked.

There behind by about five years I think. Avoid synching on an Intel or AMD CPU and don't use ipv6 in the future this vector might happen. All I'm saying"

is there any validity to this?

* aside from being really convoluted, is there

don't we have optimistic encryption for p2p connections?

this all looks like a random brain fart to me

I've not heard of ipv6 packet tagging like that

also not sure why you'd need to

starting from "ipv6 ... can be tagget"

*tagged

you know that ipv6 origin

so why do you need to tag the packet at all

DPI can of course detect all Monero traffic. Even simple filtering by RPC port number can do it

yes

also I don't understand what a viewkey has to do with it

but it can be done with regular IPv4 too

how would they have your viewkey

apparently, through CPU backdoor in microcode or something

lol

this is just one step above from "only RISC-V is safe"

fluffypony: this was in response to me posting vtnerd's p2p encryption issue on github. hes saying it doesnt matter cause its decrypted locally

Agree, it reads like word salad.

im not technical and couldnt really follow, but it sounded that way to me too

"match your viewkey to the unencrypted packets" another thing that doesn't make sense. Syncing wallet downloads all transactions from the node, so any valid viewkey form any real wallet would match something.

<fluffypony> "how would they have your viewkey" <- apparently by busting down your door for detecting monero traffic on your ISP and for pay taxes

i can dismiss most of the shit hes saying now, but its the ivp6 thing i was curious about

> <@fluffypony:libera.chat> how would they have your viewkey

* apparently by busting down your door for detecting monero traffic on your ISP and for not paying taxes

ipv6 doesn't need to use NAT, so 99.9% chance that your IPv6 address is enough (in theory) to identify the exact device that sent some IPv6 packet

IPv4 home users are almost always behind NAT which complicates things

yeah but running a Monero node doesn't mean you're using ito

*using it to evade taxes or whatever

you're just running a routing node on a p2p network

there's no tx broadcast correlation because of Dandelion++

so I'm still not understanding the exact risk

what might be nice is to make Tor + a Snowflake Proxy the default config

we're planning on doing that on Tari

meeting 1.5hr

Hello

hi

meeting time

Hi

1. greetings

hello

Hi

Hello

Hello

2. updates, what has everyone been working on?

I started working on the SpendProof which will be based on the grootle proofs in Seraphis. Still going through all the code, debugging and building my understanding about it.

Delivered fully specified OSPEAD plan to ArticMine, isthmus, and hyc. Syksy will probably not review it due to time commitments. Public portion to be released probably next week (MAGIC donation system is not ready yet this week).

I've been reviewing the above

Ditto, hoping to have my comments on Rucknium docs in the next 3 weeks

me: continued work on unit tests for spending legacy enotes in seraphis txs

Ditto. I am reviewing OSPEAD

Thank you, reviewers.

3. discussion, any topics/questions/comments on anyone's mind?

in case no one saw it, a new proof system was introduced in a recent paper monero-project/research-lab #107

in case anyone missed it*

The time line on OSPEAD, assuming there are no major snags, is to start doing the estimations in November, hopefully having the first draft of them ready in December. Note that this doesn't include an assessment of the risk of transaction non-uniformity when there are multiple wallet2 decoy selection algorithms being used due to slow user update.

Any comments yet to that new proof system?

Rucknium: did you publish your paper about the OSPEAD ? I missed it last week

limited release

Not yet. The plan is to publish a portion of it simultaneously with launching fundraiser for mj-xmr's C++ dev support of OSPEAD under the MAGIC Monero Fund.

rbrunner: not from me, would be nice to have some concrete benchmarks but that's not a trivial task

Somebody asked about the ringsize planned for Seraphis on Reddit, and I wonder how the way looks to a decision regarding that. Does that wait until code allows some benchmarks?

Or until we know exact transaction sizes in bytes for both variants, 64 versus 128=

Rucknium[m]: Ok.

rbrunner: based on my previous benchmarks, 128 ring size is about equivalent in performance to 16-ring size clsag

with BP++ efficiency/size improvements, it might be worth looking at 256 ring size (but I don't have an implementation to test right now)

So transaction size is not much of a problem there?

One can go up to 256 ring size without making changes to scaling / fees

Interesting

Trace that, Chainalysis :)

I'd doubt that a decision would be reached soon. Ring size is also linked to binning and decoy selection enforcement, which are areas that still need to be researched.

Hmmm ... and anywhere there smaller could be better than bigger, regarding rings?

Not to mention alternative decoy selection algorithms as a potential source of transaction uniformity defects.

rbrunner: no I don't think so

rbrunner: Probably not, unless things are screwed up badly. For example, if many, many wallet devs run with many alternative DSAs, and the larger ring size makes it easier to determine which wallet constructed each tx.

Yeah, that should be a consensus too. But how to enforce that?

I see. I hope we will succeed in building a good wallet for Seraphis, so people don't get itchy fingers to "improve" in the first place.

'Proof of building the ring' somehow? :p

dangerousfreedom: Consensus enforcement is probably too strict. Could enforce at node tx relay level: monero-project/research-lab #87

Rucknium[m]: I see. Yeah, nodes could have a consensus to run some checks if the ring decoys were built properly. The same as it could be done with canonical points/scalars.

Thanks

That seems to be the worst of both words, no ? The reason not to add consensus ring distribution checks is performance (AFAIK). Doing this as a relay check only means you get the hit anyway, but still allow blocks with stuff that doesn't pass.

With consensus it's harder to change later if needed. ArticMine did not like the idea of consensus enforcement. Let's see...

^^^

baking a big pile of heuristics into the protocol increases project dependency on the core team for future hard forks, which is a step in the wrong direction imo

how is it any harder than the upgrade we just performed? 2 hardforks in a 24hr period to allow for migration

I think the problem would more be too many hardforks, and in to short succession ...

Not their "hardness"

the goal should be fewer hardforks

There are many problems

no just HF

Looks to me a matter of increasing the blockchain size or increasing the computation dependency. I would go for increasing the computations (as it wont destroy the blockchain if a bad transaction is accepted)

^ Previous discussion on this topic

I hope we don't enforce the DSA because analyzing incorrectly constructed rings is like 2/3 of the fun over in Noncesense research, heh. And with bigger ring size, the fingerprints will become more statistically certain.

(joking, mostly)

I think it's not great if we have to tell people that they are really only safe if they use a wallet2-derived wallet

fwiw it makes sense not to bake it in at consensus level, at least not yet.

isthmus: Chain analysis companies are thinking the same thing, probably. But they are not joking.

since modeling true spend distribution is a continually moving target

And think about the added complexity of consensus checks, for an uncertain amount of gains

Complexity already jumps up greatly with Seraphis and Jamtis anyway.

small aside: "tell people that they are really only safe if they use a wallet2-derived wallet" --> I would make a subtle change but an important and practical one. "People are only safe if they use a wallet that produce transactions that match the reference spec (as implemented in wallet2)". Doesn't have to be wallet2-derived as long as it follows the correct behavior.

meanwhile, I don't think we can avoid telling people they're only safe if they use wallet2, since fingerprinting is a liability otherwise

I think we can estimate the gains pretty well.

Seraphis is an opportunity to remove some fingerprintability. For example, the fee discretization should reduce the fee fingerprintability a lot.

<3

Damn there goes one of my weekend projects

Hopefully we put Noncense out of business eventually :P

any last-minute topics before we close out the meeting?

ok I'll call it here, thanks for attending everyone

thanks all

<rbrunner> "Or until we know exact transacti..." <- What is the current estimated difference in transaction size between ringsize 64 and ringsize 128?

see the results posted here monero-project/research-lab #91

<Rucknium[m]> "Hopefully we put Noncense out of..." <- What is Noncesense?

Thanks hyc. It looks like there isn't much of a difference in transaction size between 64 and 128 members.

fr33_yourself: noncesense-research-lab.github.io

So they aren't working for the government and seem to be operating in goodfaith?

Yes. Check the contributors list. It's all Monero people AFAIK.

fr33_yourself[m]: here is an excellent video from isthmus, truly valuable work youtube.com/watch?v=XIrqyxU3k5Q

Thanks