09:13:28 <r4v3r23[m]> hi everyone, some one mentioned to me a potential ipv6 attack vector. ill paste his comments here:
09:13:46 <r4v3r23[m]> "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
09:13:46 <r4v3r23[m]> cloud 
09:13:46 <r4v3r23[m]> 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.
09:13:49 <r4v3r23[m]> 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. 
09:13:49 <r4v3r23[m]> 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"
09:13:58 <r4v3r23[m]> is there any validity to this?
09:15:10 <r4v3r23[m]> * aside from being really convoluted, is there
09:15:12 <fluffypony> don't we have optimistic encryption for p2p connections?
09:15:31 <sech1> this all looks like a random brain fart to me
09:15:53 <fluffypony> I've not heard of ipv6 packet tagging like that
09:15:56 <fluffypony> also not sure why you'd need to
09:15:56 <sech1> starting from "ipv6 ... can be tagget"
09:16:02 <sech1> *tagged
09:16:04 <fluffypony> you know that ipv6 origin
09:16:10 <fluffypony> so why do you need to tag the packet at all
09:16:33 <sech1> DPI can of course detect all Monero traffic. Even simple filtering by RPC port number can do it
09:16:37 <fluffypony> yes
09:16:44 <fluffypony> also I don't understand what a viewkey has to do with it
09:16:51 <sech1> but it can be done with regular IPv4 too
09:16:53 <fluffypony> how would they have your viewkey
09:17:16 <sech1> apparently, through CPU backdoor in microcode or something
09:17:21 <fluffypony> lol
09:17:54 <fluffypony> this is just one step above from "only RISC-V is safe"
09:19:21 <r4v3r23[m]> fluffypony: this was in response to me posting vtnerd's p2p encryption issue on github. hes saying it doesnt matter cause its decrypted locally
09:19:22 <grumblemobile> Agree, it reads like word salad.
09:20:19 <r4v3r23[m]> im not technical and couldnt really follow, but it sounded that way to me too
09:23:13 <sech1> "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.
09:32:53 <r4v3r23[m]> <fluffypony> "how would they have your viewkey" <- apparently by busting down your door for detecting monero traffic on your ISP and for pay taxes
09:33:13 <r4v3r23[m]> i can dismiss most of the shit hes saying now, but its the ivp6 thing i was curious about
09:33:28 <r4v3r23[m]> > <@fluffypony:libera.chat> how would they have your viewkey
09:33:28 <r4v3r23[m]>  * apparently by busting down your door for detecting monero traffic on your ISP and for not paying taxes
10:09:19 <sech1> 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
10:10:22 <sech1> IPv4 home users are almost always behind NAT which complicates things
12:18:49 <fluffypony> yeah but running a Monero node doesn't mean you're using ito
12:18:56 <fluffypony> *using it to evade taxes or whatever
12:19:03 <fluffypony> you're just running a routing node on a p2p network
12:19:14 <fluffypony> there's no tx broadcast correlation because of Dandelion++
12:19:28 <fluffypony> so I'm still not understanding the exact risk 
12:20:00 <fluffypony> what might be nice is to make Tor + a Snowflake Proxy the default config
12:20:04 <fluffypony> we're planning on doing that on Tari
15:33:13 <UkoeHB> meeting 1.5hr
16:59:39 <one-horse-wagon[> Hello
17:00:13 <hyc> hi
17:00:23 <UkoeHB> meeting time
17:00:28 <Rucknium[m]> Hi
17:00:32 <UkoeHB> 1. greetings
17:00:32 <UkoeHB> hello
17:00:35 <ArticMine[m]> Hi
17:00:41 <rbrunner> Hello
17:00:47 <dangerousfreedom> Hello
17:00:58 <UkoeHB> https://github.com/monero-project/meta/issues/738
17:02:48 <UkoeHB> 2. updates, what has everyone been working on?
17:05:01 <dangerousfreedom> 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.
17:05:21 <Rucknium[m]> 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). 
17:05:33 <hyc> I've been reviewing the above
17:06:23 <isthmus> Ditto, hoping to have my comments on Rucknium docs in the next 3 weeks
17:06:56 <UkoeHB> me: continued work on unit tests for spending legacy enotes in seraphis txs
17:07:21 <ArticMine[m]> Ditto. I am reviewing OSPEAD
17:07:27 <Rucknium[m]> Thank you, reviewers.
17:09:20 <UkoeHB> 3. discussion, any topics/questions/comments on anyone's mind?
17:11:40 <UkoeHB> in case no one saw it, a new proof system was introduced in a recent paper https://github.com/monero-project/research-lab/issues/107
17:11:51 <UkoeHB> in case anyone missed it*
17:12:17 <Rucknium[m]> 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.
17:13:23 <rbrunner> Any comments yet to that new proof system?
17:13:52 <dangerousfreedom> Rucknium: did you publish your paper about the OSPEAD ? I missed it last week
17:14:33 <hyc> limited release
17:15:13 <Rucknium[m]> 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.
17:16:03 <UkoeHB> rbrunner: not from me, would be nice to have some concrete benchmarks but that's not a trivial task
17:17:22 <rbrunner> 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?
17:17:42 <rbrunner> Or until we know exact transaction sizes in bytes for both variants, 64 versus 128=
17:18:10 <dangerousfreedom> Rucknium[m]: Ok.
17:19:35 <UkoeHB> rbrunner: based on my previous benchmarks, 128 ring size is about equivalent in performance to 16-ring size clsag
17:20:07 <UkoeHB> 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)
17:20:28 <ArticMine> https://github.com/monero-project/research-lab/issues/91
17:20:48 <rbrunner> So transaction size is not much of a problem there?
17:21:02 <ArticMine> One can go up to 256 ring size without making changes to scaling / fees
17:21:52 <rbrunner> Interesting
17:22:38 <rbrunner> Trace that, Chainalysis :)
17:22:43 <Rucknium[m]> 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.
17:23:40 <rbrunner> Hmmm ... and anywhere there smaller could be better than bigger, regarding rings?
17:23:52 <Rucknium[m]> Not to mention alternative decoy selection algorithms as a potential source of transaction uniformity defects.
17:24:41 <UkoeHB> rbrunner: no I don't think so
17:25:40 <Rucknium[m]> 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.
17:26:56 <dangerousfreedom> Yeah, that should be a consensus too. But how to enforce that?
17:27:19 <rbrunner> 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.
17:27:29 <dangerousfreedom> 'Proof of building the ring' somehow? :p
17:28:15 <Rucknium[m]> dangerousfreedom: Consensus enforcement is probably too strict. Could enforce at node tx relay level: https://github.com/monero-project/research-lab/issues/87
17:30:25 <dangerousfreedom> 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.
17:30:27 <dangerousfreedom> Thanks
17:32:19 <moneromooo> 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.
17:33:34 * isthmus agrees with mooo
17:34:20 <Rucknium[m]> With consensus it's harder to change later if needed. ArticMine did not like the idea of consensus enforcement. Let's see...
17:34:45 <ArticMine> ^^^
17:35:03 <UkoeHB> 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
17:35:25 <hyc> how is it any harder than the upgrade we just performed? 2 hardforks in a 24hr period to allow for migration
17:35:59 <rbrunner> I think the problem would more be too many hardforks, and in to short succession ...
17:36:10 <rbrunner> Not their "hardness"
17:36:15 <UkoeHB> the goal should be fewer hardforks
17:36:24 <ArticMine> There are many problems
17:36:32 <ArticMine> no just HF
17:37:58 <dangerousfreedom> 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)
17:38:17 <Rucknium[m]> https://libera.monerologs.net/monero-research-lab/20211006#c36752
17:39:04 <Rucknium[m]> ^ Previous discussion on this topic
17:40:04 <isthmus> 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.
17:40:07 <isthmus> (joking, mostly)
17:40:14 <Rucknium[m]> 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
17:40:36 <hyc> fwiw it makes sense not to bake it in at consensus level, at least not yet.
17:41:02 <Rucknium[m]> isthmus: Chain analysis companies are thinking the same thing, probably. But they are not joking.
17:41:06 <hyc> since modeling true spend distribution is a continually moving target
17:43:01 <rbrunner> And think about the added complexity of consensus checks, for an uncertain amount of gains
17:43:31 <rbrunner> Complexity already jumps up greatly with Seraphis and Jamtis anyway.
17:43:39 <isthmus> 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.
17:43:41 <hyc> meanwhile, I don't think we can avoid telling people they're only safe if they use wallet2, since fingerprinting is a liability otherwise
17:43:45 <Rucknium[m]> I think we can estimate the gains pretty well.
17:44:50 <Rucknium[m]> Seraphis is an opportunity to remove some fingerprintability. For example, the fee discretization should reduce the fee fingerprintability a lot.
17:44:58 <isthmus> <3
17:45:12 <isthmus> Damn there goes one of my weekend projects
17:46:47 <Rucknium[m]> Hopefully we put Noncense out of business eventually :P
17:48:09 <UkoeHB> any last-minute topics before we close out the meeting?
17:51:39 <UkoeHB> ok I'll call it here, thanks for attending everyone
17:53:29 <hyc> thanks all
18:41:41 <fr33_yourself[m]> <rbrunner> "Or until we know exact transacti..." <- What is the current estimated difference in transaction size between ringsize 64 and ringsize 128?
18:44:41 <hyc> see the results posted here https://github.com/monero-project/research-lab/issues/91
18:47:36 <fr33_yourself[m]> <Rucknium[m]> "Hopefully we put Noncense out of..." <- What is Noncesense?
18:53:14 <fr33_yourself[m]> Thanks hyc. It looks like there isn't much of a difference in transaction size between 64 and 128 members.
18:57:02 <Rucknium[m]> fr33_yourself: https://noncesense-research-lab.github.io/
19:11:03 <fr33_yourself[m]> So they aren't working for the government and seem to be operating in goodfaith?
19:13:40 <Rucknium[m]> Yes. Check the contributors list. It's all Monero people AFAIK.
19:13:46 <UkoeHB> fr33_yourself[m]: here is an excellent video from isthmus, truly valuable work https://www.youtube.com/watch?v=XIrqyxU3k5Q
19:19:00 <fr33_yourself[m]> Thanks