This is an automated archive made by the Lemmit Bot.
The original was posted on /r/monero by /u/rbrunner7 on 2024-02-09 14:53:09.
TL;DR: Together with a number of other Monero devs I vote to soon remove a Monero feature that lets you lock XMR against spending for a certain period of time, mostly because the feature is not very useful but can be dangerous. If you want to have your say in the decision process, read on and comment.
What are these "timelocks"?
If you receive a Monero transaction you have to wait 10 blocks before you can spend any XMR, or more exactly, any outputs / enotes, that came with it, a wait of 20 minutes give or take.
There is a hardly known and rarely used feature to influence this enforced wait time, i.e. to make it longer. A Monero transaction has a field with a technical name of unlock_time that you can use to put a timelock on a transaction: Set the field to a block number higher than the number of the most recent block in the blockchain, and this will make it impossible to spend any XMR that arrive with that transaction before the chain has grown to that block number.
An example: Soon the Monero blockchain will reach block number 3,100,000. If a transaction in that block has its unlock_time field set to 3,200,000, the receiver will have to wait 100,000 times 2 minutes, more or less, until they can spend the XMR, i.e. roughly 70 days.
The field is big enough to hold block numbers that easily amount to a wait time of centuries.
It seems that at the moment there is only a single wallet app, the "official" Monero CLI wallet, that lets you build transactions with such a timelock set interactively. If interested check the locked_transfer and locked_sweep_all commands there. Their limit is 1,000,000 blocks into the future, around 3.8 years.
If you use the Monero RPC interface you can write your own software to use timelocks with only a little bit of programming knowledge, without such a limit, however.
What are they good for?
In discussions about timelocks the most often mentioned use case is probably enforcing your own decision to hold your precious XMR at least for a given time: No need to have perfect self-discipline and "diamond hands" to HODL for a few years if you send a transaction to yourself with a lock time years in the future and leave the rest to the Monero network! Somebody wrote a nice little tutorial two years ago detailing how to do it.
There are a few more possible use cases. Monero dev /u/j-berman has detailed them here on GitHub - see the info below Known use cases.
An important piece of info is that atomic swap implementations involving XMR do not rely on these timelocks. Removing them would not break anything there.
What's the problem with them?
Monero's timelocks as implemented now have various issues.
To start, they work on the level of whole transactions, not on the level of individual enotes. This means that the change coming back to you when sending a transaction with a timelock will also be locked. Very easy to shoot yourself in the foot here: Have a single enote over 10 XMR in your wallet, send somebody 1 XMR locked for 5 years, have your change of 9 XMR locked for the same 5 years.
Timelocks are visible in the blockchain. Everybody can see them, which can be a privacy problem.
But probably the biggest problem is that they pose a danger to parties like exchanges, "swappers" and webshops that accept XMR for payment. Because timelocks are such a rarely used and obscure feature there is a lot of custom-built software out there that does not check for them. The result can be fatal for the receiver if they deliver anything to you in exchange for the XMR you sent them, assuming that everything is ok, only to find out later that they can't really use the XMR.
/u/MajesticLabs gave a warning about this to fellow market participants about a year ago here on Reddit. As a nice success many parties could be made aware about the problem and took action because of this follow-up initiative, but I have doubts that everybody is immune as of today.
/u/the_charlatan_ wrote an extensive and very interesting entry Monero timelock woes in their blog about all the various possible difficulties, together with hard numbers that show how rarely they are used.
A failed attempt to get rid of them
In late 2020 and early 2021 the Monero dev community had a quite extensive discussion about timelocks. You find many of the details in this GitHub issue and in logs of dev meetings on IRC and Matrix, e.g. this one.
If you go through the comments you probably come to the conclusion that hardly anybody really wanted to keep timelocks, and you note that many devs spoke out directly in favor of removing them altogether. We were on a good way to plan and then implement the necessary code changes to be included in the next Monero hardfork.
But somehow, how to put this, the whole endeavor just petered out. Nobody took the lead, actually started to code and made a PR, and nobody complained loudly enough about that to get things moving nevertheless. Call this a collective failure of project management if you wish.
So the Monero hardfork / network upgrade in August 2022 came - and was missed as a chance to implement the removal.
A new hope
But now, a few days ago, Monero dev jeffro256, probably after silently picking up the subject again, surprised with this PR.
This code implements first steps to retire timelocks. It removes the CLI wallet commands to create transactions with timelocks, and also modifies the RPC interface so you can't create them anymore through that. Finally it makes the Monero daemon reject any new locked transaction if somebody submits it using a wallet app, or if another daemon tries to pass it on for further distribution through the network and finally mining.
These measures could go into service with any next update of the Monero software; typically such updates happen every few months. As people are not forced to use such interim updates because they don't implement a hardfork, timelocks would probably not become impossible outright. But depending on how many people install the update, it could become pretty hard pretty fast to successfully get a transaction with a timelock into a block. Thus this would be a good step to diminish the danger to XMR processing parties.
For the next hardfork, whenever that may be, some bits of additional code could be added on top to declare new transactions with timelocks forbidden, and any blocks beyond the height of the hardfork containing one invalid, to really make it game over for timelocks.
What now?
A decision is needed: Do we go forward with that code and bring it into service?
In my opinion Monero is as successful as it is because it has a large and interested community where a surprising number of people all contribute to the success of the project, and large parts of that community read this subreddit. So, please make your opinion heard, comment away, and don't hesitate to ask if you want to know more about some detail. Thank you!
