<r​ucknium:monero.social> MRL meeting in this room in two hours.

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

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

<v​tnerd:monero.social> Hi

<o​ne-horse-wagon:monero.social> Hello.

<b​oog900:monero.social> Hi

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

Hello

<k​ayabanerve:matrix.org> 👋

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

<k​ayabanerve:matrix.org> Nothing of note on my end.

<v​tnerd:monero.social> Hackerone issues

<j​effro256:monero.social> Hpwdy

<r​ucknium:monero.social> me: I updated moneroresearch.info to use the latest version of WIKINDX. The Quick Search is improved. Instead of "OR" it now uses "AND" between words. So you get much more relevant results with multiple keyword searches. I will be on MoneroTalk at 22:30 UTC today: xcancel.com/MoneroTalk/status/1830994649730699491 , using a hired voice. I have been working on final <clipped mes

<r​ucknium:monero.social> results for combining black marble attacks with the Dulmage-Mendelsohn decomposition.

<j​effro256:monero.social> me: collecting Carrot audit proposals, hopefully should be done by next MLR meeting

<j​berman:monero.social> continuing fcmp++, working on trimming the tree on reorg/pop blocks

<r​ucknium:monero.social> 3) Stress testing monerod. monero-project/monero #9348

<r​ucknium:monero.social> I have merged 0xfffc 's PR for dynamic block size sync: spackle-xmr/monero #30

<r​ucknium:monero.social> I have started to spam stressnet again.

<j​effro256:monero.social> How's it going so far?

<r​ucknium:monero.social> plowsof wrote a bounty to enable fast sync for testnet (this would enable it on stressnet since stressnet is a testnet fork): bounties.monero.social/posts/149/0-…add-fast-blockchain-sync-to-testnet

<r​ucknium:monero.social> Currently the bounty is at 0.45 XMR

<0​xfffc:monero.social> Hi everyone. Apologies for being absent. Right now, I am working on an issue on stressnet side. But I will keep an eye on this chat too.

<0​xfffc:monero.social> My work past week was mostly on finishing dynamic bss and dynamic span. (L

<r​ucknium:monero.social> jeffro256: Initial testing of dynamic block size sync has been good. But we haven't subjected it to big blocks yet.

<r​ucknium:monero.social> Reminder that this stressnet will stop being "supported" in about a month. So it is a good time to test your code that fixes bottlenecks.

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. getmonero.org/2024/04/27/fcmps.html

<r​ucknium:monero.social> kayabanerve: Do you have an update on the potential Veridise followup work?

<k​ayabanerve:matrix.org> I believe we're planning to get on a call to organize within the next week or so.

<r​ucknium:monero.social> Anything more on FCMP++?

<j​berman:monero.social> not exactly mrl, but @tobtoht proposed considering dropping windows 32-bit support since windows 11 requires 64-bit (only >18 year old CPU's running windows 10 would be affected), and the 32-bit windows build will be a bit of a pain to get working. Seems reasonable to me but worth bringing up to a wider group

<k​ayabanerve:matrix.org> the devs yearn for monero-dev meetings

shrug :)

<r​ucknium:monero.social> kayabanerve: Yeah lol

<r​ucknium:monero.social> 5) Change how transactions are broadcasted to significantly reduce P2P bandwidth usage. monero-project/monero #9334

<r​ucknium:monero.social> vtnerd: Do you have an opinion about changing the fluff-phase tx queue timer to exponential distribution instead of Poisson?

<k​ayabanerve:matrix.org> I see we're moving on but I'll note I support monero-dev meetings (distinct from NWLB) and have no objections to dropping first-party support from problematic archaic targets.

<v​tnerd:monero.social> It needs to be exponential, I don't have any other comments than that really

<j​effro256:monero.social> I'd also tentatively say I support dropping official support for 32-bit windows unless it gets brought to our attention that more than a handful of people are actually using it

<r​ucknium:monero.social> Maybe we are moving toward loose consensus to change it from Poisson to exponential. It could be a PR and discussed further in the PR

<j​effro256:monero.social> I'd say we should converge on whatever the reviewed literature says , which is exponential , no?

<v​tnerd:monero.social> There is a pr

<r​ucknium:monero.social> The Dandelion++ paper seemed to assume that the fluff phase has exponential timers.

<r​ucknium:monero.social> I thought the PR only affected the embargo timeout?

<v​tnerd:monero.social> monero-project/monero #9295

<v​tnerd:monero.social> Oh right, I thought I changed both in that pr

