02:13:59 I will not be present at tomorrow's MRL meeting due to Monerotopia-related reasons. If anyone has something they want to raise with me before next week, please DM me. 02:14:11 (or in-person at Monerotopia) 02:26:40 Same 15:16:27 MRL meeting in this room in one hour and forty-five minutes. 17:00:39 Meeting time! https://github.com/monero-project/meta/issues/1109 17:00:44 1) Greetings 17:01:01 Hello 17:01:08 hello 17:01:14 *waves* 17:02:23 Hi 17:03:36 2) Updates. What is everyone working on? 17:04:39 <0​xfffc:monero.social> hi everyone, not gonna able to attend the meeting. worked on few minor tasks, did few reviews. the main thing I am working right now (as I am typing this ), is debugging #9362 17:05:18 me: I worked on some spy node analysis. I finished my presentation for the Monerotopia conference: "Hard Data on Banking the Unbanked through Cryptocurrency". It is scheduled to be at 17:45 UTC on Friday, November 15: https://monerotopia.com/schedule/ 17:06:26 At the presentation I will reveal a possibly first-ever estimate of the total value of goods and services purchased online using cryptocurrency in the EU in 2022, based on survey data collected by the EU central bank :D 17:07:33 Sounds interesting 17:08:19 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS https://gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 https://github.com/monero-project/research-lab/issues/100#issuecomment-2433524326 17:08:38 kayabaNerve said he won't be here at the meeting. I don't have anything to add on this right now. Anyone else? 17:09:44 me: shared a ccs update, main highlight being I implemented building the fcmp++ curve tree locally in wallet2, it makes overall sync 2-2.5x slower (initial impl was 5-6x slower), and has room for improvement still: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/491#note_27183 17:10:59 4) Making transaction weight a function of number of inputs, outputs, and `tx_extra` length instead of number of bytes. 17:11:40 kayabaNerve asked this to be on the agenda, but he's not here right now 🥹 17:13:27 But this is something I've suggested. It is really hard to get alternative implementations of Monero wallets to match wallet2's fee behavior. Fees being based on bytes makes it hard because Monero txs can be a little different in size even if they "do" the exact same thing, i.e. spend the same number of inputs to the same number of outputs. 17:13:33 That reduces tx uniformity. 17:15:02 The tx weight computation is already partway to this proposal because there is a weight clawback based on the number of outputs. The verification time of bulletproof outputs is nonlinear in the number of outputs. That's why there is the clawback. 17:15:27 Hmmm, I wonder whether you can "blow up" transactions that way, with extra-heavy inputs and outputs and proofs and such, and then spam for little XMR 17:15:41 Yes I wonder that exact thing, too 17:15:55 Which is why the cryptographers would have to comment on it 17:16:34 Sort of like the BTC Ordinals situation. 17:17:14 My gut feeling is that a switch to that would need a very, very careful examination of this danger 17:17:49 Also whether our current serialization format really does not allow to put in bytes somewhere that do not disturb interpreting the data but make everything bigger 17:17:58 Yes, or just a safety limit "If tx weight goes above Z limit, then the tx pays by bytes" 17:18:12 Apart of course from the already mentioned cryptographic questions 17:20:02 Couldn't we quantize fees a bit more, so the occasional few bytes more or less of alternative implementations wouldn't matter that much? 17:21:14 like rounding within a certain range? 17:21:32 quantizing more was essentially a core idea behind koe's discrete fee selection 17:21:35 I think a side effect of the fee discretization proposal is that txs that an an "unlucky" fee/byte would stay at the back of the confirmation line when the txpool is congested 17:22:13 Right, there was something in koe's proposal 17:23:41 Is that the same however like I probably have in mind? You pay fees for blocks of, say, 50 bytes, instead of single bytes? 17:23:45 weighting by num inputs, outputs, and tx_extra length instead of bytes I think makes sense in practice to more accurately weigh the various components of a tx, though I'm not sure if it actually would make the problem of matching wallet2 simpler, since it introduces more rules an implementer has to figure out and match perfectly beyond just the bp clawback 17:25:26 Right now there is no mathematical function that takes as argument a Monero tx and returns the wallet2 fee for it. AFAIK. 17:25:45 With this proposal, there would be a function 17:27:06 And AFAIK, the only person who can properly implement the fees is jberman :D 17:28:00 I asked Exodus Wallet to contact jberman to get their fees exactly right, but they didn't. I'm not 100% sure that they have it exactly right, but they have it approximately right at least. 17:28:22 I can only check the approximation because there is no such mathematical function, like I said. 17:29:21 There is calculate_fee in wallet2 but fair there are also surrounding pieces to that function. Regardless, I think it makes sense to implement a rule to weigh by num inputs, outputs, and tx_extra size because of the disparate impact the number of the various components have on syncing the chain beyond just their number of bytes 17:30:02 And I also think the direction of discretizing fees is a reasonable course of action toward reducing fingerprintability 17:30:35 Is all the really complicated stuff like long-time median block size, penalties and such only in the calculation of the base fee per byte? 17:30:46 Yeah, the BP clawback was a step toward that. I don't know the latest numbers of FCMP++, but AFAIK, the veification time impact of FCMP++ will be larger than the tx bytes impact, compared to the status quo. 17:30:58 @rbrunner7 yep, and that's fed to the wallet by the daemon 17:31:39 And still everything in the wallet is terribly difficult? :) 17:31:55 I wonder a bit right now, but of course I don't really doubt 17:32:19 You would think tx size in byte times fee per byte, done. 17:32:22 It's a little tricky getting priorities right and using the exact weight in the correct spot correctly 17:32:33 rbrunner: AFAIK, only the fourth (maximum) tier of the suggested fee/byte in monerod's get_fee_estimate is affected by the median block size. With the other tiers, basically wallets are expected to move up a tier in dicrete steps instead of actually increasing the tier. 17:33:00 And also using the correct fee mask and stuff. There's definitely a lot of room for error with the current flow 17:33:27 But the fourth tier is based on a _continuous_ computation of the median block size, so that would have to be analyzed and changed in a reasonable way if discretized fees were implemented. 17:33:37 Ok, it wasn't improbable from the start that something Monero related would be simple :) 17:36:28 We have p2p proxy nodes to discuss. We can discuss the fee issue more next time. 17:36:42 5) Discussion: preventing P2P proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:38:02 I added a little function to my R package https://github.com/Rucknium/xmrpeers called `peers.ip.collect()` that shows you when your local node is connected to suspected spy nodes, plus when the "subnet saturation" of those peers is occurring. Obviously, you have to not have the banlist enabled to see when you are connected to those suspicious nodes. 17:38:13 damn, missed the meeting again, sorry :/ 17:39:10 So people can check for themselves how many of their outbound peers are the suspected spy nodes, plus the subnet saturation evidence. It takes about a day of running it to see the subnet saturation clearly. 17:40:34 I posted in #monero-research-lounge:monero.social about: LionLink Networks created a press release about the BTC spy node accusations: https://linkinglion.net/ 17:40:50 > Ashburn, VA – March 26, 2024 – LionLink Networks ("LionLink") is aware of recent articles published alleging illicit behavior originating from IP addresses advertised by LionLink Networks and describing an entity known as LinkingLion. We believe the first report on this behavior to be written by the Bitcoin Developer 0xB10C....LionLink Networks categorically denies any invol vement in the activities described by the author known as 0xB10C. 17:41:27 The suspected Monero spy/proxy nodes are managed by LionLink, too. 17:42:25 Just define "illicit" the right way, and everything is in order 17:42:35 There was disagreement last meeting about having an opt-out setting in monerod to avoid establishing outbound connections to nodes on the suspected spy list. 17:43:59 rbrunner: Well, it is honest monerod nodes that are initiating all the connections to those IP addresses, so where is the grounds to complain? :) 17:44:24 Lol, right 17:45:42 I think with the evidence we have what they claim is only a pretty unimportant side-show 17:46:25 response by 0xB10C: https://b10c.me/blog/013-one-year-update-on-linkinglion/ 17:46:27 Maybe a plan: Short-term: Post on Monero communication channels a suggestion to run the banlist, Medium-term: Something like ASmap: https://github.com/monero-project/monero/pull/7935, Long-term: R&D on a more universal solution like proof-of-storage, but without big downsides. 17:47:27 I have done a few preliminary simulations about how ASmap would affect network connections. 17:48:34 By the way, there were about 800 unique ASNs in my node log data from April/May 2024. For "reachable" nodes, i.e. nodes that accept incoming conenctions. 17:49:26 @selsta does core operate the DNS blocklist (blocklist.moneropulse.* domains)? 17:50:07 yes, they pay for it 17:50:10 Really preliminary simulation results: Assume on average that reachable nodes have 120 incoming connections on average. If nodes on the network refuse to connect to a node on an ASN they are already connected to, then: Mean number of incoming txs for nodes on ASNs: 17:51:05 LionLink: 40, Hetzner: 95, Fifty rarest ASNs: 160 17:51:28 As expected, if you are on a common ASN, you get fewer incoming connections 17:51:46 On a short-term plan, I think it would also make sense for @boog900 to share the underlying logic/approach for how the IP's are determined to be proxies with someone from core, and if deemed correct, for core to add the IP's to the DNS blocklist 17:52:25 the current issue is there is a DNS TXT record size limit for IPs 17:52:35 so we need to fix that first and put out an update 17:52:56 either by switching to a .txt fetch or by using multiple DNS endpoints 17:53:55 ah, just curious what's the size limit / shortfall right now (how far past the size limit would the entire list push it)? 17:54:07 it's full currently 17:54:16 ok 17:54:26 roug estimate 3x current list 17:54:29 rough 17:54:53 well, short-to-medium plan then to include as part of the DNS blocklist flow 17:55:33 I have told sech1 & Rucknium (although I wouldn't expect them to publicly certify the method). I can PM you? and any other dev who wants to know is free to PM me. 17:58:20 There is Boog900's method and there is a method of counting up subnet saturation that can be done by anyone with a node. Of course, that only works on the set of IP ranges (about six) that the adversary has full control of. 18:00:02 Maybe I should have caught this when I analyzed the tx relay data for my black marble paper 😶. But I had already done a lot of different types of analysis with that, so I had to draw the line somewhere. 18:00:21 More on p2p spy/proxy nodes for now? 18:03:47 question for @boog900 , hypothetically if you were to publicly share your code that identifies a proxy node, is your concern that they would find another hole / method of running a proxy that's harder to detect? 18:05:22 Yes the issue is easy for them to fix (I think) 18:09:05 Reasonable 18:09:17 6) Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future `unlock_time` https://github.com/monero-project/research-lab/issues/125 18:09:19 Just checking. IIRC, chaser wanted to follow up on this by continuing the conversation in the GitHub issue. If there is nothing more to say here, we can end the meeting. 18:10:09 yes, I couldn't get to to that in the past week, so will do so after the meeting. 18:10:45 Meeting is over. Thanks everyone. 18:11:05 Delicious meeting as always 18:11:12 thank you all! 22:55:16 Veridise completed their task to provide the log deriv spec and expand the security proofs re: negative coefficients. Their report is available here: 22:55:29 https://matrix.monero.social/_matrix/media/v1/download/monero.social/AGBzpCbNZkdtnRXdtJOVmyvF 22:56:59 I spoke with kayabanerve about the last bit ("An Implicit Assumption and a Potential Vulnerability"), and he says it's not an issue in practice, but it's something to keep in mind for the implementation 23:02:16 I spoke with kayabanerve about the last bit ("An Implicit Assumption and a Potential Vulnerability"), and they say it's not an issue in practice, but it's something to keep in mind for the implementation 23:04:03 It was a potential issue. It's now confirmed to not be a potential issue. The last line suggests something to watch out for but it doesn't occur in our case.