Monero Research Lab Meeting - Wed 15 July 2026, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Live log: https://libera.monerologs.net/monero-research-lab

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. FCMP++ to-do list status. Programming tasks. Reviews and audits.

4. Post-quantum encryption. Jamtis. Repurposing unlock_time for relative locks with FCMP++.

5. FCMP beta stressnet.

6. monerosim.

7. Any other business

8. Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs: #1420

[Rucknium]

Logs

< neptunian:unredacted.org > Good afternoon, all.

< rucknium > Meeting time! #1421

< tevador > Hi

< ravfx:xmr.mx > o/

< rucknium > 1. Greetings

< rbrunner > Hello

< boog900 > hi

< articmine > Hi

< vtnerd > Hi

< jberman > waves

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

< jeffro256 > Howdy

< rucknium > me: Keeping stressnet stressed and helping troubleshoot there.

< jeffro256 > me: reviewing FCMP++ PRs and upstream bug fixes, reworked my RPC speedup PR , worked on some upstream bug fixes myself

< vtnerd > Me: still working on getting the serialization pr 100%, getting closer to (hopefully) solving the weak ptr memleak, and lastly fixing the slowdowns on d++/p2p send code

< jberman > me: FCMP++ integration PR's, stressnet debugging followup

< neptunian:unredacted.org > me: Reading some fun things about lattice commitments and various other things.

< tevador > I have this item for discussion: monero-project/research-lab#161 (apologies for the late submission). Can be done in agenda item 4.

< rucknium > tevador: Ok it can be discussed during item 4. Thanks.

< rucknium > 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero#53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/).

< jberman > * Still slowly making progress on getting integration code merged upstream

< jberman > * Making progress on the major beta stressnet items, however, I would stlil say the beta is in a state where FCMP++/Carrot code doesn't need to be blocked from mainnet aka it seems to be in a good state

< jeffro256 > As for the task list , since seraphis-migration/monero#424 was merged and reviewed (thanks Ukoe), I can rebase the wallet knowledge proofs PR , and chug along with that

< jberman > * UkoeHB has mentioned for multisig he has 1 last test he's working through

< jberman > I don't have an update on what's next with hw wallets

< ofrnxmr > Also, plowsof:matrix.org performed wallet sync and cold signing on mobile wallet for stressnet

< jeffro256 > I keep getting messages that the companies are looking jnto it, but so far nothing has materialized

< jberman > hot/cold wallet stuff seems pretty close to the finish line as well thanks to jeffro256:monero.social

< jberman > helioselene audit is still ongoing, and we're still discussing the next steps for another audit round on the circuit + gadget ipml internally

< neptunian:unredacted.org > jeffro256: Which companies are looking into it if I may ask?

< jeffro256 > Ledger, Trezor

< plowsof > ofrnxmr yes , these transactions where all signed offline via DataHoarders stressnet payments explorer https://stressnet.p2pool.observer/payments?id=cat

< plowsof > and vtnerds lwsf carrot branch

< rucknium > plowsof: Thanks. Does that mean that the code that we know works is Go code?

< UkoeHB > Yes working on multisig test. wallet2 is quite poorly designed for testing.

< jpk68:matrix.org > Hello

< rucknium > Anything more about this topic?

< plowsof > afaict yes : for the end user - the difference is after you import the signed transaction set - there is another 10-20 seconds of work that is done (building the tree and things jeffro would know about) but thats all. signed/unsigned tx sizes are just as small as wallet2 tx's