<r​ucknium:monero.social> Here's what I said about the D++ paper: monero-project/monero #9295#issuecomment-2260998091

<v​tnerd:monero.social> I'll just update that pr then

<r​ucknium:monero.social> > I have been looking at whether the fluff-phase timer should also be changed from Poisson to exponential. The Dandelion++ paper doesn't explicitly say that the fluff timers should be exponential, but it strongly hints that way IMHO. Algorithm 5 "Dandelion++ Spreading at node v" in Fanti et al. (2018) ends with Diffusion(X ,v, H). The paper says "Bitcoin Core, the most popular Bit<clipped mes

<r​ucknium:monero.social> coin implementation, adopted a protocol called diffusion, where each node spreads transactions with independent, exponential delays to its neighbors on the P2P graph." Fanti & Viswanath have an earlier paper about the privacy properties of bitcoin's transaction broadcast system. It describes diffusion: "In diffusion spreading, each source or relay node transmits the message to eac<clipped mes

<r​ucknium:monero.social> h of its uninfected neighbors with an independent, exponential delay of rate λ. We assume a continuous-time system, in which a node starts the exponential clocks as soon as it receives (or creates) a message."

<o​ne-horse-wagon:monero.social> It is estimated that as of 2024, only 4.3% of Windows users are running a 32 bit version and that number is shrinking every year.

<r​ucknium:monero.social> IIRC in PR #9295, the function named "exponential" takes the floor of the drawn values, which actually creates a geometric distribution. Probably there should be a true exponential distribution and the exp-turned-geometric distribution can be named something special for use when a discrete number is needed.

<r​ucknium:monero.social> Do we want to discuss the ten block lock now? Put it on next agenda's meeting? Neither?

<r​ucknium:monero.social> Always a fun one

<r​ucknium:monero.social> Aaron Feickert and isthmus wrote a report on it: github.com/AaronFeickert/pup-monero-lock/releases/tag/final

<r​ucknium:monero.social> AFAIK the new contributions are in Section 4 with the FCMP++ discussion

<k​ayabanerve:matrix.org> I've prior stated my disagreement with the premise, and I believe there was a general agreement we needed a proper quantitative analysis of the odds of various reorg depths/natural likelihood/etc.

<r​ucknium:monero.social> A quantitative analysis is on my CCS research agenda.

<r​ucknium:monero.social> Do we think that block propagation will change significantly when FCMP++ is activated on mainnet?

<b​oog900:monero.social> We use fluffy blocks, so probably not

<r​ucknium:monero.social> Does it make sense to investigate changing it with the FCMP++ hard fork, or should we wait until we see the network behavior, then possibly change it in a future hard fork?

Did stressnet unearth any block propagation problems as blocks became bigger? I don't think so, but I am not sure

<k​ayabanerve:matrix.org> I've called for the FCMP++ hardfork being monolithic its set of changes.

<o​ne-horse-wagon:monero.social> There's going to be a huge change with FCMP++ and I would suggest waiting until everything is settled in before piling on more changes.

<r​ucknium:monero.social> We figured out that some nodes rejected valid blocks since they didn't have the txs.

<k​ayabanerve:matrix.org> I want to deprecate/prune RPCs, ship Carrot, etc, because if we're already forcing users to update for XYZ, adding A isn't much more (but forcing them to change twice, six months apart, is).

<r​ucknium:monero.social> Then the nodes marked the blocks as permanently invalid. jeffro256 made a PR to stop the permanent invalidity of the blocks

<k​ayabanerve:matrix.org> So if we're changing the n-block lock, I'd call for it at the hard fork.

<k​ayabanerve:matrix.org> I'll also reiterate the n-block lock should be the depth reorganizations are infeasible, not unlikely, but I've rung that bell more than enough.

<j​effro256:monero.social> I agree with one-horse-wagon: we should discuss after smoothing out details of the FCMP upgrade. Unlike kayaba, I think it can be reduced now with FCMPs without such a permanate loss to privacy under certain circumstances which made the 10 block lock privacy impact much more relevant, but we definitely shouldnt try from the get go

The pessimist in me whispers that we will need a second hardfork to micro-adjust some things anyway that we did not yet get fully right with the original FCMP++ introduction ...

<r​ucknium:monero.social> kayabanerve: The only way to do that is a rolling checkpoint like BCH has

<r​ucknium:monero.social> If you do that, you add a liveness assumption to the network

<r​ucknium:monero.social> Or to nodes I mean

