02:54:25 Commented my rationale supporting both FCMP++ research proposals in advance of tomorrow's MRL meeting: https://github.com/monero-project/meta/issues/1119#issuecomment-2516057549 09:33:48 Brandon Goodell's GBP security review cc jberman kayabanerve https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_27508 15:31:17 MRL meeting in this room in one and half hours. 17:01:10 Meeting time! https://github.com/monero-project/meta/issues/1119 17:01:15 1) Greetings 17:01:16 Howdy 17:01:22 Hi 17:01:23 *waves* 17:01:27 Hello 17:01:49 hi 17:02:04 hello 17:03:43 2) Updates. What is everyone working on? 17:04:21 I’ve got to fix a functional test in my monerod patches, its a pain tracking it down for some reason 17:05:27 me: Suggested spy node ban list community communication plan: https://gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88 boog900 . HackerOne report. 17:05:41 Me: testing and improving the Carrot code 17:06:00 me: wrapping up FCMP++ wallet sync starting from arbitrary restore height (it's working as expected), then planning to move over to FCMP++ proof construction over the FFI 17:06:36 Not me, but i hope that those MAX_INPUT tests check 64+ inputs 17:06:46 I also commented my +1 on Gooddell's GPB review linked above by @plowsof, and provided more detailed rationale in support of moving forward with Cypher Stack to review Veridise's work on logarithmic derivatives in divisors, and to move forward with Veridise on R1CS proving 17:06:54 Thanks jberman 17:07:36 3) Carrot audit/review: https://github.com/cypherstack/carrot-audit/releases/download/final/Carrot-final.pdf 17:08:09 jeffro256: Could you give a summary and maybe TODO list that came out of this audit/review? 17:09:32 The review went well with no real crypto issues , I just need to clarify some portions of the spec 17:09:51 Also there were a couple typos 17:10:19 But overall I'm happy with how it went 17:11:25 One change that Kayaba brought up that would actually change the crypto is doing switch commitments 17:12:00 Doesn't that require a lot of post-quantum R&D? 17:13:49 Not really if we're scoping it to just commitments they're pretty well understood 17:14:12 The hard part is getting some PQ security out of the onetime outputs and key images 17:14:22 But that part can be done later 17:14:23 What would that type of commitments improve? 17:15:05 Amount commitment blinding factors are transmitted as part of the sender-receiver protocol and thus need to be decided beforehand 17:16:33 Rbrunner: A switch commitment allows for a commitment to be perfectly blinding and computationally binding until it "switches" to perfectly binding 17:17:02 Well not really "perfectly", but still computationally binding against a quantum computer 17:17:27 So they would be a step towards future PQ security? 17:17:35 In higher level terms, it let's us set up a PQ-secure turnstile in the future 17:18:07 And using those would not invalidate the audit results just obtained? 17:18:31 we'd basically get post-quantum monetary soundness in exchange for losing confidentiality 17:18:43 Would it be a true turnstile or just a future prohibition on spending outputs that do not have the switch commitments, i.e. outputs produced before switch commitments were available? 17:19:04 I think they would basically be a very small-scoped swap of one part of the derivation, so we would need to revalidate just that small bit of the derivation , but nothing else 17:20:43 Well it wouldn't lose confidentially unless actively "switched". We wouldn't retroactively lose confidentially for enotes spent before the turnstile 17:21:41 yes, this is to mean what comes after the hypothetical fork that flips the switch 17:22:06 It depends on the implementation, but old outputs do not use switch commitments so there wouldn't be any way to prove a quantum computer didn't open its commitment to an arbitrary value so those probably wouldn't be allowed 17:24:00 Proving ownership PQ-securely will be a lot harder , but that is specific to how the wallet derives its addresses , but doesn't need to be a part of the addressing protocol 17:24:07 (At the moment) 17:25:13 Switch commitments *do* though, unless we were to transmit the entire blinding factor encrypted to the receiver (which RingCT did do at one point) 17:25:46 However, this costs an extra 32 bytes per enote 17:25:52 Ok. This is a big decision, so maybe we can think about it and come back next meeting to discuss more. 17:25:58 4) Security Review - Generalized Bulletproofs. Brandon Goodell's comments. https://repo.getmonero.org/-/project/54/uploads/b2d5c8198f55d72b588f1ef138126850/GBP_Security_Review.pdf https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_27508 17:26:56 jberman: What is the "tightness gaps" you mentioned? 17:28:18 As far as I can tell, everything came out fine in the GBP review. 17:29:39 From section 4.1: "security proofs do not merely establish 17:29:39 security. The proof itself contains a description of a reduction from one problem to 17:29:41 another, and the details of that reduction lead to a tightness gap in security. Both 17:29:43 [3] and [7] neglect analysis of tightness. This is a usual practice and up to 17:29:45 industry standards." 17:31:35 Does "reduction from one problem to another" mean that it has been proven that P ⇔ Q? That statements P and Q are equivalent? 17:32:03 The "tightness gap" makes me think that they are not proven exactly equivalent. 17:32:56 Anyway, maybe this is something I need to educate myself on. Goodell says that GBP is proven OK up to industry standards. 17:34:40 Any more comments on this? 17:34:51 Are they already implemented for Monero, those GBPs? 17:34:55 I don't know if that question is directly relevant/exactly how it relates. From the conclusion which migh help provide more color: "The tightness gaps implied by the security proofs of [7] imply a lower bound on 17:34:55 scheme security, and this bound weakens with each transcript rewinding. Ensuring 17:34:57 this lower bound exceeds cryptographic security is a conservative way to select 17:34:59 system parameters for future system designers. It would be nice that [7] be modified 17:35:01 to mention and compute tightness gaps. Due to this, security theorem statements 17:35:03 are most useful when stated like this: If there exists an algorithm A which runs in 17:35:05 time at most tA and breaks one of the security properties of scheme S with success 17:35:07 probability at least ϵA, then there exists an algorithm B which runs in time at most 17:35:09 tB and solves a famously hard problem P with success probability at least ϵB" 17:36:14 This is sort of about the total bits of security of Monero txs, maybe 17:37:52 GBPs are "generalized bulletproofs" and are a core component of FCMP++. Kayaba implemented GBPs in his work on FCMP++ 17:38:21 Nice 17:39:09 5) Proposed Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points". https://gist.github.com/kayabaNerve/6173fa623ac0f6a9cd4269c16f3ffd48 17:42:11 The review sounds good to me. Thanks for the write-up, kayabanerve 17:43:01 It does seem relevant in that the choice of bit-security may be affected by the tigtness gap (i.e. a "tighter" gap seems to imply a wider window for certain classes of attacks, rendering a higher bit security unnecessary? I'm may be reading that portion incorrectly) 17:43:20 Yes, those gists are valuable to keep the (at least for me) much welcome overview 17:43:24 sorry, rending a higher bit security more necessary* 17:44:07 That proposed review seems good to me also 17:44:51 Nice :) 17:45:15 Reiterating +1 from me too 17:45:25 Anyone else have comments on Proposed Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points"? 17:45:27 Does Monero help here to push forward the state of the art of crypocurrencies in general? 17:47:19 AFAIK Monero seems to be the most widely used application of BPs, so it would certainly make sense for Monero to push forward research into attacks / security hardening for BPs 17:47:41 Interesting. 17:49:04 I see loose consensus here in favor of Cypher Stack review of "On the Use of Logarithmic Derivatives in Eagen’s Proof of Sums of Points". https://gist.github.com/kayabaNerve/6173fa623ac0f6a9cd4269c16f3ffd48 17:49:40 Or maybe jeffro wants to say something 17:50:27 Maybe not. Let's move on. 17:50:32 6) Veridise proposed work: Formal definition of an interactive protocol and verifying the R1CS defined in the FCMP++ paper aligns. https://gist.github.com/kayabaNerve/175a00de6edd3a64458dacb4f5e481e0 17:51:09 Seems good to me 17:51:27 +1 17:51:34 Yes, thankfully looks good, because we need those R1CSs - whatever they are :) 17:52:36 rbrunner: this is a good primer: https://learn.0xparc.org/materials/circom/additional-learning-resources/r1cs%20explainer/#context-what-is-r1cs-and-how-does-it-fit-in 17:53:16 Thanks, looks pretty wild :) 17:53:30 it is :) 17:54:04 Sorry, reviewing other people's review on zk proofs is a bit over my head ;) 17:54:50 Hopefully someday it won't be 17:56:55 Do we have loose consensus here in favor of this proposed work by Veridise? 17:57:09 +1 17:57:34 I find the forest of proofs and reviews a bit hard to navigate, that flow chart discussed last week would definitely help :) but I have no objection either. 17:58:05 With limited information , I say +1 17:58:06 I've been working on this spread sheet: https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/ 17:59:30 jberman this is awesome. thank you. additional respect for using CryptPad. 17:59:42 Quite a number of lines towards the end, but those are mostly or even all code audits, right? 17:59:43 :) 18:00:18 Almost all code audits except "Gadgets formal verification" 18:00:21 Thus quite straightforward 18:00:40 I see loose consensus in favor of Veridise proposed work: Formal definition of an interactive protocol and verifying the R1CS defined in the FCMP++ paper aligns. https://gist.github.com/kayabaNerve/175a00de6edd3a64458dacb4f5e481e0 18:00:57 7) Discussion: preventing P2P proxy nodes. https://github.com/monero-project/research-lab/issues/126 18:01:01 So with those "gadgets" the "crypto" will be complete. 18:01:31 I wrote a draft post to urge node operators to enable boog900 's ban list: https://gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88 18:01:55 Note that the draft says "The Monero Research Lab (MRL) has decided to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses." 18:02:05 @rbrunner yep, we're approaching the finish line for theoretical vetting of FCMP++ 18:02:12 Is that accurate? Does MRL make that recommendation? Discuss. 18:04:08 Seems to me evidence is good enough, and potential harm big enough, to indeed speak out such a recommendation. We don't go overboard here, if you ask me. 18:04:13 I hope this can be released in a week or so. It would also need some Monero devs and researchers to PGP-sign the ban list and to ask SethForPrivacy to add the ban list to his monerod Docker template. 18:05:51 Anyone should feel free to suggest edits by making a comment on the gist 18:06:34 "MRL has decided to ask node operators to block these IP addresses voluntarily instead of by default." For what it's worth, that seems important to me. 18:06:52 IMHO looks sane, and the best that can be done to mitigate the problem at present. 18:07:42 Do you have a deterministic method / piece of code that can re-find these proxies, and would you be willing to do a semi-closed source release to those who you want to the sign the banlist ? 18:07:43 rbrunner: Should I put that higher in the post? 18:08:16 jeffro256: That is a question for boog900 18:08:18 Seems like a good finishing sentence to me. That's a good spot IMHO 18:08:52 Yes I'll PM you 18:08:55 I understand that the methodology should remain semi-private since we don't want the adversary to adapt their methods, but I personally would like to know why I would be signing a banlist, even if I don't release the details to the public 18:09:13 Makes sense. 18:10:32 Speaking just for myself I don't personally want to take an explicit role in advocating for banning specific IP's. The approach seems reasonable generally to me though 18:11:06 I also haven't gotten the chance to dig deeper into @boog900 's findings, but it passes my initial smell test. Would encourage anyone who wants to dig deeper / sign off to PM @boog900 as well 18:13:09 now is the time to give each people a different method so that if one is patched we know who is the maul 18:13:13 One legit use case for a proxy node tho that jberman brought up was running a node at home but not revealing to the world where your home is 18:14:10 These nodes do not proxy all messages they handle handshakes themselves 18:14:29 Well, we don't have something against the occassional single proxy node, right? 18:14:36 Just to whole packs of them ... 18:14:40 Or intercept and insert their own data 18:16:19 This may be related to the video I reviewed on MoneroTopia 18:16:40 The Chainalysis one? It might 18:17:05 Yes that one 18:18:24 The idea there was to trick unsuspecting wallets to connect to the spy none in order to collect the wallet IPs 18:18:37 Node 18:20:07 Boog900's findings are more about the P2P network privacy. IIRC the Chainalysis representative complained that Dandelion++ made their job harder. Maybe they are trying to have a strategy to weaken D++ 18:21:16 Yes I understand, weaken D++ by collecting wallet IPs 18:22:26 My concern here is that a BS company does not change to use proxy IPs to do this 18:22:33 they can definitely weaken the effects of D++ by running loads of spy nodes, can't they? 18:22:43 Have to use 18:22:45 IIRC Chainanal was running malicious nodes hosted at community trusted domains that had prior expired and Chainanl picked up the domains. So it wasn't that they were running proxies on tons of IP's, rather that they controlled community trusted domains 18:22:48 chaser: Yes 18:23:56 Whereas the discussion here is relevant to running tons of spy proxy nodes across many different IP's, which Chainanal may also be doing, but it's not known who's doing that AFAIK 18:24:04 Yes they can., but detecting proxy nodes does not address this 18:24:42 chaser: The effect of the suspected spy nodes on the privacy provided by D++ is estimated here under "Empirical privacy impact": https://github.com/monero-project/research-lab/issues/126#issuecomment-2460261864 18:26:35 Making sure I remember this correctly: if you use your own node for transactions, this makes the Chainalysis attack not an issue for you, correct? 18:27:43 preland: The _remote node_ attack would not affect you, but your own node could still be connecting to peer spy nodes, which weakens D++. To avoid connecting to them, run the ban list. 18:27:57 ^+1 18:28:07 tx-proxy 18:28:17 I think Chainalysis were black-holing txs, if you look at the video by the IP addresses in observations there are small symbols, sadly he never hovered over any long enough for the help text to pop up with a description of what they mean, at least I didn't see it. 18:28:17 The 4 symbols I have seen are: a speaker, cross, 3 lines, question mark. 18:28:19 The only one I have a little bit of confidence on is the 3 lines, I think it means stem, like the tx was sent in a stem message. At 32:00 if you look at all outputs with IPs with that symbol the time till it was seen a second time is extremely high, it makes me think these txs were blackholed. 18:28:21 I believe the real issue is the behavior of the proxy node as opposed to the node being a peproxy 18:28:28 anonymous-inbound 18:29:51 +1 to @ofrnxmr 's point also. Using tor/i2p via tx-proxy is another way to avoid a spy proxy node from correlating your node's IP to your txs 18:31:06 NAT nodes are easier to blackhole, because you cant connect to them 🙃. Using anonymous-inbound and tx-proxy throw in variables that make it a guessing game 18:31:08 Yes, but there is an unresolved issue with the real IP address of a Monero node onion service being discovered. I can't link to it right now since moneroresaerch.info is giving an error 😬 18:31:30 So we have nodes that accept wallets. Connections but do not open outbound connections 18:31:56 When you relay via tx-proxy, it doesnt share your onion address 18:32:32 So even if you associate me ip to onion (my onion starts with ofrnxmr btw), you dont know my tx-proxy's txes 18:33:03 your node will insert it at the end of a peer list message IIRC 18:33:29 At the end ? 💀 18:34:31 Here it is: Shi et al. (2024) "Deanonymizing Transactions Originating from Monero Tor Hidden Service Nodes" https://dl.acm.org/doi/abs/10.1145/3589335.3651487 18:34:42 Can we focus on the node behaviour itself as opposed to whether it is behind a proxy? 18:35:05 Sounds like unintended behaviors. Whats the point of hiding the addr$ss via "unknown tor host", if the host is known via being the last onion on the peerlist 🥲 18:35:47 Artic, are you asking about the spy node behavior? 18:35:57 Yea 18:35:58 yikes, I really botched that then. 18:36:01 Yea 18:36:12 Yes 18:36:55 knowing the hidden service doesn’t automatically get you the IP address, at least, but some Tor node knows the correlation 18:36:57 ArticMine: Ideally, a Monero node should be able to determine if its peer is a single node or if it is part of a network of proxied nodes. The network of proxied nodes means that the spy node operator pays a lower cost in storage, RAM, and CPU. 18:37:39 this should’ve been an a GI Issue; I don’t recall seeing it before 18:38:30 another point - if you use —tx-proxy without —anonmous-inbound you get the privacy back, but aren’t helping the network of relays 18:38:50 There's a paper about how to check if something is a real single node or not, but requires a lot of protocol changes, found by boog900 : JHeo, Ramachandran, and Jurdak (2023) "PPoS : Practical Proof of Storage for Blockchain Full Nodes" https://ieeexplore.ieee.org/document/10174897 18:40:15 we can randomize the list, but there’s a timestamp too that could be problematic 18:40:31 Do we want to discuss `MAX_INPUTS`/`MAX_OUTPUTS` again or do we want to end the meeting here and postpone that discussion until we get more CPU benchmarks? 18:40:53 The latter IMO 18:41:07 Yes but the real issue here is the spying. I just don't see the deterrence in just detecting proxies 18:41:51 I mean the BS company will just pass the additional cost to government 18:42:26 if you can detect proxies, then you can ban them from D++ stems 18:42:29 AFAIK, the only deterrence that D++ has is to make it economically costly for an adversary to spy. It's a permissionless network after all. 18:43:18 This is the end of the meeting. We can continue discussing P2P network privacy, of course :) 18:43:32 mitigating that would probably require a different network-layer mixing method 18:44:23 and potentially non-trivial PoW for participation 18:44:49 @vtnerd here's the relevant code for sending a node's IP to outgoing connections at the end of the peerlist: https://github.com/monero-project/monero/blob/893916ad091a92e765ce3241b94e706ad012b62a/src/p2p/net_node.inl#L2475-L2501 18:45:19 chaser: I would agree. The Dandelion++ protocol limits the spying effectiveness to roughly the theoretical minimum. The theoretical minimum is a function of the share of spy nodes on the network. 18:45:21 Thanks everyone ! 18:45:23 @moneromoo brought up this exact issue on my PR and I completely forgot to look into it more :/ https://github.com/monero-project/monero/pull/8324#issuecomment-1125108872 18:46:43 I summarize the D++ protocol's resistance to spy nodes in the GitHub issue I linked above. 18:47:19 https://github.com/monero-project/research-lab/issues/126#issuecomment-2460261864 18:49:10 If an adversary has enough malicious nodes, he/she can also try to launch eclipse and network partitioning attacks, which are distinct from spying. 18:50:37 @jberman yes, I know what needs to be fixed, just a little disappointed I missed this first time 18:51:26 he/she? Artificial intelligence don't have gender 18:51:42 oh wow, just read that moo comment. a shame this wasn’t fixed earlier 18:55:10 For any spy's that kept logs: i was joking. my onion doesnt start with "ofrnxmr" 🫠 18:56:17 From issue 126 the outbound connection behavior combined with accepting wallet connections are characteristic of the malicious nodes 18:58:47 I mean the proxy approach is reasonable as long as it does not inadvertently target legitimate proxy use for privacy purposes 19:06:00 In any case a back and forth between the community and the adversary on this could easily set up the adversary for a significant legal failure here in Canada over privacy law violations 20:22:26 https://moneroresearch.info/ is back up. It was the runaway mysql log issue again. 20:24:49 <0xfffc:monero.social> Apologies everyone. I totally forgot/missed this meeting. 20:24:49 <0xfffc:monero.social> Anyway, my update was mostly working on general wallet-rpc issues. #9601 and other small fixes. ( although small, but should introduce good speed up in many cases ) 20:50:56 <0xfffc:monero.social> I read the discussion. I have a question about blackhole nodes. What is the wallet response? I am a wallet. I send a transaction. My transaction gets blackholed on its way ( and never gets to fluff ). What do I do? wait and resend to same node? 20:50:57 <0xfffc:monero.social> Because IIUC, blackholing is going to introduce another security issue. If I have 20% of nodes as spy node, I set the rule to blackhole any transaction unless you get it from the wallet. Then my surveillance capability is going to get a boost. 20:50:59 <0xfffc:monero.social> Scenario 1: 20:51:01 <0xfffc:monero.social> Wallet generates tx -> node 1 -(stem)- > node 2 (blackhole). 20:51:03 <0xfffc:monero.social> Wallet waits x seconds. 20:51:05 <0xfffc:monero.social> Wallet generates tx again, changes the node -> node 2 ( now this node has more information ), and passes the transaction. 20:53:13 In scenario 1, the honest `node 1` will broadcast the tx in fluff mode after the embargo timeout fires, so it still gets spread through the network without the wallet user doing anything. 20:54:19 <0xfffc:monero.social> oh thanks. now it made sense. I forgot that all the nodes (on stem path) do the fluff after few seconds. So not big of a deal. 20:54:46 Still, IMHO, the black-holing node 2 gets some info from this. Because ordinarily node 2 doesn't know that the immediately preceding node in the stem was the actual origin. 20:55:57 But if node 2 black-holes the tx, then they can run a statistical model about how many nodes may have participated in the stem phase (because with more nodes participating in the stem phase, the first timeout will be reached sooner). 20:55:58 <0xfffc:monero.social> Yes. it basically breaks the very purpose of stem. But still not as bad as I thought for a moment. 20:57:01 <0xfffc:monero.social> The interesting case is when you have X % of nodes on the network. ( Let's say 30% of the nodes on the network are spy node and doing blackholing. That is the interesting case to think about ). 20:58:57 <0xfffc:monero.social> For example. Let's think my scenario 1. If node 2 is blackholing. and after embargo timeout node 1 will fluff. Then considering you are running 30% of the nodes on the network. There is chance you know which nodes that tx is originated from. 21:33:26