<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1393

<rucknium> 1. Greetings

Hi

<jberman> waves

<boog900> Hi

Hi

<jpk68:matrix.org> Hello

Hello

<vtnerd> Hi

<rucknium> 2. Updates. What is everyone working on?

<jeffro256> Howdy

<jberman> Beta stressnet debugging and working with @jeffro256 on resolving a beta net specific consensus issue

<jeffro256> ^ Same

<rucknium> me: Keeping stressnet stressed and monitored. Reviewing monerosim version 0.1.0

Still Polyseed in the Monero core software

<vtnerd> Me: updating various prs in monerod and lws. Moving back to looking at serialization limits and block size again shortly

<rucknium> 3. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686).

I have no updates, I'm still going with AC1024 as discussed in the last meeting. I can answer questions if needed.

<syntheticbird> Hi

<rucknium> I thought more about having an interactive address option. I think some merchants have problems with non-interactive txs. Or you could say that they are accustomed to the "pull" procedure of digital fiat payments, but cryptocurrency txs are "push". In previous research, I found this set of complaints about accepting cryptocurr [... too long, see mrelay.p2pool.observer/e/nIrw_oQLU1NOeXQ5 ]

<rucknium> Just some thoughts on UX. Or DX (developer experience) maybe.

<rucknium> ^ AFAIK, that site blocks Tor. And I cannot get archive.org to work right now :(

I think that interactive transactions could be an option, but not the only option. There are use cases for non-interactive transfers.

<rucknium> That reminds me that the Tor Project is running a cryptocurrency donation campaign for some internet privacy tools, including ones that are useful for research. I used OnionShare to collect user-submitted monerod logs, for example. The donation link appears in the blank page of the newest version of Tor Browser: internetfreedom.torproject.org

<rucknium> They accept XMR. Donations are being matched by Cake Wallet and Zcash Community Grants, plus some smaller donors.

<rucknium> tevador: I agree. Not the only option. I just wanted to say that an optional interactive protocol could have some UX/DX advantages.

Yes, I'm still planning to include an interactive protocol in the appendix of Jamtis.

<rucknium> 👍️

In response to spirobel, for point 2, you cannot just pretend that passively posted donation addresses don't exist. They do and we are not going to discontinue that use case.

This is a response to: libera.monerologs.net/monero-research-lab/20260519#c677589

<rucknium> Here was point 2: > <@spirobel:kernal.eu> @tevador: libera.monerologs.net/monero-research-lab/20260518#c677439

<rucknium> > 2.the one-to-many "donation address" use case:

<rucknium> > for this case the status quo is that we have systems like kuno, ccs, xmrchat.

<rucknium> > there is a need for the group to see a donation counter go up.[... more lines follow, see mrelay.p2pool.observer/e/rcqJ_4QLX0kyemE4 ]

<sgp_> I agree passive donation addresses are important

<rucknium> More discussion about PQ addressing?

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<rucknium> This week we got above the 5MB block size ceiling, as predicted. To 6MB blocks :)

<rucknium> stressnetnode1.redteam.cash

<rucknium> I also set up an alt chain visualizer because we needed it this week: stressnetconsensus1.redteam.cash stressnetconsensus2.redteam.cash

<rucknium> The same app code as for mainnet, adjusted a little for stressnet.

<jberman> Modifying the long term window in the dynamic scaling algo to kick in at 2 weeks instead of the current 100k block window unfortunately triggered a consensus issue that's leading to a number of syncing problems / chain splits. After some rounds trying to resolve the issue cleanly, it seems the most efficient option on the table to proceed is to essentially restart the stressnet

<jeffro256> After a lot of discussion with j-berman, I think that it is decided that we are going to rollback the stressnet for the beta v2.0 release due to the grossness of the consensus break. I am going to put out a PR which clears the blockchain if using a previous version of the beta stressnet, merge in the LTM window cache size fix, [... too long, see mrelay.p2pool.observer/e/jeyo_4QLam01TTAy ]

<rucknium> That sounds fine to me

So more or less one off-by-one bug, and stressnet broke down? Really shows the importance of code reviews :)

