<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> (or in-person at Monerotopia)

<j​effro256:monero.social> Same

<r​ucknium:monero.social> MRL meeting in this room in one hour and forty-five minutes.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1109

<r​ucknium:monero.social> 1) Greetings

Hello

<c​haser:monero.social> hello

<j​berman:monero.social> *waves*

<b​oog900:monero.social> Hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<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

<r​ucknium:monero.social> 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: monerotopia.com/schedule

<r​ucknium:monero.social> 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

Sounds interesting

<r​ucknium:monero.social> 3) FCMP++ tx size and compute cost and MAX_INPUTS/MAX_OUTPUTS gist.github.com/kayabaNerve/c42aeae1ae9434f2678943c3b8da7898 monero-project/research-lab #100#issuecomment-2433524326

<r​ucknium:monero.social> kayabaNerve said he won't be here at the meeting. I don't have anything to add on this right now. Anyone else?

<j​berman:monero.social> 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: repo.getmonero.org/monero-project/c…als/-/merge_requests/491#note_27183

<r​ucknium:monero.social> 4) Making transaction weight a function of number of inputs, outputs, and `tx_extra` length instead of number of bytes.

<r​ucknium:monero.social> kayabaNerve asked this to be on the agenda, but he's not here right now 🥹

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> That reduces tx uniformity.

<r​ucknium:monero.social> 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.

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

<r​ucknium:monero.social> Yes I wonder that exact thing, too

<r​ucknium:monero.social> Which is why the cryptographers would have to comment on it

<r​ucknium:monero.social> Sort of like the BTC Ordinals situation.

My gut feeling is that a switch to that would need a very, very careful examination of this danger

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

<r​ucknium:monero.social> Yes, or just a safety limit "If tx weight goes above Z limit, then the tx pays by bytes"

Apart of course from the already mentioned cryptographic questions

Couldn't we quantize fees a bit more, so the occasional few bytes more or less of alternative implementations wouldn't matter that much?

<c​haser:monero.social> like rounding within a certain range?

<j​berman:monero.social> quantizing more was essentially a core idea behind koe's discrete fee selection

<r​ucknium:monero.social> 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

Right, there was something in koe's proposal

Is that the same however like I probably have in mind? You pay fees for blocks of, say, 50 bytes, instead of single bytes?

<j​berman:monero.social> 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

<r​ucknium:monero.social> Right now there is no mathematical function that takes as argument a Monero tx and returns the wallet2 fee for it. AFAIK.

<r​ucknium:monero.social> With this proposal, there would be a function

<r​ucknium:monero.social> And AFAIK, the only person who can properly implement the fees is jberman :D

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I can only check the approximation because there is no such mathematical function, like I said.

<j​berman:monero.social> 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

<j​berman:monero.social> And I also think the direction of discretizing fees is a reasonable course of action toward reducing fingerprintability

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?

<r​ucknium:monero.social> 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.

<j​berman:monero.social> @rbrunner7 yep, and that's fed to the wallet by the daemon

And still everything in the wallet is terribly difficult? :)

I wonder a bit right now, but of course I don't really doubt

You would think tx size in byte times fee per byte, done.

<j​berman:monero.social> It's a little tricky getting priorities right and using the exact weight in the correct spot correctly

<r​ucknium:monero.social> 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.

<j​berman:monero.social> And also using the correct fee mask and stuff. There's definitely a lot of room for error with the current flow

<r​ucknium:monero.social> 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.

Ok, it wasn't improbable from the start that something Monero related would be simple :)

<r​ucknium:monero.social> We have p2p proxy nodes to discuss. We can discuss the fee issue more next time.

<r​ucknium:monero.social> 5) Discussion: preventing P2P proxy nodes. monero-project/research-lab #126

<r​ucknium:monero.social> I added a little function to my R package 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.

<v​tnerd:monero.social> damn, missed the meeting again, sorry :/

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I posted in #monero-research-lounge:monero.social about: LionLink Networks created a press release about the BTC spy node accusations: linkinglion.net

<r​ucknium:monero.social> > 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<clipped message

<r​ucknium:monero.social> vement in the activities described by the author known as 0xB10C.

<r​ucknium:monero.social> The suspected Monero spy/proxy nodes are managed by LionLink, too.

Just define "illicit" the right way, and everything is in order

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> rbrunner: Well, it is honest monerod nodes that are initiating all the connections to those IP addresses, so where is the grounds to complain? :)

Lol, right

I think with the evidence we have what they claim is only a pretty unimportant side-show

<j​berman:monero.social> response by 0xB10C: b10c.me/blog/013-one-year-update-on-linkinglion

<r​ucknium:monero.social> Maybe a plan: Short-term: Post on Monero communication channels a suggestion to run the banlist, Medium-term: Something like ASmap: monero-project/monero #7935, Long-term: R&D on a more universal solution like proof-of-storage, but without big downsides.

<r​ucknium:monero.social> I have done a few preliminary simulations about how ASmap would affect network connections.

<r​ucknium:monero.social> 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.

<j​berman:monero.social> @selsta does core operate the DNS blocklist (blocklist.moneropulse.* domains)?

yes, they pay for it

<r​ucknium:monero.social> 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:

<r​ucknium:monero.social> LionLink: 40, Hetzner: 95, Fifty rarest ASNs: 160

<r​ucknium:monero.social> As expected, if you are on a common ASN, you get fewer incoming connections

<j​berman:monero.social> 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

the current issue is there is a DNS TXT record size limit for IPs

so we need to fix that first and put out an update

either by switching to a .txt fetch or by using multiple DNS endpoints

<j​berman:monero.social> ah, just curious what's the size limit / shortfall right now (how far past the size limit would the entire list push it)?

it's full currently

<j​berman:monero.social> ok

roug estimate 3x current list

rough

<j​berman:monero.social> well, short-to-medium plan then to include as part of the DNS blocklist flow

<b​oog900:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> More on p2p spy/proxy nodes for now?

<j​berman:monero.social> 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?

<b​oog900:monero.social> Yes the issue is easy for them to fix (I think)

<j​berman:monero.social> Reasonable

<r​ucknium:monero.social> 6) Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future `unlock_time` monero-project/research-lab #125

<r​ucknium:monero.social> 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.

<c​haser:monero.social> yes, I couldn't get to to that in the past week, so will do so after the meeting.

<r​ucknium:monero.social> Meeting is over. Thanks everyone.

<s​yntheticbird:monero.social> Delicious meeting as always

<c​haser:monero.social> thank you all!

<s​gp_:monero.social> Veridise completed their task to provide the log deriv spec and expand the security proofs re: negative coefficients. Their report is available here:

<s​gp_:monero.social> matrix.monero.social/_matrix/media/…ero.social/AGBzpCbNZkdtnRXdtJOVmyvF

<s​gp_:monero.social> 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

<s​gp_:monero.social> 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

<k​ayabanerve:matrix.org> 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.