Community close to reaching consensus on Monero's timelocks deprecation
After a year of research and discussions1, the community is close to reaching consensus on what to do with Monero’s timelocks (
Here’s a big picture of everything:
Each XMR transaction has inputs and outputs:
Outputs are the amounts available for further spending.
Inputs are selected from
nprevious transaction outputs.
unlock_time field is part of all XMR transactions and it dictates when a transaction’s outputs can be spent again, depending on its value:
- a value of
0means funds can be spent immediately (after the standard 10 block maturity period)
- if it’s below
500'000'000, it is interpreted as a block height and compared with the current block height
- values above
500'000'000are interpreted as Unix time in seconds (relative to the local time of the monero node machine)
TheCharlatan2 has discovered vulerabilities linked to Monero’s timelocks in April 2020, while reading through the C++ code comments:
Monero inherited a largely uncommented source code from the original cryptonote developers. Particularly hazy areas are commented with either //TODO or //FIXME.
He also urged others to review the code in an effort to identify other potential bugs:
I would strongly recommend other security researchers to take a tour through these. There are roughly 120 TODOs and 30 FIXMEs left, so there may be more to find.
Recently (12 September), two of his HackerOne reports have been publicly disclosed:
- Hardware Wallets Do Not Check Unlock Time (#8172453)
- Unix time unlock_time values have dangerous validation rules enabling a number of exploits (#8547264)
He published 3 blog posts5 related to the issues, here are the TLDR’s:
A lack of unlock time verification on the monero hardware wallets could have allowed a compromised host to permanently lock up a user’s XMR after a transaction. Both Trezor and Ledger patched the issue.
[..] transaction unlock_time values were interpreted with local time, allowing a host of non-critical exploits targeting the integrity of the blockchain.
Both Ledger and Trezor have patched the issue.
All the known issues have been patched in Monero v0.17.00. No evidence of actual issue-related harm towards user funds was found.
Although the bugs have been fixed for some time,
unlock_time is still detrimental to Monero user’s privacy.
The community has been exploring a few possible solutions:
- 1 - Deprecate/remove timelocks
- 2 - Encrypt
- 3 - Tweak/improve the current implementation
Valid use cases of
unlock_time are rather limited, currently. The main ones seems to be its use as a proof of unspent funds and as a potential subscription model.
Contrary to what some may believe, COMIT’s XMR-BTC atomic swap implementations is not based on the existence of Monero timelocks, as suggested in their paper8.
- timelocks can be re-added to Monero in the future, but it would more difficult to implement
- if the community decides to eliminate timelocks, this could happen in one of the next few hard forks
- it seems that
unlock_timeis also a barrier to a decoy selection binning9 implementation, according to j-berman10
The community seems to be almost ready to deprecate timelocks altogether.
If you can think of any other valid use cases or compeling reasons for not removing
unlock_time or if you have any other suggestions, you can still post a comment on Github11, Reddit12 and attend the next MRL & Dev meetings13.
https://github.com/monero-project/meta/issues/519, https://github.com/monero-project/meta/issues/610, https://github.com/monero-project/meta/issues/613, https://github.com/monero-project/meta/issues/614 ↩
https://thecharlatan.ch/Wallet-Timelock/, https://thecharlatan.ch/Monero-Unlock-Time-Vulns/, https://thecharlatan.ch/Monero-Unlock-Time-Privacy/ ↩