<spirobel:kernal.eu> tevador: just to clarify: i am not for discontinuing the use case. its just that if someone wants this functionality, they have to continue to scan the whole chain. also again: my suggestion is non interactive.

<jberman> It's worth noting this isn't an issue that would have affected mainnet, nor an issue with the updated scaling implementation proposed for FCMP++. It was strictly an issue with the stressnet specific change that would only affect stressnet to decrease the LT window so the chain could grow faster and get stressed faster on stressnet

Somehow missed that crucial detail, thanks for clarifying!

<spirobel:kernal.eu> regarding the PQ addressing small addition: it would be good to have it as a separate document from jamtis and it shouldnt take up most of the space regarding addressing design choices. the discussion should be more focused on ux problems in the real world and how we can reduce scan time. > <@rucknium> More discussion about PQ addressing?

<rucknium> The intended use of the new stressnet node is to just swap the old monerod out and start running the new one without deleting the old stressnet blockchain?

<jberman> Ya basically just a smooth path for people upgrading to not have to manage deleting their db manually

<rucknium> That would skip the long testnet sync from scratch :)

So basically one big reorg back to start of stressnet?

Dropping blocks like crazy :)

<jberman> Ah sorry, I misinterpreted your message. No, it would actually delete the old stressent db, so it would re-sync from scratch

<jberman> Unfortunately popping blocks needs an overhaul to be faster than just re-syncing

... on testnet

<jpk68:matrix.org> @spirobel:kernal.eu: Why shift the focus even further away from the non-interactive side of the protocol? This seems like a needlessly large UX change with no apparent benefit

<jeffro256> For reference , my stressnet node wasn't even able to pop 100 blocks per hour on my older desktop computer, so we figured it would be literally faster to just clear the entire DB and re-sync from scratch

<rucknium> pop blocks is very useful, but not when blocks are large.

<rucknium> IIRC, BTC doesn't have an easy-to-use pop_blocks command.

That somehow sounds strange. I remember dropping blocks quickly. Really that much of a difference if they are large? Or maybe slower since FCMP?

(dropping blocks quite in general, years ago)

<spirobel:kernal.eu> @jpk68:matrix.org: i clarified earlier my approach is non interactive. further context: xcancel.com/spirobel/status/2020868563532382583#m and two more MRL messages ...

<jeffro256> Yeah, it's not a FCMP++-specific issue, but FCMP++ really doesn't help for popping blocks: monero-project/monero #10207

<jeffro256> Especially when each block is >6MB

Ah, I see, I was dropping manually using one of the extra tools beside monerod

Which of course didn't put anything back into the pool

<spirobel:kernal.eu> @jpk68:matrix.org: mrelay.p2pool.observer/e/gIrIw4QLRzMzb2VC maybe i should turn this whole thing into a gist ... just to be clear i dont like interactive protocols ... where both parties have to be online at the same time.

monero-blockchain-export

--pop-blocks

<rucknium> At one point, there were 9 orphaned blocks produced for the same block height. Was that caused directly be the consensus bug? It was a sight to behold.

<jeffro256> lol probably

<rucknium> Did we have progress on the other stressnet issues?

<rucknium> mrelay.p2pool.observer/m/monero.social/gYZDLUYFleUqMRKiFOSBRoOD.png (consensus-breakdown.png)

<rucknium> ^ Here was the set of orphan blocks on stressnetconsensus1.redteam.cash

Cool

<rucknium> Can IRC side see images?

There is a link that works

(But might expire after some time, I guess)

<rucknium> Thanks, DataHoarder[m] , for working IRC image links :)

<jberman> Slight progress on impaired node connectivity after deep reorgs, and jeffro also made solid progress on 1) faster wallet loading when the pool is large, and 2) improved fix to unrestricted RPC when the pool is large > <@rucknium> Did we have progress on the other stressnet issues?

<jberman> The consensus issue has unfortunately taken up a solid amount of time

<rucknium> Nice

<rucknium> I mean nice to your first message

<rucknium> After the meeting I will shut down my stressnet monitors while I re-sync testnet

<rucknium> Any other discussion about stressnet?

<jberman> Nothing from me

