I discovered an issue with deterministic ring members: unlock time. Since any output could potentially be locked, if you deterministically select a locked output then you have to rewind tx building pretty far. That alone isn’t a deal-breaker, but binning makes it a big problem. What if the local outputs around the output you want to spend are all locked? There might not be enough decoy outputs available to make a bin

with the real spend in it. This opens a serious attack vector. IMO the only real solution is to deprecate the unlock_time field (only keep the 10-block lock time). A big question there is coin base outputs, which have 60-block unlock_time by consensus. Would it be safe to reduce that to the default 10 blocks?

An alternate solution would be hidden lock times, so the lock time of ring members is irrelevant. That invites non-trivial tx scaling costs.

Btw does anyone know if atomic swaps are using unlock_time? Are there any other usecases?

Monero atomic swaps do not use any timelock on the Monero side of things.

Thanks kayabaNerve :)

One thing to consider is in the long run it would be nice to move to arbitrary ref set sizes (eg all the outputs on-chain, like ZCash) if research takes us there. However, it isn’t guaranteed timelocks will be compatible with that tech.

UkoeHB: "arbitrary ref set sizes (eg all the outputs on-chain, like ZCash)"

Is that possible? I have been thinking about this as I have been examining the mixin selection issue. Relying on statistical obfuscation will continue to have its limitations, regardless of any improvements I come up with.

It isn’t possible with current research afaik, otherwise we would be pursuing it.

Hopefully Halo2 on Orchard will give some hints.

"Hello? Yes, please proceed with holy grail integration"

Resistance to statistical attack will probably continue to be a weak point for Monero unless the privacy model is changed.

UkoeHB: that's a good spot. That would've been an issue with the naive approach I was thinking too. It does seem like it can be avoided with the Moser paper's general approach to constructing bins on the node. You could keep locked outputs in a queue before assigning them to bins when unlocked, but this would basically defeat the purpose of binning close outputs together (and also may have other problems with ordering I'm not

seeing)

>You could keep locked outputs in a queue before assigning them to bins when unlocked

Actually, could just hold off on assigning an output ID until an output unlocks

the case to remove lock times here is pretty strong imo: monero-project/research-lab #78

jberman[m]: do you mean like append them to the output set when they become unlocked?

yep that's what I was thinking

Hmm yeah it could work, append a locked tx to the block that’s 10 blocks before it gets unlocked. Then when the default lock time is up, the output’s lock time will line up with the first block that can spend it.

but the locked output isn't being spent .... ?

?

this is prolly due to my lack of maths with ring sigs, but if you select an output as a decoy, does the unlock time matter?

Yeah. If a tx references an output that is locked, consensus will reject the tx.

ah, so the locktime itself isn't obfuscated / buried in some way

They're in the clear

It's possible to obscure them via an extension to signatures, but this incurs significant cost

I do think it would make sense to hold off on appending an output to the output set until it's unlocked. You would expect a miner and/or user to spend their outputs closer to when they unlock, so it actually would make sense to see someone spend a recently unlocked output that has a very long lock time around the same time as a user who spends an output that unlocks after 10 blocks. It probably makes even more sense that they

would be members of the same bin (rather than a recently unlocked output with a very long lock time being in the same bin as a very old output with the default unlock)

Yeah I had a similar thought. Plus, currently, outputs with long lock times are far less likely to be used as decoys than normal outputs, since they only become available once unlocked (i.e. the tail end of the selection distribution).

It could be used for a timing-targeted decoy poison attack.

Yep, true

Either deprecating custom lock times or obfuscating seem to be the best options

it would probably still make sense to hold off on adding coinbase outputs to the output set until they unlock for the above reasoning, but the benefits of doing that probably aren't that significant

Updated the MRL issue: monero-project/research-lab #78#issuecomment-913046076

+1 for encrypting or removing unlock_time. I would lean towards the latter but could be convinced otherwise if there's a strong use case articulated for encrypting and keeping the feature.

I'm excited about all the decoy research, we're overdue for an overhaul :- )

are there any non niche use cases for time locks?