Use recent block times for unlock time by moneromooo-monero · Pull Request #6745 · monero-project/monero

moneromooo-monero · 2020-08-05T14:31:17Z

From an original patch by TheCharlatan.

UkoeHB · 2020-08-07T12:52:04Z

Is removing the static cast for time(NULL) ok/intended here?

Also, according to the other changes in this PR get_adjusted_time() will return the median of the last 60 blocks' timestamps.. which should be 30 blocks ago (60 minutes ago) on average. Not the current time. Am I missing something or this broken?

One way to fix this is to estimate the current time from the median block's time.

//approximate the time (in UTC) of the current block based on the block that should be positioned at 1/2 of the blockchain check window, and how often blocks are produced on average //using the median means the 'height' block author can't manipulate their timestamp to significantly affect the return value from this function ... get_adjusted_time(m_db->height()) + static_cast<uint64_t>((BLOCKCHAIN_TIMESTAMP_CHECK_WINDOW/2) * (get_ideal_hard_fork_version(height) < 2 ? DIFFICULTY_TARGET_V1 : DIFFICULTY_TARGET_V2)) ...

Honestly it's a bit messy, so maybe add a function. The terminology is really mixed up here since the behavior of get_adjusted_time() should really be in a function called get_timestamp_check_median_time(), and get_adjusted_time() should return the approximate time of the current block and call get_timestamp_check_median_time() internally.

Can't recall. It seems pointless anyway.
The whole point is to start using blockchain timestamps instead of local time. This is intended. A 30 minute delay is fine, since this is typically used to lock things long term, not for a few minutes I think ? Define broken. Adding an offset would need changing some tests IIRC, and means you might unlck too early instead of too late. Why do you think this may be needed ?

By 'broken' I meant 'unintended consequences'. It sounds like the changes are intentional.

"A 30 minute delay is fine, since this is typically used to lock things long term, not for a few minutes I think ?" Presumably if someone is locking a transaction with UTC time, they are trying to be more precise than a block height lock could provide. As the PR stands, users will have to wait an extra 60mins on average for their outputs to be unlocked (relative to the unlock time).

It sounds like you are concerned about future times being used for timelock checks. What about correcting the offset by doing a minimum of the current block's block time and the median block's time + 60mins? If blocks are accelerating then the current block's time will be more accurate than the median + 60, if the current block has a future time then the median + 60 should be closer to the real time, and if blocks are decelerating then authors will have to wait a few extra minutes to spend their outputs.

Note that even without the offset someone who can manipulate the median could push it into the future up to +1hr (since block times are limited by local_time + 2hr according to check_block_timestamp()). Adding the corrected offset allows timelocked tx to be spent up to 2hrs early in the worst case, while being much closer to +/- 10mins in the typical case.

The concern goes in both directions, faster and slower blocks, meaning both block timestamps into the future and the past. I'd argue a window of +-60 minutes is the time precission that we can provide and that it is good enough. If you lock a transaction's outputs with unix time exactly a year into the future, you get a guaranteed precision of +-60 minutes, while if you use blocks, the precision is unknown and could vary days.

Having the ability to push the median significantly would probably be at the limit of our security boundaries, since it is miners that are pushing it. I have not done any statistics on this though.

Sorry, rather than 'current block' for corrected offset it should be 'previous block + 2mins' since the current block may be under construction and we don't want to use local time.

Well, +/- 60mins might be ok, but I'm wondering why not push for even more precision if it's possible?

I spent a bit of time going through some of the potential problems with koe's proposal and think it is safe enough to go with it. It does introduce some extra complexity though and detecting a few of the corner cases has been challenging. The proposal does allow a miner to block inclusion of a time locked transaction into the next block by setting a low timestamp of his own mined block. In the current protocol, there are no incentives or rewards gained by doing this. Given this added complexity I would like to get a bit more review here.

To get the adjusted time I think it should be like this:

// project the median to match approximately when the block being validated will appear // the median is calculated from a chunk of past blocks, so we use +1 to project onto the current block median_ts += (BLOCKCHAIN_TIMESTAMP_CHECK_WINDOW + 1) * DIFFICULTY_TARGET_V2 / 2; // project the current block's time based on the previous block's time // we don't use the current block's time directly to mitigate timestamp manipulation uint64_t adjusted_current_block_ts = m_db->get_block_timestamp(height - 1) + DIFFICULTY_TARGET_V2; // return minimum of ~current block time and adjusted median time // we do this since it's better to report a time in the past than a time in the future return (adjusted_current_block_ts < median_ts ? adjusted_current_block_ts : median_ts);