<spirobel:kernal.eu> @jpk68:matrix.org: the apparent benefit is that you dont have to sync wallets anymore.

<rucknium> 5. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667).

<rucknium> @yiannisbot:matrix.org said he would arrive to the meeting at 18:00 UTC. In 6 minutes.

<yiannisbot:matrix.org> Hi everyone, I'm here :)

<yiannisbot:matrix.org> The general feeling of the community seems to be that we skip Milestone 1 and focus on Milestone 2. We won't only count unreachable nodes, but try to find better heuristics and derive insights that would help identify spy nodes and blockchain surveillance companies. We will also spend some time to investigate if POW systems wo [... too long, see mrelay.p2pool.observer/e/sP21gIULNmpoZmxz ]

<yiannisbot:matrix.org> Does that sound like a good summary? We plan to update the proposal issue to reflect these new directions. Any extra feedback is more than welcome as we try to shape up the final version.

<yiannisbot:matrix.org> @rucknium:monero.social: plowsof what's your take and suggestions for next steps?

<rucknium> That sounds good to me. Right, I think one would use monerosim when you are ready to actually implement a feature into the monerod C++ codebase. Initial research on the viability of a PoW approach would come before that.

<rucknium> @boog900:monero.social had some recent thoughts about spy node countermeasure that he may want to post here.

<yiannisbot:matrix.org> Exactly. So if while doing the study we come up or identify a previously proposed approach that looks attractive, we can then port it into monerosim.

<rucknium> More comments on this item? (I see someone typing)

<vtnerd> For #2 (unreachable nodes) you kind of have to do the work if #1 anyway? Just no fancy dashboard?

<boog900> I had an idea on how we could prove nodes were not making too many outbound connections but it would require something like proof of storage. If we could do that though then we might be able to allow stemming to inbound connections, which would increase the stem graph and remove the privacy leak when nodes don't allow inbound.

<yiannisbot:matrix.org> Yeah, kind of. That's why we included it as a first item/milestone. But given M1 is not desired we'll do just what is needed to be able to get to M2.

<boog900> It's pretty cheap to tag on with proof of storage though

<rucknium> To get unreachable nodes, you take a different approach. You have to passively wait for nodes to connect to you. To get reachable nodes, you can just crawl rapidly through peer lists, connecting briefly to each reachable node. To get the ratio of reachable to unreachable, of course, you would do both.

<rucknium> Or there may be a smarter way to get unreachable node count, but I don't know of one.

<vtnerd> the primary value of unreachable node estimation is in d++ privacy related. Is that the consensus? Because funding the research for that makes sense

<yiannisbot:matrix.org> @vtnerd: Agreed, but to me that would be the natural next step.

<rucknium> @vtnerd:monero.social: Yes

<yiannisbot:matrix.org> @boog900: That's a good approach. We'll take this into account as we revise the methodology for Milestone 2.

<boog900> I feel Milestone 2's scope is getting large.

<rucknium> Paraphrasing, the D++ papers said that unreachable nodes don't play a large role in the network, so they are ignored in the analysis. We could show that unreachable nodes do play a big role in the network, at least by the number of nodes.

<rucknium> I am trying to find the quote. They don't use the term "unreachable"

<rucknium> Can't find it at the moment.

<rucknium> We can end the meeting here. Thanks everyone.

<yiannisbot:matrix.org> Thanks. We'll be back next week with an updated proposal for Milestone 2 and hope to make progress from there.

spirobel: Your twitter post is too vague to properly judge the proposal. You should post a more detailed write-up, with all the keys and derivations, what constitutes an address, what is included on-chain and what must be shared off-chain.

I'm suspecting that in the process of writing it down, you will identify several issues.

<spirobel:kernal.eu> @tevador it is good enough to judge the core idea. no i don't think there is an issue with this. its a fairly clear idea

<spirobel:kernal.eu> i will turn it into gist when i have more time

It's not clear to me. One paragraph says the sender includes an index verbatim, one paragraph says the sender increments an index and one paragraph says the sender fills part of the index with random data.

<spirobel:kernal.eu> or write a prototype ... do a kdf on the wallet seed and put it into the address ... put the secret into the place where the dummy payment id is now

