01:53:06 <merope> Rucknium https://github.com/endorxmr/monero-node-p2p-scanner
02:07:44 <merope> One thing you can expect to find: several ip addresses that show up multiple times, with different p2p ports (and sometimes different rpc ports too)
02:10:31 <merope> In fact, there are entire /24 ip ranges that show up like that - and if you try to reach any of them, you will typically not be able to. Could be someone trying to mess with the network, or maybe just some weird experiment
02:41:01 <Rucknium[m]> Thanks!
02:44:12 <merope> No problem, hope you find it useful. Should be pretty straightforward to use, but let me know if you have any questions
02:45:20 <merope> One idea I had for an improvement would be to save each node's response individually, thus allowing us to draw a full node graph
02:46:55 <merope> But wasn't sure on what the best tools for such a job are, so never got around to it
02:48:37 <Rucknium[m]> That's what the Cao et al. (2020) paper does. Gets the nodes (vertices) and the connections (edges) to get the full graph.
15:30:36 <UkoeHB> meeting 1.5hr
15:52:26 <Rucknium[m]> <UkoeHB> "I put together an overview of..." <- Thank you! Would be good to have a summary table comparing Seraphis 128 ring size and CLSAG 16 ring size transactions: Ring size, tx byte size, verification time, wallet scanning time.
15:54:09 <Rucknium[m]> For "Find-received" key: Is it like current view tags? The light wallet server finds the view tags and then send to client wallet only ones that match? If that's how it works, what proportion of all transactions would the light wallet server send to the client wallet?
15:55:23 <Rucknium[m]> "Some care has to be taken here because a timing analysis can theoretically be performed on the Janus detection branch." Is there somewhere I can read about this timing analysis?
15:57:04 <Rucknium[m]> "In the current protocol, output ordering is implementation-defined because onetime addresses are a function of output index (Seraphis does not need this)." Is this visible on-chain or to the recipient of a transaction? Bitcoin has BIP69 to fix their tx uniformity, but it doesn't have good adoption: https://transactionfee.info/charts/transactions-bip69-compliant/
16:14:42 <moneromoooo> It is visible to the recipient which output they get (obviously) but not to others.
16:15:08 <moneromoooo> With typical transfer+change 2 out txes, it means the recipient knows which output is change. Observers do not.
16:15:57 <moneromoooo> This assumes the output that doesn't go to the recipient goes back to the sender, which is a pretty good assumption, but not necessarily true.
16:22:10 <UkoeHB> Rucknium[m]: yes the find-received key can only check view tags. It’s 1/256 on average that pass that check
16:23:18 <UkoeHB> The timing analysis is just because balance recovery is not necessarily constant time, depending on implementation (the current impl is not constant time). There are many verification steps that can early-cancel, and the Janus check is one of them
16:24:31 <UkoeHB> If you think user A has address B, and you have a side channel on A, then you can send funds to B and watch A during balance recovery.
16:25:21 <UkoeHB> Tbh it’s not specifically the Janus check that’s the problem.
16:25:45 <UkoeHB> Making everything constant time would seriously degrade performance
16:27:32 <UkoeHB> Output ordering is not visible on-chain but if your wallet impl is not randomizing output order then you might be able to use other fingerprinting data to identify txs made by that impl, then learn something about the outputs in those txs (ie which ones are change).
16:28:11 <Rucknium[m]> I've wondered about the computational time issue for view tags as they are implemented now: Remote node sends all txs to a wallet, the wallet scans. The wallet takes slightly more time to fully scan an output that belongs to it. Could the remote node infer anything? I'm guessing probably not due to noise in the connection latency/bandwidth.
16:28:34 <UkoeHB> That’s an important question, I don’t know
16:29:30 <UkoeHB> Someone who knows more about that stuff should look into it
16:30:18 <UkoeHB> For example, I know mobilecoin put a ton of effort into making their remote Fog-based balance recovery constant time
16:37:30 <UkoeHB> Although that was mostly in-enclave iirc
17:00:11 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/768
17:00:11 <UkoeHB> 1. greetings
17:00:11 <UkoeHB> hello
17:00:23 <vtnerd> hello
17:00:27 <rbrunner> hello
17:01:05 <one-horse-wagon[> Hello.
17:01:19 <Rucknium[m]> Hi
17:01:23 <ghostway[m]> Hello
17:01:26 <monerobull[m]1> Hi
17:01:37 <plowsof11> hi
17:02:36 <jberman[m]> Hello
17:02:56 <UkoeHB> 2. updates, what's everyone working on?
17:03:55 <vtnerd> just started looking at bp++
17:04:24 <vtnerd> started with the readme and docs this time instead of haskell code. slightly more confident that Ill be able to do something, more details next week hopefully
17:04:35 <vtnerd> Im still piecing together my internally busted network
17:05:09 <vtnerd> the haskell is just rough because its math-heavy-crypto code. so its like a terrible crash-course in haskell lol
17:05:57 <rbrunner> I made my "long addresses" Reddit post: https://old.reddit.com/r/Monero/comments/zl4615/why_seraphis_jamtis_addresses_will_be_so_awfully/
17:06:05 <Rucknium[m]> I have been looking at fee prediction. It won't be a research topic for several months, but we should be collecting mempool data now. I read Huberman, G., Leshno, J. D., & Moallemi, C. (2021). "Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System." To my surprise, the model assumes that users don't know the mempool contents. The paper's purpose is to discover the long-run fee equilibrium behavior, so
17:06:06 <Rucknium[m]> it makes sense I guess.
17:06:18 <Rucknium[m]> I wrote some code to collect mempool txs
17:06:29 <plowsof11> no resp yet from follow up email to bp++ author. i've kept CypherStack up to date on the delay and they are understanding / will be patient.
17:06:36 <UkoeHB> me: finished reviewing my multisig changes (vtnerd those will keep you busy all next year :) ), and wrote this overview of the current Seraphis design https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e (let me know if I am missing anything - I will add a table for tx parameters as requested by Rucknium[m])
17:06:53 <jberman[m]> Submitting a PR hopefully today implementing a few changes on top of PR 8076 that will help daemons process RPC requests when the tx pool is under heavy load, following this comment: https://github.com/monero-project/monero/pull/8076#issuecomment-1340590787
17:06:55 <Rucknium[m]> vtnerd: Did you see the MRL log from last meeting about a new Dandelion++ paper?
17:07:14 <vtnerd> haha my ccs time is just being code-reviews, but everyone keeps saying Im decent at them so why not
17:08:14 <rbrunner> jberman[m]: Nice. I may have time on Friday to look at it.
17:10:37 <UkoeHB> 3. discussion
17:11:49 <rbrunner> Some info about the reactions on Reddit to my post:
17:11:55 <rbrunner> Pretty favorable, I would say
17:12:00 <rbrunner> Somebody made another post about possible disruption: https://old.reddit.com/r/Monero/comments/zlr2m4/the_downside_of_jamtis_addresses/
17:12:15 <rbrunner> That came out a bit more controversial, but not unexpectedly so
17:12:43 <rbrunner> And I learned that Lightning Network invoices are at least 190 characters long :)
17:13:19 <rbrunner> In Base32, by the way
17:16:15 <UkoeHB> might be good to make a reddit post about that seraphis design overview (I'm not on reddit)
17:16:40 <rbrunner> I can do that, if that's ok with you
17:16:42 <UkoeHB> everyone might not realize the design has stabilized
17:16:54 <UkoeHB> and I am not even writing new code for over a week
17:17:20 <UkoeHB> last new thing was 10 days ago
17:17:58 <isthmus> That's exciting :)
17:17:59 <UkoeHB> rbrunner: sure
17:18:32 <UkoeHB> isthmus: yeah :) now for the long agonizing review process
17:19:04 <blankpage[m]> Is it fair to say that the seraphis paper is outdated?
17:19:11 <isthmus> Hey Rucknium, RE "Remote node sends all txs to a wallet, the wallet scans. The wallet takes slightly more time to fully scan an output that belongs to it. Could the remote node infer anything?" 
17:19:12 <isthmus> ^^ you might find this an interesting read https://crypto.stanford.edu/timings/
17:19:24 <UkoeHB> blankpage[m]: not really, the core design is the same - most of the changes have been with jamtis
17:19:46 <blankpage[m]> Or has the paper been updated along with the finalization of the design?
17:21:18 <UkoeHB> blankpage[m]: the paper doesn't have jamtis in it
17:21:23 <Rucknium[m]> I am going to be a broken record: is there a roadmap for writing Seraphis security proofs? We could ask for outside help like CypherStack if necessary.
17:21:34 <blankpage[m]> Good to know, that you
17:21:36 <UkoeHB> I'm considering updating the paper with a case study of jamtis, not sure if that's a good idea or not
17:22:02 <UkoeHB> Rucknium[m]: no roadmap
17:22:14 <Rucknium[m]> Or Geometry Labs ;)
17:23:06 <Rucknium[m]> That means we still don't know for sure if Seraphis is secure.
17:23:33 <rbrunner> I think that's sure ...
17:23:38 <UkoeHB> the existence of a security proof doesn't guarantee that, if the proof itself is flawed
17:24:35 <isthmus> 🤔 ooh writing or analyzing those security proofs would be a fun project
17:24:39 <Rucknium[m]> Yes. Getting a "candidate" proof is the first step.
17:24:40 <UkoeHB> the only parts that seem security-proofable to me are the seraphis composition proof and the squashed enote model
17:25:16 <UkoeHB> security proofing jamtis would be an enormous task
17:26:39 <rbrunner> Is there an "ELI5" somewhere what, in principle, a "security proof" is? I confess to have no idea at all.
17:26:39 <UkoeHB> I also wrong a dual-base vector proof for multisig stuff, not sure if we want/need a security proof for that
17:27:06 <moneromoooo> If you wrong it, we sure do need a proof :D
17:27:25 <Rucknium[m]> Don't we still need to security proof Jamtis?
17:27:30 <Rucknium[m]> Even if it's a big task?
17:27:31 <UkoeHB> moneromoooo: lol
17:27:56 <UkoeHB> Rucknium[m]: CryptoNote and subaddresses were not security proofed
17:28:24 <UkoeHB> not to say if someone has a vision about how to security proof jamtis, that would be amazing
17:28:39 <UkoeHB> just not clear if it's mandatory
17:29:21 <rbrunner> I guess for starting something like that we would need a pretty strict "feature freeze" first?
17:29:30 <UkoeHB> probably
17:29:34 <Rucknium[m]> Is the lack of security proof for Cryptonote related to the counterfeiting bug several years ago?
17:30:02 <UkoeHB> possibly?
17:30:53 <dangerousfreedom> Hello. I guess I figured out how to make unspentproofs for seraphis. I will write about it by the weekend.
17:31:58 <UkoeHB> I guess I should make clear I won't be spending too much effort working on or looking for security proofs. My involvement is winding down as I have accomplished everything I set out to do.
17:32:22 <Rucknium[m]> Anyone want to answer rbrunner 's ELI question about security proofs? I know "regular" math proofs, but I'm not a cryptographer.
17:32:40 <isthmus> @rbrunner - security proofs involve formally defining an adversary and what it means for them to break a given aspect of a given system. And then the goal is to prove things like “an adversary being able to convert a public key into a private key would imply that they can break the discrete log problem” and stuff like that. 
17:32:40 <isthmus> So you can sleep a little better if there is a security proof thought to be correct. To push back on a security proof involves identifying an adversary that should have been included in the model, or a issue with the reduction to a “hard” problem like discrete log.
17:32:40 <isthmus> (take the ELI5 with a grain of salt, I manage GL’s cryptography wing but I am not a cryptographer myself)
17:33:17 <Rucknium[m]> UkoeHB: Good to know. So we should think about how to get those proofs using alternative means/personnel.
17:34:19 <rbrunner> Seems to me it's pretty open how to approach this then? Seems to depend on how you assume your adversary to be.
17:34:44 <rbrunner> Two cryptographers tasked with "Security proofs for Jamtis" might come up with pretty different things?
17:35:36 <Rucknium[m]> You can have multiple proofs of the same theorem. Basically, different paths to the same destination
17:37:01 <Rucknium[m]> Writing nontrivial math proofs is generally hard. I don't know how hard it is in cryptography, but also probably hard.
17:37:35 <Rucknium[m]> It's not just "put in enough effort and you will accomplish the task"
17:38:24 <rbrunner> I see. It may even be that nobody at all stumbles over the right approach in the cases of Seraphis and Jamtis.
17:39:06 <plowsof11> increase the hackerone pot would help in the future
17:39:13 <dangerousfreedom> We have the advantage that many people are looking here too which puts some pressure on the guy doing it as he has to have an authority bigger than the Monero community to say it is not flawed. Who did it when the RCT came?
17:39:48 <dangerousfreedom> (If it was done)
17:39:50 <Rucknium[m]> rbrunner: That is why I have brought it up repeatedly: We need someone to find this thing, and we are not sure yet whether this thing exists. If there is a counterexample, then Seraphis will need to be re-worked.
17:40:34 <Rucknium[m]> By "counterexample" I mean some fact that disproves the conjecture that Seraphis is secure
17:40:55 <rbrunner> Not sure we understand each other. I was thinking about the case where people try to "construct" such proofs, but nobody is able to.
17:41:16 <rbrunner> Like famous theorems in math that went unproved for literally centuries.
17:42:10 <Rucknium[m]> Yes, so we can run into trouble if either (1) no one can come up with a proof or (2) someone proves that Seraphis is insecure. You can find insecurity during the task of trying to prove security.
17:42:48 <Rucknium[m]> Sarang would obviously be a good person to attempt this since he worked on a similar cryptosystem.
17:43:03 <rbrunner> Well, I guess there still is review: Somebody traces step by step the constructs and sees whether everything makes sense.
17:44:17 <Rucknium[m]> I would find it hard to recommend Seraphis implementation on mainnet if we don't have the necessary security proofs.
17:45:06 <rbrunner> I think we don't have security proofs for the current constructs either :)
17:46:15 <rbrunner> Maybe we could buy something like 2 or 3 workdays from Sarang to look at it and then tell us whether they would like to try?
17:46:17 <Rucknium[m]> We have them for some of the constructs. I don't know the complete list of which we have and which we do not.
17:47:02 <Rucknium[m]> rbrunner: I would support that
17:50:32 <UkoeHB> we are approaching the end of the meeting - were there any other topics to bring up?
17:51:08 <one-horse-wagon[> Will someone be following up with Sarang?
17:52:36 <Rucknium[m]> Is there loose consensus for it? This would be a good project for MAGIC Monero Fund since the decision and funding could be done quickly.
17:53:01 <one-horse-wagon[> You have my vote.
17:53:07 <Rucknium[m]> We would need a more formal description of the outcome of the work
17:55:21 <plowsof11> does magic have a track record of quick funding? 
17:56:22 <Rucknium[m]> We can spend out of our general fund, which has about 50,000 USD IIRC
17:56:46 <Rucknium[m]> Split between USD and XMR pretty equally
17:57:26 <plowsof11> fund this one first https://monerofund.org/projects/statistical_attack_reduction
17:58:02 <Rucknium[m]> That one was approved based on requiring community funding
17:58:29 <one-horse-wagon[> Like rbrunner said, at least let's get Sarang to look at the problem for a few days as a first step.
17:59:13 <Rucknium[m]> Diego Salazar: Thoughts on the discussion above?
18:01:24 <Rucknium[m]> We need CypherStack to give an initial "yes" to some type of work. Then MAGIC Monero Fund committee can approve fund disbursement at its next meeting on Tuesday. MAGIC Board needs to give final approval. That's mostly just conflict-of-interest, in Monero Project scope, and KYC.
18:02:29 <DiegoSalazar[m]> Always down.
18:03:12 <UkoeHB> ok we are past the hour so I'll call it here, thanks for attending everyone; discussion about planning can continue as needed
18:03:55 <Rucknium[m]> Great. How could we describe the intended outcome of the work?
18:04:11 <DiegoSalazar[m]> Just keep in mind the holiday season might delay timelines.
18:04:37 <Rucknium[m]> Yes, understandable.
18:04:45 <DiegoSalazar[m]> Rucknium: you tell me, man. What do you guys want the deliverable to be. We work based off of the client desires here. 
18:05:20 <DiegoSalazar[m]> It seems you want either security proofs as a deliverable, or, barring that, reasoning why they can't be developed, OR a proof that Seraphis is insecure.
18:06:09 <Rucknium[m]> I would like the cryptographers in the room to guide discussion. To me, I think we would need identification of the gaps in the Seraphis paper that need to be filled before Seraphis goes on mainnet. Some estimate of what it would take to fill those gaps
18:06:14 <DiegoSalazar[m]> As isthmus said, we'd need a stated adversary as well, and it'd be wise to have it defined for us before-hand.
18:06:47 <DiegoSalazar[m]> Rucknium[m]: Ok. This should be doable. Anything else from anyone else?
18:07:41 <UkoeHB> that sounds good to me
18:07:48 <Rucknium[m]> Eventually we need security proofs. rbrunner 's suggestion was to see if Sarang or someone else at Cypherstack could see if writing the security proofs would be within their capabilities / areas of expertise.
18:08:25 <Rucknium[m]> So, spending a small amount of time and money now, with the possibility of spending a lot more
18:12:44 <Rucknium[m]> Diego Salazar: I will follow up with you soon after I get initial approval from the MAGIC Monero Fund committee.
18:20:38 <DiegoSalazar[m]> Great. Look forward to hearing from you guys. :)
18:20:40 <isthmus> Project description could have *high level* adversary classes and priorities. For example, proofs of security against passive observers of public blockchain data would be highly desirable deliverable, whereas security against side channel attacks might be “nice to have”
18:20:40 <isthmus> The technical adversary definitions are deeply nuanced, like “Under <X formal security model> [citation 1] an adversary with <Y> access to a random oracle can reduce P(k) by <Z> ....” so identifying the salient theoretical attackers and tailoring them to the system under review is a big part of the cryptanalysis research itself.
18:34:31 <monerobull[m]1> Where are all the anti-hardfork anti-seraphis accounts on reddit coming from
18:35:01 <monerobull[m]1> * coming from all of a sudden 
18:36:25 <ArticMine[m]> monerobull[m]1: Good question
18:37:40 <sech1> Are they new accounts? What's their creation date? Any posts in r/Monero or other crypto-related subreddits?
18:54:49 <monerobull[m]1> U/Spederan who apparently started posting 2 months ago, asked about the existence of a Monero JavaScript library 1 month ago and has now commented quite a bit against hardforks and also made the recent reddit post against Seraphis
18:57:50 <UkoeHB> guys this is off-topic
19:29:40 <rbrunner> UkoeHB: https://old.reddit.com/r/Monero/comments/zlzvij/preliminary_seraphis_design_overview/?
19:41:00 <UkoeHB> rbrunner: thanks