Note: on the odd looking +1 in median_ts... imagine:

window = 2, blocks are indexed b0, b1, b2; block b2 is being validated; median of window is at timestamp (b0 + b1)/2 = 0.5b; adding offset of window/2 means adjusted timestamp would be 1.5b so we need to add another 0.5b -> 0.5b + (window + 1)/2 = 2b

window = 3, blocks are indexed b0, b1, b2, b3; block b3 is being validated; median of window is at timestamp 1b; adding offset of window/2 means adjusted timestamp would be 2.5b so we need to add another 0.5b -> 1b + (window + 1)/2 = 3b

I assume adjusted_current_block_ts and previous_block_ts are the same variable here, right ?

Pushed with that change.

UkoeHB · 2020-08-07T13:56:57Z

Suggested change

if(b.timestamp > (uint64_t)time(NULL) + CRYPTONOTE_BLOCK_FUTURE_TIME_LIMIT)

{

MERROR_VER("Timestamp of block with id: " << get_block_hash(b) << ", " << b.timestamp << ", bigger than adjusted time + 2 hours");

if(b.timestamp > (uint64_t)time(NULL) + CRYPTONOTE_BLOCK_FUTURE_TIME_LIMIT)

{

MERROR_VER("Timestamp of block with id: " << get_block_hash(b) << ", " << b.timestamp << ", bigger than local time + 2 hours");

UkoeHB · 2020-08-07T14:17:36Z

Why was this declaration moved up 400 lines? New spot seems less appropriate based on other declarations nearby.

To make it public.

I guess I could add public: and private: and keep it where it was though. Seemed a bit meh but it minimizes the diff...

Ah if it's being made public that makes sense.

UkoeHB · 2020-08-07T14:19:32Z

Looks like terminology confusion again, since 'adjusted_time' has been changed to mean 'median time of last 60 blocks'. Which makes the behavior here change.

Looks like it was already broken. I'm not sure why it's adding that define. The threshold really should be adjusted_time. If you can't think of why the define gets added either, I'll remove.

Not sure what you are referring to. Define?

I think we should rename it to locktime_median_time_past or something along those lines to avoid confusion.

By define, I meant adding CRYPTONOTE_LOCKED_TX_ALLOWED_DELTA_SECONDS_V2 etc. I don't see what purpose this has.

Is this a Chesterton's fence? It does feel like an idea that didn't get fully fleshed out. It has been there ever since the original fork.

On second thought, it doesn't hurt anything either. So as you imply, safer to keep it in at least for now.

The name seems clear to me. It's getting the adjusted time from the daemon, not the current time.

UkoeHB · 2020-08-07T14:20:35Z

Is this 3-parameter overload of check_block_timestamp() being deprecated? If so, might be nice to remove it completely.

It looks like it's still used.

UkoeHB · 2020-08-07T14:21:19Z

Behavior change

Looks like the same as the one above. I think I might be missing your point though, since the point of the patch is to change the behaviour. So can you expand on whether you think something else (than the addition) is wrong ?

Sorry, just pointing out that every use of 'adjusted_time' is really '60 mins ago on average'. Since they are all replacing 'current time' the behavior changes.

UkoeHB · 2020-08-07T14:22:17Z

Why was const removed from all of these functions?

Because they now call RPC.

UkoeHB · 2020-08-07T14:24:50Z

Behavior change

selsta · 2020-08-07T20:24:36Z

Is the unbound submodule update intended?

moneromooo-monero · 2020-08-08T10:05:31Z

No. Not sure how it ended up here, thanks.

moneromooo-monero · 2020-08-08T12:57:45Z

Ah, I found the behaviour change, a place is changing this without checking for v13. Will fix.

Sign in to view

dEBRUYNE-1 · 2020-08-28T14:44:08Z

Fyi, has conflicts with src/cryptonote_config.h as far as I can see.

moneromooo-monero · 2020-09-09T19:11:13Z

Now with the expected extra time. I'll rebase later since that'll pollute the diff massively.

moneromooo-monero · 2020-09-09T19:12:16Z

I do not have the space to sync another chain here, it would be nice if someone could try a full sync to make sure this does not break historical blocks :)

moneromooo-monero · 2020-09-10T01:22:47Z

I'm wondering whether this change can lock an ouput after it was unlocked, if the adjusted time goes back in time (ie, a new block has an earlier ts than the one 60 block ago). That could be annoying.

sedited · 2020-09-10T01:32:43Z

If the last block is re-orged then sure, this can happen. However this is even true if you take just the median block times without additional modification. As long as the time used for the validation is relative to whatever the state is when the transaction is first included in a block, a change of the time into the past in a later block does not matter.

UkoeHB · 2020-09-12T17:48:34Z

This comment is out of date, otherwise everything looks good.

/** * @brief get the "adjusted time" * * Computes the median timestamp of the previous 60 blocks, projects it * onto the current block to get an 'adjusted median time' which approximates * what the current block's timestamp should be. Also projects the previous * block's timestamp to estimate the current block's timestamp. * * Returns the minimum of the two projections, or the current local time on * the machine if less than 60 blocks are available. * * @return current time approximated from chain data */

xiphon · 2020-09-15T02:07:12Z

Suggested change

uint64_t adjusted_current_block_ts = m_db->get_block_timestamp(height - 1) + DIFFICULTY_TARGET_V2;

uint64_t adjusted_current_block_ts = timestamps.back() + DIFFICULTY_TARGET_V2;

Based on a patch by TheCharlatan <seb.kung@gmail.com>

UkoeHB suggested changes Aug 7, 2020

View reviewed changes

moneromooo-monero force-pushed the dul branch from bf39d76 to 3d423fc Compare August 8, 2020 18:34

sedited reviewed Aug 28, 2020

View reviewed changes

Comment thread src/cryptonote_core/blockchain.cpp Outdated

This comment was marked as resolved.

Sign in to view

moneromooo-monero force-pushed the dul branch from 3d423fc to 6ee9003 Compare August 28, 2020 11:59

moneromooo-monero force-pushed the dul branch from 6ee9003 to edf9e24 Compare September 9, 2020 19:10

moneromooo-monero force-pushed the dul branch from edf9e24 to 7f0b685 Compare September 12, 2020 13:34

UkoeHB reviewed Sep 12, 2020

View reviewed changes

moneromooo-monero force-pushed the dul branch from 7f0b685 to b09e34e Compare September 12, 2020 19:34

UkoeHB approved these changes Sep 13, 2020

View reviewed changes

moneromooo-monero force-pushed the dul branch 2 times, most recently from b695126 to c903435 Compare September 14, 2020 23:28

selsta approved these changes Sep 14, 2020

View reviewed changes

xiphon reviewed Sep 15, 2020

View reviewed changes

moneromooo-monero and others added 2 commits September 15, 2020 11:40

blockchain: deterministic UNIX time unlock checks

4971219

Based on a patch by TheCharlatan <seb.kung@gmail.com>

wallet2: adapt to deterministic unlock time

80e535c

moneromooo-monero force-pushed the dul branch from c903435 to 80e535c Compare September 15, 2020 11:41

selsta approved these changes Sep 15, 2020

View reviewed changes

UkoeHB approved these changes Sep 15, 2020

View reviewed changes

luigi1111 merged commit ea587de into monero-project:master Sep 16, 2020

stoffu mentioned this pull request Oct 20, 2020

blockchain: deterministic UNIX time unlock checks /monero#6745 aeonix/aeon#201

Merged

Rucknium mentioned this pull request Feb 27, 2024

Monero Research Lab Meeting - Wed 21 February 2024, 17:00 UTC monero-project/meta#970

Closed

-  if(b.timestamp > (uint64_t)time(NULL) + CRYPTONOTE_BLOCK_FUTURE_TIME_LIMIT)
-  {
-    MERROR_VER("Timestamp of block with id: " << get_block_hash(b) << ", " << b.timestamp << ", bigger than adjusted time + 2 hours");
+  if(b.timestamp > (uint64_t)time(NULL) + CRYPTONOTE_BLOCK_FUTURE_TIME_LIMIT)
+  {
+    MERROR_VER("Timestamp of block with id: " << get_block_hash(b) << ", " << b.timestamp << ", bigger than local time + 2 hours");

	uint64_t adjusted_current_block_ts = m_db->get_block_timestamp(height - 1) + DIFFICULTY_TARGET_V2;
	uint64_t adjusted_current_block_ts = timestamps.back() + DIFFICULTY_TARGET_V2;

Uh oh!

Conversation

moneromooo-monero commented Aug 5, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

UkoeHB Aug 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

UkoeHB Sep 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

UkoeHB Aug 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

selsta commented Aug 7, 2020

Uh oh!

moneromooo-monero commented Aug 8, 2020

Uh oh!

moneromooo-monero commented Aug 8, 2020

Uh oh!

This comment was marked as resolved.

Uh oh!

UkoeHB Aug 8, 2020 •

edited

Loading

UkoeHB Sep 11, 2020 •

edited

Loading

UkoeHB Aug 8, 2020 •

edited

Loading

UkoeHB Sep 12, 2020 •

edited

Loading