<spirobel:kernal.eu> then only scan transactions that contain this secret in the dummy id

But that's a serious privacy regression. Any external observer can see the same pid repeating and can conclude that those two outputs are owned by the same party.

<spirobel:kernal.eu> @tevador ... yes because this works for only one tx, so after that this secret index needs to be incremented

That doesn't solve anything, the external observer can identify (pid, pid+1) just as easily as (pid, pid)

<spirobel:kernal.eu> no it cant. because after the initial transaction the channel is open and we can obviously "increment" it in away the channel observer wont know

Ah, so your proposal requires a secret channel between the sender and receiver. OK, in that case we don't actually need addresses, the receiver can just construct their own outputs every time.

<spirobel:kernal.eu> and the point is: you find the channel opening ... and then you can find all others ... that where sent with this participant

<spirobel:kernal.eu> no wallet syncing anymore

<spirobel:kernal.eu> and just to be clear: by channel i mean this in the simplest way, just some ecdh with the viewkey in the address and just say: this is the next secret for the next transaction. then you can find it as easily as the first but the observer wont know. thats what i mean by increment

<spirobel:kernal.eu> used the word channel because i had hedy lamarrs frequency hoping technique in mind, but its not some interactive off chain connection

<spirobel:kernal.eu> so you can reconstruct the first secret from seed and you get all the others afterwards as the next "index" is always embedded in encrypted form in the transaction

Does it allow for stateless address generation? Probably not. You'd have to keep track of issued 'view keys' and never reuse the same key for two recipients (even if they don't send you anything). And you still have to scan, at least for the first transaction in every channel.

<spirobel:kernal.eu> do subaddresses allow for stateless address generation? no we increment the subaddress index. " never reuse the same key for two recipients " exactly what we recommend now for subaddresses ...

Jamtis does allow for stateless address generation.

<spirobel:kernal.eu> and scanning for open channels: no. the expensive part is the cpu work ... and even if we were to still to do all the network fetching (which is not necessary, as this secret is similar to a txhash an "index" in the sense of a database index, so we can retrieve just what we want. its just a matter of in the case of remote node [... too long, see mrelay.p2pool.observer/e/zYKsgoULTVN4M0RS ]

It could probably work if the channel opening transaction included the original index. But at least the sender is always stateful. If they ever forget how many transactions they have sent, repeated 'view tags' will appear in the blockchain.

spirobel: you can't have stateless address generation that supports "index lookup" because you don't know which addresses exist.

<spirobel:kernal.eu> yes i dont see statefulness as a big issue. wallets have to do this in practice. statefulness is cheap compared to having to scan every single transaction everyone is sending all the time

<spirobel:kernal.eu> and also for logical reasons: if you want to compartmentalize your identity you have to make different identifiers for the people you interact with in any case

Stateful addresses get you issues like this: monero-project/monero #8138

<spirobel:kernal.eu> but that is an engineering issue. because wallet2.cpp sometimes left gaps ... in my wallet library i increment the index for every address generated

And how do you know the value of the index when restoring from a seed?

<spirobel:kernal.eu> this whole lookahead thing is clunky ... also statelessness is not worth the price ... we can literally do away with scanning entirely ... which is a much practical step towards scaling than something like tachyon (which needs to update a proof constantly to be able to spend, different topic, but shows the different directions here ...)

<spirobel:kernal.eu> "And how do you know the value of the index when restoring from a seed?" you would know how many addresses you generated ... you can easily just make 100000. just call the kdf make the secret ask the node if there where txs for these ... just a database lookup

<spirobel:kernal.eu> and the incremented indeces per participant only come into play if a tx was found ... if that is the case its easy ... because the info is in the tx

<spirobel:kernal.eu> alright its getting late here I am getting sleepy. has been fun chatting with you cya

<br-m> <rucknium> Can IRC side see images? > 19:47:26 <rbrunner> There is a link that works > 19:47:58 <rbrunner> (But might expire after some time, I guess)

the links won't expire unless the content is deleted on the matrix side

and bridge stays up, it mainly proxies the authenticated call 1:1