Meeting summary: Monero Research Lab, 14 February 2024

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from February 14th 2024, 1700 UTC.

Logs

The raw, unedited, full log file for this meeting:

240214-mrl.log (144 lines)

Summary

Note: it is possible that some relevant information may be missing from this summary; read the full log file for the complete, unedited discussion.

• Participants: 7 (rucknium², d​angerousfreedom³, a​lex⁴, j​effro256⁵, rbrunner⁶, xFFFC0000⁷, plowsof⁸)

• (1) Updates

  • rucknium was working on both OSPEAD⁹ and some empirical analysis of unlock time

  • j​effro256 was working on seraphis tx serialization¹⁰

  • xFFFC0000 was working on fixing locking mechanism on blockchain.cpp¹¹

• (2) Open discussions

  • (2.1) on ‘Removing/Fixing/Encrypting monero’s timelocks’¹²:

    • rbrunner noted that his recent Reddit post (‘Timelocks: Let us finally retire a rarely used and dangerous feature of Monero’¹³) has 99% upvotes: I would guess 8 or even 9 out of every 10 comments are pro removal

    • r​ucknium linked to their recent analysis¹⁴ which includes usage stats and some estimates of the privacy impact on users who are creating txs with custom lock times and noted that 95% of custom unlock times have no effect since the wallet developer(s) do not understand that block height is absolute and also the real spend can be correctly guessed in 34-91% of the custom unlock times that I evaluated

      • j​effro256 suggested the possibility that developers actually DO understand that the height is absolute, but they’re putting other meta information in that field

    • a​lex pointed out that timelocks can be a good feature and shared how LocalMonero¹⁵ occasionally uses it to disincentivize users that repeatedly ignore bans from trying to return to the platform: we take the XMR that they placed in the arbitration bond and send it to them in a timelocked transaction to disincentivize them from trying to return again

      • plowsof was unhappy with LM’s usage of timelocks: The fact that you can punish people (deserving or not) is terrible

      • rbrunner acknowledged that timelocks do have uses - including alex’s use case which has a novel edge - but remained skeptical that they are net positive: for me they in no way outweigh the negatives

    • r​ucknium was wondering if a compromise was possible: Maybe wallet2 can consider custom-locked outputs as “not received” by default

    • a​lex mentioned other cases where a timelocked tx might be useful: where a person might know ahead of time that they will be entering a dangerous situation (travel, jail, mandatory conscription, etc) and want to ensure that their coins will not be spent until they are out of the situation, so they send themselves a timelocked tx

      • rbrunner noted that some use cases with rents, subscriptions and similar pay-ahead things can be very dangerous if circumstances change, and the XMR absolutely can’t

    • j​effro256 thought that LM’s use case can be replicated by choosing to send the funds later or sending to a time lock puzzle¹⁶

      • alex replied to jeffro256 noting that a timelocked transaction is better than choosing to send the funds later: the person might start to claim that we never intend to send them and start some sort of reputation damaging action

      • j​effro256 suggested sending the funds in a time lock puzzle and proving that they will be able to access the funds after s bounded amount of computation; alex was interested, although unsure how to implement it

    • j​effro256 listed the main concerns with time locks for 99.9% users:
      • 1) receiving time locked funds leads to confusion why it isnt spendable
      • 2) you can’t pick locked decoys which degrades on chain privacy and makes making non fingerprint able decoy selection harder
      • 3) you cant pick locked decoys which can open you up to privacy attacks from an untrusted daemon
      • 4) it makes transactions less uniform which degrades on chain privacy

    • alex was considering the fact that the lock is per TX as opposed to per output to be the actual unintuitive part

    • plowsof thought that by merging jeffro256’s PR (‘Enforce Tx unlocktime is Zero by Relay Rule’¹⁷) instead of disabling with a hardfork could encourage devs to not care about unlock_time

      • rbrunner noted that a separate discussion might be needed for this topic, but only if/after consensus to remove the feature is first reached

    • rucknium pointed out a bigger issue that needs to be solved, which is Nonstandard txs fees¹⁸: Right now usage of custom unlock time is very low. Nonstandard txs fees, which about 5% of txs use now I think, are a much bigger problem

    • a​lex finally agreed with rbrunner and noted that the simplicty and privacy of the XMR protocol is more important than [LM’s] use case and was cool with the removal of timelocks: If it’s a hazard to privacy it should be removed, just like tx_extra.

    • r​ucknium was keen to point out that locked transactions are not just a theoretical risk and linked to a 2023 discussion¹⁹ about 133 XMR that were blocked for a period of 4 years

    • d​angerousfreedom was in favor of disabling it (for the sake of privacy) for future transactions but not void the current ones that uses it and suggested using a robust and easy to use multisig to fix many of the timelock issues

    • alex concluded that existing timelocks should be honored, but for the sake of simplifying XMR and strengthening privacy they should be removed, assuming that time lock puzzles are a practical solutions as jeffro256 says

      • jeffro256 agreed with alex: no more new non-zero tx unlock times, but honor the old unlock times

    • r​ucknium noted that having the off-chain time lock puzzles working would be a good compromise

    • j​effro256 was ready to discuss some extra issues, including a slight change to the unix-time-based unlock times, a small modification to the consensus rules also related to the unlock time, and disallowing v1 transactions for “unmixable” input amounts in the next network upgrade but rbrunner pointed out that those issues would need a handful of meetings

      • rbrunner suggested xFFFC0000 could look into off-chain time lock puzzles; xFFFC0000 agreed to take a look after fixing the locking mechanism on blockchain.cpp

Update: added reference link to time-lock puzzles technical report¹⁶ (credit to Rucknium for sharing link).

Let me know if you find this kind of report helpful.

Feedback, edits always welcome @/about.

-3RA