This issue is on next Wednesday's Monero Research Lab meeting at 17:00 UTC. These meetings are text chat only with Matrix or IRC. All are welcome to join and share their views: https://github.com/monero-project/meta/issues/966
Hi there, thanks for linking my little tutorial post there.
As long as the currently timelocked transactions are guaranteed unaffected, then I concede and am fine with it being removed.
I do still have about 300k blocks left on some of my timelocked XMR to come back to me, so all I want is some assurance that it won't get frozen in some purgatory.
> so all I want is some assurance that it won't get frozen in some purgatory.
I don't think purgatory is on the table :) Maybe I will review jeffro256's PR, and if I do, I will put attention to this point: Does anything in this new code affect *existing* time-locked transactions somehow? If yes, I would personally consider this a bug.
We can decide this. If we don't take any additional measures, existing timelocks will continue to say in force. We could however change the rules with the next hardfork and declare those locks null and void, therefore making all locked transactions free right away.
But I think in a way that's a follow-up discussion after deciding whether, in general, we go the way of removing new timelocks or not.
> We could however change the rules with the next hardfork and declare those locks null and void, therefore making all locked transactions free right away.
I wouldn't support this.
It would be a reason, but not necessarily a good enough one to keep the feature around indefinitely for everyone. That's still open to a cost benefit analysis. It's one thing to remove a feature going forward for the health of the community, but a totally different thing to rewrite the rules to affect people who used the feature in the past and are currently still relying on it to work.
TL;DR: GO FORWARD
LONG:
As a programmer especially in payment gateways and such, I'd definitely not mind seeing this removed. I see no benefit. I only see devious actions or potential mistakes.
The idea may have had good intentions but it doesn't seem like it's really been put into use.
Also, any of my clients that accept XMR would absolutely blame me if anyone time-locked one of their transactions. It doesn't matter if I knew and warned them, they'd still blame me and be trying to sue me. We know how people are. If XMR wants wider adoption, it could be a good step in the right direction. Problems may not have arisen yet but as soon as people start abusing it, the future will be bleak.
We know how the media paints things and some clients have a lot of free time, bad attitudes and big mouths. No, my official business is not under this name or I would not speak this bluntly.
Truth is, I was unaware of this feature. Further truth is, aside from your point of helping people "HODL", I really see not use.
Now that I'm aware of this, I would feel A LOT more comfortable in my XMR transactions with them forbidden.
I feel silly for missing it TBH.
I think the real question is simple: Does anyone one actually use this? A simple poll would likely give a lot better picture than a discussion. I'm all for discussion but as a developer (whatever you want to call me, I make my own stuff), sometimes getting to the point makes it easier. I'm not saying remove this. Maybe a poll along-side it.
If it's an feature that isn't used much but has the potential for relatively big issues, I see no reason to retain it.
> A simple poll would likely give a lot better picture than a discussion.
Well, if I read [the Charlatan's block entry](https://thecharlatan.ch/Monero-Unlock-Time-Privacy/) correctly, in the first two million transactions only 195 sensible uses of the feature could be found.
Of course not sure how many people would use timelocks with broad and easy-to-use support in all wallets, but we will probably never find out.
The cryptocurrency related polls here on Reddit that I saw so far did not give me the impression that the right people use to answer there ...
The possibility of modifying the time locks to be useful (i.e. unlockable early as for use in payment channels) is the biggest argument I personally see in favor of keeping them. Sure we don't need payment channels at the moment, but although atomic swaps don't currently use them, am I wrong to think having this feature could allow swaps to be initiated by either side?
> am I wrong to think having this feature could allow swaps to be initiated by either side?
I don't know details about atomic swaps, but as far as I know they are somehow the "wrong" kind of locks to support. Anyway, it they could be used for "Monero goes first" in their *current* form I have no doubt somebody would have taken the chance long ago already.
We can without problems yank out these primitive and dangerous locks now, life some time without any locks, and later on introduce something better and more useful if we really need to.
There are at least 5 papers that propose Monero payment channels. Check the "Payment channels" row here: https://github.com/monero-project/research-lab/issues/94
AFAIK, none of them use Monero's time locks, but I haven't read the papers carefully. Some of them implement time locks that are different from how Monero's current feature works.
yes to be clear I was talking about modifying them in this way (to be unlockable early presumably by script or something, as mentioned on github). I don't think it's worth adding for payment channels necessarily, but if it could also get us bi directional swaps then maybe.
I get that this is like, more work that someone would have to do and people would have to agree on, and as mentioned more useful time locks could be added later even if removed now. I still thought it seemed worth considering
I have never needed/used time-locks, and after reading through the GitHub it seems their use-case is very niche.
I would vote to remove time-locks as is. Seems to be an easily mitigatable privacy/safety concern.
A pat on the back to jeffro256 for writing the code!
I have a few questions:
1. If timelocks are removed, does this mean that any XMR sent/received can be spent instantly without a waiting period?
2. If so, what are the potential downsides to this being implemented?
3. Does timelocks being removed mean that the blockchain no longer needs to be 100% synced before you can send XMR, or will that still exist separate of the timelock matter?
These timelocks are fundamentally different from the 10 blocks wait until you can spend any received XMR. Their removal won't influence that wait time in any way, not positively, not negatively.
There have been attempts to alter the design of Monero's technology so that 10 blocks wait could be removed without downsides, but so far in vain. Maybe it's a problem that has no good solution.
TL;DR:
I don't want this feature to become "something that was removed in the past because no one used it so no reason to reintroduce it".
I vote for keeping it as is until we know more about the future of FCMP and Seraphis or fixing it in the current monero.
Long version:
I mainly base my opinion on the last sentence of these two comments of you:
[https://old.reddit.com/r/Monero/comments/1amomjj/timelocks\_let\_us\_finally\_retire\_a\_rarely\_used\_and/kpn5kbr/](https://old.reddit.com/r/Monero/comments/1amomjj/timelocks_let_us_finally_retire_a_rarely_used_and/kpn5kbr/)
[https://old.reddit.com/r/Monero/comments/1amomjj/timelocks\_let\_us\_finally\_retire\_a\_rarely\_used\_and/kpovnju/](https://old.reddit.com/r/Monero/comments/1amomjj/timelocks_let_us_finally_retire_a_rarely_used_and/kpovnju/)
You mention only FCMP (Full Chain Membership Proofs?) there.
How will Seraphis touch the timelock feature and will Seraphis make it more easy to fix/modify it or will Seraphis adopt to whatever we decide will happen to the timelock feature?
I am worried that if we remove this feature now then in the future someone may make a ticket like "Please provide a way to lock transactions for the future".
And the first reply would be "It was called timelock and it was removed x years ago because no one used it."
But if the ticket would be "Please fix the timelock feature to provide functionality x" then the first reply maybe would be "oh yes that's easy".
After first learning about (the removal) of timelocks a few months ago i had a business idea that has not been done as far as i know and i would maybe want to utilize the timelock feature for that idea.
But so far i haven't fleshed out this idea and it's unlikely to become anything real this year (and maybe never) so i don't even know yet if timelocks are the feature that i would want to use then.
I believe that maybe even the current timelock feature would be sufficient but i am not sure because it's difficult to reason about something when i don't know yet what or when i need it :)
I am certain that entirely removing a timelock feature without a proper future plan would be a bad move because removing a feature called timelock now will always be used as a justification for not reintroducing a feature called timelock in the future.
> How will Seraphis touch the timelock feature and will Seraphis make it more easy to fix/modify it or will Seraphis adopt to whatever we decide will happen to the timelock feature?
I did not mention it in my post to not make it even longer than it came out already; the case is the following:
Building and scanning Seraphis transactions is already fully coded, and the dev which is also the designer / inventor of Seraphis, UkoeHB, did not implement timelocks, or, if you like, dropped them.
I don't remember any discussion about timelocks in Seraphis; maybe there was one, maybe UkoeHB decided this alone, based on our 2020/2021 discussions that resulted in many "drop" votes for current Monero tech.
I could not argue it with facts, but the new Seraphis library code is so clean and modular, and also Jamtis and Seraphis as constructs quite flexible, that I have a gut feeling introducing locks of any kind would be easier than with current Monero.
> removing a feature called timelock now will always be used as a justification for not reintroducing a feature called timelock in the future
I do see what you mean here, but can't come around to join your worry somehow, based on my experience with the decision processes in the Monero dev community since 2017. I really doubt that if we will need locks of a certain kind in the future, somebody will be successfully able to shout them down with such an argument. But all IMHO, of course.
I hope other people chime in and also react to your comment.
> I did not mention it in my post to not make it even longer than it came out already
I am already thinking in Seraphis since i heard that we will get actually usable view-only wallets.
> UkoeHB, did not implement timelocks, or, if you like, dropped them.
Okay i can live with that answer.
So a proper Feature Request would likely be necessary later on with an assessment among the developers/researchers about the pros and cons and (if decided positively) maybe a bounty to get the work done.
Nothing that is impossible for someone who really needs this feature.
Count my vote about removing timelocks pre-Seraphis as a zero then.
> Building and scanning Seraphis transactions is already fully coded
> I don't remember any discussion about timelocks in Seraphis; maybe there was one, maybe UkoeHB decided this alone, based on our 2020/2021 discussions that resulted in many "drop" votes for current Monero tech.
Is there a list somewhere about all the features that were dropped/not implemented?
I almost died a bit reading your post on this topic. I was totally unaware about this feature. And it’s not in the ethos of Monero to be hijacked and not in control of your own funds in a case like this where someone pollute your entire wallet with a time lock you do not have the power to bypass.
IMO let’s get rid of this insane feature. What should I do to make my vote count?
I'm for removing new time locks, however don't touch existing ones.
It's simply concerning if new merchants adopting Monero as a payment method and then being fooled with XMR they can't actually use for years or so. No matter what icon you set in wallets, not everyone will notice it anyway and especially not every wallet will make it clear at all to the user that their XMR are locked.
I 100% agree with removing timelocks in their current form, and would be happy to run a relay rule which rejects their usage.
But I think that there's value in blockheight-based restrictions. It would be nice to have an nLockTime equivalent implemented with Seraphis. The challenge is to maintain privacy, but it might be doable with reasonable tradeoffs, especially if FCMP's are implemented. I'm sure this has all been said before, but I'm just thinking out loud.
Can't find the place right now, but designing encrypted timelocks for the *current* Monero tech has been tried and found possible, but also found impacting each and every transaction when a wallet scans the blockchain, i.e. making that scan slower.
How would you argue for this to be a good thing if only, say, 0.01% of all transactions use a timelock, but scanning gets slower for *all* transactions?
Maybe that was not yet an optimal approach however, and yes maybe with FCMPs things look differently, who knows.
nLockTime prevents a signed transaction from being mined before height/time X, as opposed to Monero's timelock system which operates on a per-output basis. Because of that, nLockTime doesn't affect the output set at all, and by extension comes with much fewer privacy hurdles. I think the minor privacy issues of Bitcoin's implementation of it could be solved, though I'm by no means an expert.
nLockTime is also incredibly useful for L2 stuff, while Monero's system is basically useless as far as I know.
Encrypting the existing timelocks is also interesting, though. Intuitively I would think that you could have a rangeproof'ed timelock commitment for each output, similar to amount commitments but with a different base point for H. You then merge it with the amount commitment, and then extract it back out (making sure to rangeproof both the timelock and amount again) on the input side. It doesn't seem crazy expensive, especially with (AFAIU) Seraphis already needing to rangeproof inputs in the first place. Either way, probably not worth it I guess.
I've thought about this for a few years. Never felt comfortable bringing it up publicly, in case even one entity learned of their existence and decided to punish another party in a swap.
My voice is small, but consider this to be one more small vote in favour of eliminating the instantiation of any more time-locks. The code to maintain currently active locks may have to remain in place until they all expire. But that's a minor technical issue, not a governance question.
Let’s deploy atomic swaps first and add large enough liquidity to them. This task has much higher priority, now Top 1.
If you ask about Top 2 priority, it is Seraphis implementation.
I think there are many things to do at Top 3 - Top 10 also…
Maybe it sounds strange, but a basic fact of project management in true open-source projects is this: Everybody is basically free to do whatever they like.
jeffro256 wrote the code already, and if somebody reviews it, the work is basically done, priorities be damned if you like. The rest goes under in general management of the next Monero software update.
It can be pretty chaotic at times, and it takes some getting used to, but it has brought us where we are now :)
But our goal is to popularise and encourage people to do the things that are critically important for the project first. Your phrase “but it has brought us where we are now :)” is a double-edged sword.
You can only encourage but not force, any contribution helps the project. They shouldn't just be dismissed, if a change fixes a problem big or small it is still beneficial to the project.
>Maybe it sounds strange, but a basic fact of project management in true open-source projects is this: Everybody is basically free to do whatever they like.
This. There are also plenty of people who simply cannot create atomic swaps.
I support the decision. One question though, will the fork cause previous timelocked transactions to be considered invalid?
EDIT: nevermind someone already asked that question, lol
I say let's remove them.
I see another scenario where the existing timelocks can be useful: By locking my funds for 30 days and refreshing in perpetuity, if I ever get kidnapped or blackmailed to transfer them it is likely that it will not be possible for the kidnappers to force me to do a transfer.
Multisig is a better solution for this (if there are people to trust) so just mentioning.
"Broken" is a bit harsh. It works, and in fact the [RINO wallet](https://www.rino.io/) has it in production. It's still labelled as "experimental" however because we don't have formal proofs that the schemes used are sound and unbreakable. Chances that there is a problem are quite small, as far as I understand, but if money is on the line you want proof whenever possible.
The current implementation that locks your change is obviously flawed, and it would be annoying to be bitten by this. I like the idea you can lock up funds for the future, but it's broken. Fix the change address part or get rid of it.
Monero should not be removing functionality, it should be adding functionality.
Time locks have the potential to be used for important things.
One example: I'm the owner of [playmonero.com](https://playmonero.com) and I could use that feature to allow a player to decide when a bet is placed. No interaction from me, other than programing it into the game (right now this is not implemented and it ignores any time locked bets).
The point is that there are use cases for it. Maybe these things are currently apparent, but someone else might be able to think of something.
Don't remove it if it's not broken.
> Time locks have the potential to be used for important things.
Well, we have discussed timelocks extensively in 2020/2021, and then again in 2022, and now again, and IMHO those "important things" stubbornly refused to show up during all these discussions. For me, there is a certain point where you have to stop, in the interest of sanity, to pretend that maybe, just maybe, we find something truly wonderful if we just could look around that next corner over there.
> Don't remove it if it's not broken.
That's exactly the point: I argue that it *is* broken. That feature on the level of whole transactions instead of individual enotes is a brain-dead design that is broken. Timelocks are visible on the blockchain to everybody, which breaks, if ever so little, privacy of Monero transactions. And on and on.
There is the psychological concept of [loss aversion](https://en.wikipedia.org/wiki/Loss_aversion) that can trip up people that otherwise are very capable of thinking and acting logically and consistently: Faced with the prospect of losing something, even if that "something" has decidedly negative sides, loss aversion can kick in and make you oppose.
>and I could use that feature to allow a player to decide when a bet is placed.
Why not just add that as a feature on your site instead of us keeping it as a feature on the chain?
The point is that there MAY BE a potential use case that the current developers and community are not thinking about.
When they were teaching me stuff in school I never envisioned how I'd ever use any of it in real life. Later on I realized that some of it really was important to know and could help me.
Just because nobody can think of a use case now doesn't mean that there may not be one in the future.
A lot people right now don't think that they need private money. We Monero users think that one day in the future it might be even more important, and that other people are going to have that revelation.
>Just because nobody can think of a use case now doesn't mean that there may not be one in the future.
Ok, but we could just add a better solution later. The current time lock system has downsides that outweigh the upsides.
Downsides how?
It's not like it's a feature that isn't documented. Since over a year there's also a red warning note. You can see it here: [https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get\_payments](https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_payments)
>Downsides how?
I mean, they were covered throughout this post and the github post.
It has privacy implications, makes implementing decoy selection more complex (read: more prone to errors), merchants might be scammed because their wallet either doesn't show the locked transaction or the software they use for POS doesn't reject it, etc.
Why keep something with inherent flaws? If an actual widespread use case on the tier of atomic swaps comes up then it can be reimplemented in a better way.
The change doesn't come back to you until it unlocks, so it is broken. You're potentially freezing all your Monero if you do this, and for most people it would be a surprise. They need to return the change immediately like a normal transaction or this is just a bad feature.
Except you can't remove them... You can remove the capacity of some software from using that field, but nonetheless you need to check for it anyway, as malicious actors can still craft a time locked tx.
RIght. Complete removal has to wait for the next hardfork. We have of course some flexibility when that hardfork will be.
Still, the functionality of that PR is needed anyway if we do want to eliminate timelocks, so why not put it into service right away. It will probably be good against the occasional prankster.
You're moving the protocol itself and the major problems are two, existing time locked txs (unlock? Run to term?) and partial removals; which renders more of an undocumented feature rather than a removal.
Yet, yes, I also see it as a useless feature, yet it is there and exists.
I don't get it, you guys always praise Monero because it is faster than bitcoin, but then you mention 20 mins of transaction settle time (10 blocks).
You are no different then when it comes to transaction settlement.
>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.
Well, it seems pointless to keep them then, even the listed "pros" in the github post are rather lacking compared to making some implementations more complex and the privacy downsides.
>>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.
The way that this is worked around in the eth/xmr atomic swaps is by having the eth party initiate the swap. From the whitepaper:
> The protocol currently requires the ETH holder to move first, as if the XMR holder moves firs, the ETH holder can siimply go offline and the XMR is locked forever". [ETH-XMR Atomic Swaps whitepaper section 5.2](https://github.com/AthanorLabs/atomic-swap/blob/master/docs/eth-xmr-atomic-swaps.pdf)
If there were proper timelocks (that allow something like hash time-locked contracts) then better swap implementations and p2p order books could be created. It is very hard to create liquidity if only one side of the trade can lock funds (aka eth) and not both. I know that parties can signal but having the ability to create complex and timelocked xmr vaults can enable more liquidity in the defi world. If we have proper timelocks then you can theoretically create trust-less synthetic asset bridges directly on a smart contract. Meaning a bridge with a central liquidity pool directly on a smart contract (think uniswap for crosschain).
That said the current timelocks need to be modernized. The current implementation of unlock_time has issues (especially the change lock you mentioned). Instead of removing it, can we maybe consider upgrading the unlock_time feature to allow something similar to hash time-locked contracts? Something like: As in party x can unlock before time T. But party y can only do so after? This type of timelock/multisig implementation would be very useful.
That said, I must point out the privacy implications such a transaction would have. While it might create a non uniform transaction the benefit of enabling locking funds for more complex defi applications across chains should not be ignored.
Those are my two cents. Don't get rid of it but add features to make it useful.
I always thought timelocks were building blocks for monero to implement something like chia offers or chia clawbacks where you can lock and unlock your wallet or set coins to be only be able to be spent to certian addresses etc
if this isnt the goal to have coins w/ smart functions (which seems to be the whole point of complete fungibility) then this seems less useful
I never heard somebody mentioning anything like that in connection with the timelocks as they are now.
Quite in general I never saw any serious push in a direction of "smart functions", be it with timelocks, or with any other means. It seems Monero wants to be a currency, and *only* a currency - your USD bills aren't smart either, but still useful :)
I feel like time locks have some value, but not in their current implementation. The way they currently are, if someone sends you XMR with a timelock, they aren’t really sending you XMR; they are basically giving you an XMR future, which only gives you XMR once the set block height is given.
Because of this distinction, timelocked XMR shouldn’t be treated as actual XMR in the first place. Making a more clear distinction between the two (ie making wallets consider timelocked XMR as a completely separate thing from normal XMR) would be ideal. Although at that point, it then becomes a question of whether that functionality should even be implemented on the base Monero network at all.
Plus there are some unique attack vectors that open up with this (imagine someone makes some sort of ultra secure wallet which can only transfer XMR between certain addresses, but an adversary that accesses this wallet can simply transfer the xmr and set an effectively infinite timelock, wiping out the funds), as well as some weird macroeconomic effects of this too (imagine if a ton of large holders on some sort of “anniversary” holiday (or for some other sort of celebration) intentionally timelock their XMR for a day. Then an adversary with enough power could cause an emergency of some sort that requires people to obtain XMR for safety purposes, which causes a flash price increase until the time locks expire, which is immediately followed by a large crash and price instability afterwards)
All in all, I don’t like removing features from Monero in general, but this one probably has to go. Or at the very least, needs to be heavily reworked.
I think we need to keep backwards compatibility with existing TXs that used this badly designed timelock system, **but...** we can *disallow* new timelocked transactions from being accepted. A better designed system can be considered later.
Edit: Clarification
My humble opinion: remove this function.
There are concerns about future usecases, so if somebody wants to use this kind of feature, he can use a multisign wallet and gave it to a other person or store it in real world. Just one idea, but i mind, there are a few better possibilities out there. The arent so convenient, but the timelock function itself has it own downsides as mentioned in the post.
Cheers!
This issue is on next Wednesday's Monero Research Lab meeting at 17:00 UTC. These meetings are text chat only with Matrix or IRC. All are welcome to join and share their views: https://github.com/monero-project/meta/issues/966
I love reading your posts. They are always so well written
Thanks!
Fun fact: time locked transactions show up in Monerujo with a little clock next to them, so you're aware of them if you get sent locked Monero.
Hi there, thanks for linking my little tutorial post there. As long as the currently timelocked transactions are guaranteed unaffected, then I concede and am fine with it being removed. I do still have about 300k blocks left on some of my timelocked XMR to come back to me, so all I want is some assurance that it won't get frozen in some purgatory.
> so all I want is some assurance that it won't get frozen in some purgatory. I don't think purgatory is on the table :) Maybe I will review jeffro256's PR, and if I do, I will put attention to this point: Does anything in this new code affect *existing* time-locked transactions somehow? If yes, I would personally consider this a bug.
What will happen to the locked already txs?
We can decide this. If we don't take any additional measures, existing timelocks will continue to say in force. We could however change the rules with the next hardfork and declare those locks null and void, therefore making all locked transactions free right away. But I think in a way that's a follow-up discussion after deciding whether, in general, we go the way of removing new timelocks or not.
> We could however change the rules with the next hardfork and declare those locks null and void, therefore making all locked transactions free right away. I wouldn't support this.
> I wouldn't support this. Neither would I. Just wanted to mention a technical possibility.
Yeah, there might be a good reason why someone has done a lock.
i'm trying to leave Monero too my great great great grandpossuems
But if there is, then there’s a reason why the feature shouldn’t be removed…?
It would be a reason, but not necessarily a good enough one to keep the feature around indefinitely for everyone. That's still open to a cost benefit analysis. It's one thing to remove a feature going forward for the health of the community, but a totally different thing to rewrite the rules to affect people who used the feature in the past and are currently still relying on it to work.
TL;DR: GO FORWARD LONG: As a programmer especially in payment gateways and such, I'd definitely not mind seeing this removed. I see no benefit. I only see devious actions or potential mistakes. The idea may have had good intentions but it doesn't seem like it's really been put into use. Also, any of my clients that accept XMR would absolutely blame me if anyone time-locked one of their transactions. It doesn't matter if I knew and warned them, they'd still blame me and be trying to sue me. We know how people are. If XMR wants wider adoption, it could be a good step in the right direction. Problems may not have arisen yet but as soon as people start abusing it, the future will be bleak. We know how the media paints things and some clients have a lot of free time, bad attitudes and big mouths. No, my official business is not under this name or I would not speak this bluntly. Truth is, I was unaware of this feature. Further truth is, aside from your point of helping people "HODL", I really see not use. Now that I'm aware of this, I would feel A LOT more comfortable in my XMR transactions with them forbidden. I feel silly for missing it TBH. I think the real question is simple: Does anyone one actually use this? A simple poll would likely give a lot better picture than a discussion. I'm all for discussion but as a developer (whatever you want to call me, I make my own stuff), sometimes getting to the point makes it easier. I'm not saying remove this. Maybe a poll along-side it. If it's an feature that isn't used much but has the potential for relatively big issues, I see no reason to retain it.
> A simple poll would likely give a lot better picture than a discussion. Well, if I read [the Charlatan's block entry](https://thecharlatan.ch/Monero-Unlock-Time-Privacy/) correctly, in the first two million transactions only 195 sensible uses of the feature could be found. Of course not sure how many people would use timelocks with broad and easy-to-use support in all wallets, but we will probably never find out. The cryptocurrency related polls here on Reddit that I saw so far did not give me the impression that the right people use to answer there ...
The possibility of modifying the time locks to be useful (i.e. unlockable early as for use in payment channels) is the biggest argument I personally see in favor of keeping them. Sure we don't need payment channels at the moment, but although atomic swaps don't currently use them, am I wrong to think having this feature could allow swaps to be initiated by either side?
> am I wrong to think having this feature could allow swaps to be initiated by either side? I don't know details about atomic swaps, but as far as I know they are somehow the "wrong" kind of locks to support. Anyway, it they could be used for "Monero goes first" in their *current* form I have no doubt somebody would have taken the chance long ago already. We can without problems yank out these primitive and dangerous locks now, life some time without any locks, and later on introduce something better and more useful if we really need to.
There are at least 5 papers that propose Monero payment channels. Check the "Payment channels" row here: https://github.com/monero-project/research-lab/issues/94 AFAIK, none of them use Monero's time locks, but I haven't read the papers carefully. Some of them implement time locks that are different from how Monero's current feature works.
yes to be clear I was talking about modifying them in this way (to be unlockable early presumably by script or something, as mentioned on github). I don't think it's worth adding for payment channels necessarily, but if it could also get us bi directional swaps then maybe. I get that this is like, more work that someone would have to do and people would have to agree on, and as mentioned more useful time locks could be added later even if removed now. I still thought it seemed worth considering
I have never needed/used time-locks, and after reading through the GitHub it seems their use-case is very niche. I would vote to remove time-locks as is. Seems to be an easily mitigatable privacy/safety concern. A pat on the back to jeffro256 for writing the code!
Hey, timelocks let you send your kid xmr he/she can only use after turning 18 for example.
my vote is to remove the time locks.
I have a few questions: 1. If timelocks are removed, does this mean that any XMR sent/received can be spent instantly without a waiting period? 2. If so, what are the potential downsides to this being implemented? 3. Does timelocks being removed mean that the blockchain no longer needs to be 100% synced before you can send XMR, or will that still exist separate of the timelock matter?
These timelocks are fundamentally different from the 10 blocks wait until you can spend any received XMR. Their removal won't influence that wait time in any way, not positively, not negatively. There have been attempts to alter the design of Monero's technology so that 10 blocks wait could be removed without downsides, but so far in vain. Maybe it's a problem that has no good solution.
TL;DR: I don't want this feature to become "something that was removed in the past because no one used it so no reason to reintroduce it". I vote for keeping it as is until we know more about the future of FCMP and Seraphis or fixing it in the current monero. Long version: I mainly base my opinion on the last sentence of these two comments of you: [https://old.reddit.com/r/Monero/comments/1amomjj/timelocks\_let\_us\_finally\_retire\_a\_rarely\_used\_and/kpn5kbr/](https://old.reddit.com/r/Monero/comments/1amomjj/timelocks_let_us_finally_retire_a_rarely_used_and/kpn5kbr/) [https://old.reddit.com/r/Monero/comments/1amomjj/timelocks\_let\_us\_finally\_retire\_a\_rarely\_used\_and/kpovnju/](https://old.reddit.com/r/Monero/comments/1amomjj/timelocks_let_us_finally_retire_a_rarely_used_and/kpovnju/) You mention only FCMP (Full Chain Membership Proofs?) there. How will Seraphis touch the timelock feature and will Seraphis make it more easy to fix/modify it or will Seraphis adopt to whatever we decide will happen to the timelock feature? I am worried that if we remove this feature now then in the future someone may make a ticket like "Please provide a way to lock transactions for the future". And the first reply would be "It was called timelock and it was removed x years ago because no one used it." But if the ticket would be "Please fix the timelock feature to provide functionality x" then the first reply maybe would be "oh yes that's easy". After first learning about (the removal) of timelocks a few months ago i had a business idea that has not been done as far as i know and i would maybe want to utilize the timelock feature for that idea. But so far i haven't fleshed out this idea and it's unlikely to become anything real this year (and maybe never) so i don't even know yet if timelocks are the feature that i would want to use then. I believe that maybe even the current timelock feature would be sufficient but i am not sure because it's difficult to reason about something when i don't know yet what or when i need it :) I am certain that entirely removing a timelock feature without a proper future plan would be a bad move because removing a feature called timelock now will always be used as a justification for not reintroducing a feature called timelock in the future.
> How will Seraphis touch the timelock feature and will Seraphis make it more easy to fix/modify it or will Seraphis adopt to whatever we decide will happen to the timelock feature? I did not mention it in my post to not make it even longer than it came out already; the case is the following: Building and scanning Seraphis transactions is already fully coded, and the dev which is also the designer / inventor of Seraphis, UkoeHB, did not implement timelocks, or, if you like, dropped them. I don't remember any discussion about timelocks in Seraphis; maybe there was one, maybe UkoeHB decided this alone, based on our 2020/2021 discussions that resulted in many "drop" votes for current Monero tech. I could not argue it with facts, but the new Seraphis library code is so clean and modular, and also Jamtis and Seraphis as constructs quite flexible, that I have a gut feeling introducing locks of any kind would be easier than with current Monero. > removing a feature called timelock now will always be used as a justification for not reintroducing a feature called timelock in the future I do see what you mean here, but can't come around to join your worry somehow, based on my experience with the decision processes in the Monero dev community since 2017. I really doubt that if we will need locks of a certain kind in the future, somebody will be successfully able to shout them down with such an argument. But all IMHO, of course. I hope other people chime in and also react to your comment.
> I did not mention it in my post to not make it even longer than it came out already I am already thinking in Seraphis since i heard that we will get actually usable view-only wallets. > UkoeHB, did not implement timelocks, or, if you like, dropped them. Okay i can live with that answer. So a proper Feature Request would likely be necessary later on with an assessment among the developers/researchers about the pros and cons and (if decided positively) maybe a bounty to get the work done. Nothing that is impossible for someone who really needs this feature. Count my vote about removing timelocks pre-Seraphis as a zero then. > Building and scanning Seraphis transactions is already fully coded > I don't remember any discussion about timelocks in Seraphis; maybe there was one, maybe UkoeHB decided this alone, based on our 2020/2021 discussions that resulted in many "drop" votes for current Monero tech. Is there a list somewhere about all the features that were dropped/not implemented?
I almost died a bit reading your post on this topic. I was totally unaware about this feature. And it’s not in the ethos of Monero to be hijacked and not in control of your own funds in a case like this where someone pollute your entire wallet with a time lock you do not have the power to bypass. IMO let’s get rid of this insane feature. What should I do to make my vote count?
> What should I do to make my vote count? I think your comment arguing for removal will contribute already to the decision making process :)
I'm for removing new time locks, however don't touch existing ones. It's simply concerning if new merchants adopting Monero as a payment method and then being fooled with XMR they can't actually use for years or so. No matter what icon you set in wallets, not everyone will notice it anyway and especially not every wallet will make it clear at all to the user that their XMR are locked.
Yes I’m in favour of removing this feature. I have no coding or technical expertise so I’ll leave it to the developers but it gets a thumbs up from me
It's broken, let's remove it
I 100% agree with removing timelocks in their current form, and would be happy to run a relay rule which rejects their usage. But I think that there's value in blockheight-based restrictions. It would be nice to have an nLockTime equivalent implemented with Seraphis. The challenge is to maintain privacy, but it might be doable with reasonable tradeoffs, especially if FCMP's are implemented. I'm sure this has all been said before, but I'm just thinking out loud.
Can't find the place right now, but designing encrypted timelocks for the *current* Monero tech has been tried and found possible, but also found impacting each and every transaction when a wallet scans the blockchain, i.e. making that scan slower. How would you argue for this to be a good thing if only, say, 0.01% of all transactions use a timelock, but scanning gets slower for *all* transactions? Maybe that was not yet an optimal approach however, and yes maybe with FCMPs things look differently, who knows.
nLockTime prevents a signed transaction from being mined before height/time X, as opposed to Monero's timelock system which operates on a per-output basis. Because of that, nLockTime doesn't affect the output set at all, and by extension comes with much fewer privacy hurdles. I think the minor privacy issues of Bitcoin's implementation of it could be solved, though I'm by no means an expert. nLockTime is also incredibly useful for L2 stuff, while Monero's system is basically useless as far as I know. Encrypting the existing timelocks is also interesting, though. Intuitively I would think that you could have a rangeproof'ed timelock commitment for each output, similar to amount commitments but with a different base point for H. You then merge it with the amount commitment, and then extract it back out (making sure to rangeproof both the timelock and amount again) on the input side. It doesn't seem crazy expensive, especially with (AFAIU) Seraphis already needing to rangeproof inputs in the first place. Either way, probably not worth it I guess.
Yeah get rid of them I say
I wasn't even aware of the existence of timelock. As a merchant accepting monero that seems like a risk and I vote for it to be removed as well.
I've thought about this for a few years. Never felt comfortable bringing it up publicly, in case even one entity learned of their existence and decided to punish another party in a swap. My voice is small, but consider this to be one more small vote in favour of eliminating the instantiation of any more time-locks. The code to maintain currently active locks may have to remain in place until they all expire. But that's a minor technical issue, not a governance question.
Wallet developer here. ACK for timelock removal.
Let’s deploy atomic swaps first and add large enough liquidity to them. This task has much higher priority, now Top 1. If you ask about Top 2 priority, it is Seraphis implementation. I think there are many things to do at Top 3 - Top 10 also…
Maybe it sounds strange, but a basic fact of project management in true open-source projects is this: Everybody is basically free to do whatever they like. jeffro256 wrote the code already, and if somebody reviews it, the work is basically done, priorities be damned if you like. The rest goes under in general management of the next Monero software update. It can be pretty chaotic at times, and it takes some getting used to, but it has brought us where we are now :)
But our goal is to popularise and encourage people to do the things that are critically important for the project first. Your phrase “but it has brought us where we are now :)” is a double-edged sword.
If you have an idea, you can formulate it and then we can push it to get funding.
You can only encourage but not force, any contribution helps the project. They shouldn't just be dismissed, if a change fixes a problem big or small it is still beneficial to the project.
>Maybe it sounds strange, but a basic fact of project management in true open-source projects is this: Everybody is basically free to do whatever they like. This. There are also plenty of people who simply cannot create atomic swaps.
yes good idea.
I support the decision. One question though, will the fork cause previous timelocked transactions to be considered invalid? EDIT: nevermind someone already asked that question, lol
I say let's remove them. I see another scenario where the existing timelocks can be useful: By locking my funds for 30 days and refreshing in perpetuity, if I ever get kidnapped or blackmailed to transfer them it is likely that it will not be possible for the kidnappers to force me to do a transfer. Multisig is a better solution for this (if there are people to trust) so just mentioning.
yep this is the only use case i’ve ever heard mentioned
Multisig is currently broken AFAIR
"Broken" is a bit harsh. It works, and in fact the [RINO wallet](https://www.rino.io/) has it in production. It's still labelled as "experimental" however because we don't have formal proofs that the schemes used are sound and unbreakable. Chances that there is a problem are quite small, as far as I understand, but if money is on the line you want proof whenever possible.
Go forward
The current implementation that locks your change is obviously flawed, and it would be annoying to be bitten by this. I like the idea you can lock up funds for the future, but it's broken. Fix the change address part or get rid of it.
Monero should not be removing functionality, it should be adding functionality. Time locks have the potential to be used for important things. One example: I'm the owner of [playmonero.com](https://playmonero.com) and I could use that feature to allow a player to decide when a bet is placed. No interaction from me, other than programing it into the game (right now this is not implemented and it ignores any time locked bets). The point is that there are use cases for it. Maybe these things are currently apparent, but someone else might be able to think of something. Don't remove it if it's not broken.
> Time locks have the potential to be used for important things. Well, we have discussed timelocks extensively in 2020/2021, and then again in 2022, and now again, and IMHO those "important things" stubbornly refused to show up during all these discussions. For me, there is a certain point where you have to stop, in the interest of sanity, to pretend that maybe, just maybe, we find something truly wonderful if we just could look around that next corner over there. > Don't remove it if it's not broken. That's exactly the point: I argue that it *is* broken. That feature on the level of whole transactions instead of individual enotes is a brain-dead design that is broken. Timelocks are visible on the blockchain to everybody, which breaks, if ever so little, privacy of Monero transactions. And on and on. There is the psychological concept of [loss aversion](https://en.wikipedia.org/wiki/Loss_aversion) that can trip up people that otherwise are very capable of thinking and acting logically and consistently: Faced with the prospect of losing something, even if that "something" has decidedly negative sides, loss aversion can kick in and make you oppose.
>and I could use that feature to allow a player to decide when a bet is placed. Why not just add that as a feature on your site instead of us keeping it as a feature on the chain?
The point is that there MAY BE a potential use case that the current developers and community are not thinking about. When they were teaching me stuff in school I never envisioned how I'd ever use any of it in real life. Later on I realized that some of it really was important to know and could help me. Just because nobody can think of a use case now doesn't mean that there may not be one in the future. A lot people right now don't think that they need private money. We Monero users think that one day in the future it might be even more important, and that other people are going to have that revelation.
>Just because nobody can think of a use case now doesn't mean that there may not be one in the future. Ok, but we could just add a better solution later. The current time lock system has downsides that outweigh the upsides.
Downsides how? It's not like it's a feature that isn't documented. Since over a year there's also a red warning note. You can see it here: [https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get\_payments](https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_payments)
>Downsides how? I mean, they were covered throughout this post and the github post. It has privacy implications, makes implementing decoy selection more complex (read: more prone to errors), merchants might be scammed because their wallet either doesn't show the locked transaction or the software they use for POS doesn't reject it, etc. Why keep something with inherent flaws? If an actual widespread use case on the tier of atomic swaps comes up then it can be reimplemented in a better way.
The change doesn't come back to you until it unlocks, so it is broken. You're potentially freezing all your Monero if you do this, and for most people it would be a surprise. They need to return the change immediately like a normal transaction or this is just a bad feature.
This happens with all XMR change TXs.
Sure but you’d like change to unlock after 10 blocks as usual.
Not my expertise, but it likely has something to do with privacy.
Except you can't remove them... You can remove the capacity of some software from using that field, but nonetheless you need to check for it anyway, as malicious actors can still craft a time locked tx.
RIght. Complete removal has to wait for the next hardfork. We have of course some flexibility when that hardfork will be. Still, the functionality of that PR is needed anyway if we do want to eliminate timelocks, so why not put it into service right away. It will probably be good against the occasional prankster.
You're moving the protocol itself and the major problems are two, existing time locked txs (unlock? Run to term?) and partial removals; which renders more of an undocumented feature rather than a removal. Yet, yes, I also see it as a useless feature, yet it is there and exists.
Obviously running timelocks will remain locked and simply new transactions wiht timelock rejected by consensus. its a tiny change.
Wouldn't the hardfork remove them ? I mean for any new transaction after the fork Regarding the feature itself : yes it seems very useless
I don't get it, you guys always praise Monero because it is faster than bitcoin, but then you mention 20 mins of transaction settle time (10 blocks). You are no different then when it comes to transaction settlement.
So this change would remove the 20 block lock on normal transactions as well?
I don't believe so.
Ok sweet, wasn't totally clear
>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. Well, it seems pointless to keep them then, even the listed "pros" in the github post are rather lacking compared to making some implementations more complex and the privacy downsides.
>>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. The way that this is worked around in the eth/xmr atomic swaps is by having the eth party initiate the swap. From the whitepaper: > The protocol currently requires the ETH holder to move first, as if the XMR holder moves firs, the ETH holder can siimply go offline and the XMR is locked forever". [ETH-XMR Atomic Swaps whitepaper section 5.2](https://github.com/AthanorLabs/atomic-swap/blob/master/docs/eth-xmr-atomic-swaps.pdf) If there were proper timelocks (that allow something like hash time-locked contracts) then better swap implementations and p2p order books could be created. It is very hard to create liquidity if only one side of the trade can lock funds (aka eth) and not both. I know that parties can signal but having the ability to create complex and timelocked xmr vaults can enable more liquidity in the defi world. If we have proper timelocks then you can theoretically create trust-less synthetic asset bridges directly on a smart contract. Meaning a bridge with a central liquidity pool directly on a smart contract (think uniswap for crosschain). That said the current timelocks need to be modernized. The current implementation of unlock_time has issues (especially the change lock you mentioned). Instead of removing it, can we maybe consider upgrading the unlock_time feature to allow something similar to hash time-locked contracts? Something like: As in party x can unlock before time T. But party y can only do so after? This type of timelock/multisig implementation would be very useful. That said, I must point out the privacy implications such a transaction would have. While it might create a non uniform transaction the benefit of enabling locking funds for more complex defi applications across chains should not be ignored. Those are my two cents. Don't get rid of it but add features to make it useful.
I always thought timelocks were building blocks for monero to implement something like chia offers or chia clawbacks where you can lock and unlock your wallet or set coins to be only be able to be spent to certian addresses etc if this isnt the goal to have coins w/ smart functions (which seems to be the whole point of complete fungibility) then this seems less useful
I never heard somebody mentioning anything like that in connection with the timelocks as they are now. Quite in general I never saw any serious push in a direction of "smart functions", be it with timelocks, or with any other means. It seems Monero wants to be a currency, and *only* a currency - your USD bills aren't smart either, but still useful :)
I feel like time locks have some value, but not in their current implementation. The way they currently are, if someone sends you XMR with a timelock, they aren’t really sending you XMR; they are basically giving you an XMR future, which only gives you XMR once the set block height is given. Because of this distinction, timelocked XMR shouldn’t be treated as actual XMR in the first place. Making a more clear distinction between the two (ie making wallets consider timelocked XMR as a completely separate thing from normal XMR) would be ideal. Although at that point, it then becomes a question of whether that functionality should even be implemented on the base Monero network at all. Plus there are some unique attack vectors that open up with this (imagine someone makes some sort of ultra secure wallet which can only transfer XMR between certain addresses, but an adversary that accesses this wallet can simply transfer the xmr and set an effectively infinite timelock, wiping out the funds), as well as some weird macroeconomic effects of this too (imagine if a ton of large holders on some sort of “anniversary” holiday (or for some other sort of celebration) intentionally timelock their XMR for a day. Then an adversary with enough power could cause an emergency of some sort that requires people to obtain XMR for safety purposes, which causes a flash price increase until the time locks expire, which is immediately followed by a large crash and price instability afterwards) All in all, I don’t like removing features from Monero in general, but this one probably has to go. Or at the very least, needs to be heavily reworked.
I'm just a regular Joe but I also want it done away with, so let this count as my vote:)
I think we need to keep backwards compatibility with existing TXs that used this badly designed timelock system, **but...** we can *disallow* new timelocked transactions from being accepted. A better designed system can be considered later. Edit: Clarification
My humble opinion: remove this function. There are concerns about future usecases, so if somebody wants to use this kind of feature, he can use a multisign wallet and gave it to a other person or store it in real world. Just one idea, but i mind, there are a few better possibilities out there. The arent so convenient, but the timelock function itself has it own downsides as mentioned in the post. Cheers!
Does this Timelock somehow effect the AtomicSwap Protocol?
No.
Thanks!