< rucknium > 4. Post-quantum encryption (monero-project/research-lab#151 (comment)). Jamtis (https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-c-instant-sync-protocol). Repurposing unlock_time for relative locks with FCMP++ (monero-project/research-lab#161).

< tevador > The relative lock is a trade off which might be worth the slight leakage it would cause.

< jeffro256 > I don't understand how making the unlock time relative does anything to help it support payment channels

< neptunian:unredacted.org > jeffro256: If I'm reading it correctly, I think it's just addressing having a better unlock_time which would preserve the payment channels.

< tevador > It allows the channel to have 2 presigned transactions: Withdraw (time-locked) and Punish (not locked). The Punish is used if Alice attempts to close the channel with an old state.

< tevador > But I agree we should investigate specific protocols it would allow before implementing it.

< jeffro256 > Ah I see. In that case, we would need to move the reference_block field to the signable portion of the transaction

< articmine > tevador: Which works very well if the fees are much lower than the channel value.

< jeffro256 > This would break tx chaining and make offline signing weirder

< tevador > jeffro256: no, it does not need to be signed

< tevador > only unlock_time = 1 is signed, so Alice cannot change that

< rbrunner > I am still a bit confused. Their value does not rest on them being relative now, or does it? I could already lock up to the same block like any relative lock with the "old" locks

< tevador > She can select whatever reference_lock / anchor_height she wants, but if block_height - anchor_height < 720, the transaction won't be relayed.

< jberman > > But I agree we should investigate specific protocols it would allow before implementing it.

< jberman > I agree with this. If there is a specific protocol spec'd that could feasibly work, then it could make sense. FWIW moneromoo at one point highlighted how there is still a way for someone to hack that kind of unlock time behavior with the current unlock_time: by constructing a tx and putting it on chain with a specific unlock_time, and then pre-signing a tx with that output as an input

< tevador > You need a relative lock to have payment channels that don't expire

< neptunian:unredacted.org > I feel like the fake lock fix could be an issue. How many wallets would realistically be randomly setting unlock_time=1 for normal transactions?

< rbrunner > Ah, the clock starts to tick with the mining of the tx, whenever that will be?

< tevador > Yes, the block starts ticking when Alice submits the malicious old state transaction.

< tevador > clock*

< jeffro256 > But does that leave the door open to fraud by anyone who knows the rerandomizations by setting an arbitrary reference block? > only unlock_time = 1 is signed, so Alice cannot change that

< jeffro256 > *doesn't

< tevador > No, you cannot make a valid membership proof for an enote that's not in the tree yet (it will be added ~700 blocks later)

< tevador > unlock_time = 1 tells the consesus protocol to use an old tree root for the proof

< tevador > Which proves that the transaction is spending only enotes older than 24 hours.

< rbrunner > Are these new locks still per tx and not per output?

< rucknium > IIRC, one of the reasons custom unlock time is being eliminated at the deployment of FCMP is that custom unlock time negatively affects the FCMP tree performance.

< neptunian:unredacted.org > I think it's a bit of a UX issue to have random 24-hour locks on ordinary transactions.

< tevador > neptunian: No, there would be no locks on random transactions.

< tevador > The enote spent is ALREADY older than 24 hours, so there no wait time.

< rucknium > And hasn't the issue with Monero-style locks been that when custom lock time arrives, you have a race in the txpool to spend the tx if multiple people have the right to spend it?

< neptunian:unredacted.org > tevador: Ah. I see. Thanks for clarification.

< tevador > The repurposed unlock_time doesn't work like the old one. It only affects tx validity, not subsequent spending.

< jeffro256 > Yeah that could work. If we can do a gate on some cryptograpgic condition, then that would be pretty similiar to HTLCs

< tevador > Basically, with unlock_time = 1, Alice has a pre-signed transaction that will become valid in 24 hours. After that, only the normal 10 block lock applies.

< jeffro256 > tevador: *assuming no large changes in hashrate

< tevador > ~24 hours*

< jeffro256 > I agree with Berman that it would be nice to have at least 1 sketch of a real, useful payment channel before supporting it, but this version of time locks is much closer to actually supporting payment channels

< tevador > I will try to add a protocol sketch to #161

< UkoeHB > So it's a tx publish lock, not an enote lock as with the current timelocks. Yeah you can accomplish the same with timelocks by submitting a locked enote then chaining off it. So any protocol using relative locks would presumably already work.

< tevador > No, it would not work.

< jeffro256 > UkoeHB would the main difference here be that this relative lock doesn't put the compute / storage burden on tree builders?

< tevador > Current unlock_time is unconditional, so it also prevents Bob from spending it with his Punish transaction.

< tevador > The proposed unlock_time functionality would be used to only lock Alice's Withdraw transaction. AFAIK that can't be accomplished with the old locks.

< UkoeHB > tevador: you can timelock a dummy enote, it doesn't have to be the funds actually transferred by the relatively-locked tx.

< UkoeHB > jeffro256: yeah, and simplifying the payment channel workflow (if there is one)

< tevador > OK, so we have a presigned dummy enote. Alice publishes just this dummy, waits 24 hours and then steals the funds from the wrong state transaction.

< tevador > I haven't seen any workiable protocol using the current broken unlock_time feature.

< UkoeHB > tevador: probably easier for you to post a sketch then I can logically disprove it (or fail to).

< tevador > I will post a sketch

< tevador > For proving, not disproving

< neptunian:unredacted.org > I'd agree with Tevador about the relative lock being good given the slight leakage.

< neptunian:unredacted.org > It may be best to wait for the full sketch, though.

< UkoeHB > tevador: what about a 2-of-2 on the dummy so it can't be invalidated by Alice?

< tevador > UkoeHB: You can try to sketch your protocol using the old locks. I'm strongly suspecting it won't work.

< neptunian:unredacted.org > Ooh. A sketch-off.

< rucknium > Thanks, tevador . Anything more on this topic for now?

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

< jberman > For v2.1, I'd like to have the elusive wallet tx rejection double spend errors fully solved. It seems there are a few issues it has exposed (also present in the current release monerod) that are leading to this rare edge case issue

< rucknium > I'm starting to test the proposed fixes.

< jberman > ^I've requested rucknium:monero.social run all the patches we have for identified issues (1 patch by vtnerd as well) + more detailed logging that would help us be certain we have fully solved it

< jberman > And that logging also includes additional logging that would help us get to the bottom of a distinct issue of more frequent bans, seemingly caused by tx relay v2

< jberman > Here's a tracker for beta v2.1 : seraphis-migration/monero#415 , I'll updae that as we get more info on the issue with rucknium:monero.social 's majorly appreciated help

< jberman > the code rucknium:monero.social is running includes the 3 PR's under the "sporadic double spend" bullet, and the "log missing requested pool tx" bullet

< rucknium > Anything more on stressnet?

< jberman > nothin from me

< jeffro256 > vtnerd how is p2p SSL looking for stressnet?

< rucknium > 5. monerosim (https://github.com/Fountain5405/monerosim).

< rucknium > gingeropolous:monero.social seems to be working on improvements: https://github.com/Fountain5405/monerosim/commits/main/

< rucknium > I don't know if there is anything to discuss.

< plowsof:matrix.org > its claimed as being completed now https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589

< rucknium > I think the task described in the CCS is completed.

< plowsof > thanks for looking into this Rucknium 👍

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

< articmine > Thanks

< jeffro256 > Thanks everyone!

< vtnerd > jeffro256: Sorry phone call came in. It was ready last I looked, I'll double check that before Friday

< vtnerd > The d++ slowdown took precedence

< vtnerd > vtnerd: I'm in the process of moving, so things are a bit hectic around here for another week or so

< DataHoarder > 19:18:28 plowsof: Thanks. Does that mean that the code that we know works is Go code?

< DataHoarder > This is scanning code, not signing code. I can only generate/verify SAL proofs, not FCMP. I can generate/sign full txs pre-FCMP++. I think plowsof just means "here's a list shown via my explorer" :)

< plowsof > couldn't have said it better myself, thanks DataHoarder 😅

< jeffro256 > tevador can I ping you again for mx25519 PR review plz ? The carrot_core dependencies are almost all merged, which would leave mx25519, I will PR the unclamped changes soon

< tevador > OK