Community close to reaching consensus on Monero's timelocks deprecation

After a year of research and discussions¹, the community is close to reaching consensus on what to do with Monero’s timelocks (unlock_time) implementation.

Here’s a big picture of everything:

The basics

Each XMR transaction has inputs and outputs:

• Outputs are the amounts available for further spending.

• Inputs are selected from n previous transaction outputs.

The 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 0 means 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'000 are interpreted as Unix time in seconds (relative to the local time of the monero node machine)

Vulnerabilities

TheCharlatan² 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 (#817245³)
• Unix time unlock_time values have dangerous validation rules enabling a number of exploits (#854726⁴)

He published 3 blog posts⁵ 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.

Proposed fixes

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 unlock_time
• 3 - Tweak/improve the current implementation

j-berman⁶ shared an overview of the pros and cons for each of the above in MRL issue #78⁷.

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 paper⁸.

Notes

• 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_time is also a barrier to a decoy selection binning⁹ implementation, according to j-berman¹⁰

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 Github¹¹, Reddit¹² and attend the next MRL & Dev meetings¹³.

Update: community to vote for removal of timelocks¹⁴.