search

serai-dex / serai

Other
263 stars 49 forks source link

Support time-based Monero timelocks #104

Closed kayabaNerve closed 1 month ago

kayabaNerve commented 2 years ago

This requires being able to obtain the time from the Monero blockchain, according to its rules.

SamsungGalaxyPlayer commented 2 years ago

What do you mean by support? Nodes will need to know to identify these transactions to prevent malice at the minimum.

kayabaNerve commented 2 years ago

We don't support identifying if they've already passed or not. It's a Monero library feature I expect to never see used. Serai explicitly checks no timelock is present, and any timelock, block or time based, will faill that check.

SamsungGalaxyPlayer commented 2 years ago

Good :) I see no reason to support timelocks other than knowing how to spot and flag/block them. Since that's already done, ✅

kayabaNerve commented 11 months ago

The processor does currently calculate Monero's network time upon genesis (as Serai needs to specify a Monero starting block, with no context of any Monero block, so the block is the earliest one with a time after Serai's time). This could be moved to monero-serai but the calculation is too expensive to not cache somehow.

j-berman commented 10 months ago

AFAICT the reason to support this in monero-serai today is so that multiple Serai nodes can be certain that as long as no reorg has occurred on the Monero chain, all Serai nodes know that a Monero output that could be used as a decoy is unlocked by a specific height, even if all respective Monero nodes have different chain sizes past that specific height.

Instead of getting the time from the Monero blockchain at a specific height, which is not currently supported via RPC request, and instead of maintaining logic in monero-serai that requires correctly checking that a time-based Monero output is unlocked, I think it would be simpler if the Monero get_outs RPC accepted a height request param and returned output's unlocked status using that height.

I included the above suggestion as a TODO in #384.

kayabaNerve commented 10 months ago

Right. This would allow deterministic derivation of whether or not an output is unlocked for the ~100 outputs on chain which use timelocks.

kayabaNerve commented 1 month ago

https://github.com/serai-dex/serai/blob/2c8af04781d5dd5ebef55d60674233035da59e4c/processor/monero/src/rpc.rs#L53-L89 is the algorithm for this (ignoring how it collapses None to 0). Please note how it makes 60 RPC calls.

When scanning, users can allow outputs with a timelock if they specify the time to allow. With regards to decoys, the RPC can trust the remote node. If someone wants to build a deterministic RPC which uses the above algorithm (in whatever inefficient, or efficient via some cache, manner), they have that ability thanks to the DecoysRpc abstraction.

The fact it's all technically possible, combined with timelocks being deprecated (https://github.com/monero-project/monero/pull/9151) and time-based timelocks planned for removal, makes me fine marking this won't fix. The concerns about the slight privacy fingerprint to the deterministic decoy selection algorithm are absolved with FCMPs anyways.