<k​ayabanerve:matrix.org> jeffro256: The private option is the depth reorgs are infeasible. To suggest we can reduce it is to disagree with my premise or to say reorgs aren't feasibly by an adversary at 9 blocks.

<r​ucknium:monero.social> Since a node that has been shut down for a while can wake up to two blockchains because it never saw the Nth checkpoint block

<k​ayabanerve:matrix.org> It's not about if a reorg actually happens. It's about the tree root selection being a fingerprint.

<k​ayabanerve:matrix.org> Rucknium: If we assume you're not eclipsed, and no adversary has 51%, then the probability of a n-block reorg goes down with each additional block.

<k​ayabanerve:matrix.org> An adversary with just 49% can only pull off any reorg with random chance.

<k​ayabanerve:matrix.org> I'm calling for the n-block lock to have n be the soft finality depth, where we define soft finality as an adversary having infeasible likelihood of performing a reorg. This is generally done in practice with the hash power percentage of the top mining pool(s).

<r​ucknium:monero.social> Allowing nodes to leave and re-enter the network was part of the bitcoin design in the white paper

<k​ayabanerve:matrix.org> I'm not claiming it's hard finality, even though that can be a discussion for another day. I'm saying PoW coins for years have evaluated reorg risks for minority adversaries and recommended amounts of confirmations accordingly.

<r​ucknium:monero.social> What's your infeasibility probability?

<k​ayabanerve:matrix.org> (and also higher confirmations for situations of higher criticality, I'm not blind to that)

<r​ucknium:monero.social> Those have usually been heuristics. Satoshi had the wrong minority attack formula in the white paper anyway

<r​ucknium:monero.social> Recommendations are just risk management. Everyone has a different risk preference

<k​ayabanerve:matrix.org> If you want to say they're heuristics and have me call them such, I'm fine doing so.

<k​ayabanerve:matrix.org> I'd call for at least 1% odds by the largest mining pool.

<k​ayabanerve:matrix.org> Specifically for the n-block lock.

<r​ucknium:monero.social> Over what period of time? A year? And what is the resource of the adversary? Can it keep trying every block?

<k​ayabanerve:matrix.org> I guess we'd have to define how long until we expect users to realize they've been so repurposed. I am scared to ask what the confirmation count needs to be if we say over a day though.

<k​ayabanerve:matrix.org> I said > largest mining pool

<k​ayabanerve:matrix.org> And if they have a finite amount of hash power for attempts, can't they only start an attempt occasionally? Having attempts in parallel would mean they have more hash power than assumed.

<k​ayabanerve:matrix.org> Or we simplify to a singular attempt. I don't have all the answers here and I'm not trying to claim I do. I'm solely saying that even if a non-trivial adversary attempts a reorg, it should be agreed sufficiently unlikely at some confirmation depth. I believe that depth should be lock depth.

<k​ayabanerve:matrix.org> (not just unlikely naturally, yet unlikely by an active attacker so infeasible)

<k​ayabanerve:matrix.org> If we want to reduce the lock depth, I'd call to reduce the depth at which we consider reorgs infeasible. I wouldn't call to alternatively define the lock depth.

<r​ucknium:monero.social> I have a question about this sentence in the paper: "[In Zcash] There are few network consensus rules governing the age of this anchor; it must be at least one and at most 100 blocks old."

<k​ayabanerve:matrix.org> If I can pay 10k over a year to invalidate TXs once a month, some wallets will default to more stable tree roots and we will end up with fingerprints though.

<r​ucknium:monero.social> Would FCMP++ have a maximum age of an anchor? If it doesn't any tx that stays in the txpool longer than the max anchor depth would be permanently invalid, right?

<k​ayabanerve:matrix.org> No, doing so would invalidate TXs as you say.

<r​ucknium:monero.social> Unless there are objections I will put the 10 block lock on the agenda for next meeting. It has been about a year since it was on the agenda. Right on time for its annual appearance.

<r​ucknium:monero.social> We can end the meeting here.

I don't think Zcash has _any_ consensus rules regarding the anchor depth.

The 100 blocks thing is just a limit on what parameters the wallet uses

It defaults to 3 but allows the user to specify 1 to 100

And of course it would be trivial to fork the wallet and change that range to 200 or 1000 or whatever

<r​ucknium:monero.social> Thanks, isthmus

Having had experience in the past with network upgrades, the ecosystem will not be able to cope with successive network upgrqdes in a short time-spqn

Even when Monero was much smaller it was already difficult to get everyone to upgrade properly and on time