Skip to content

Conversation

@lightwalker-eth
Copy link
Member

No description provided.

@vercel
Copy link

vercel bot commented Aug 5, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
examples.nameguard.io ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 13, 2024 8:41pm
nameguard.io ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 13, 2024 8:41pm
namehashlabs.org ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 13, 2024 8:41pm
storybook.namekit.io ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 13, 2024 8:41pm

@changeset-bot
Copy link

changeset-bot bot commented Aug 5, 2024

🦋 Changeset detected

Latest commit: 54ab2d3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages
Name Type
@namehash/ens-utils Minor
@namehash/namekit-react Minor
@namehash/nameguard-js Patch
@namehash/nameguard-react Patch
@namehash/nameguard Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

return false;
if (releaseTimestamp && releaseTimestamp.time > atTimestamp.time) {
// if the name is not yet released, we can't register it
// TODO: check for possible off-by-1 errors in the logic above
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lightwalker-eth can you extend on off-by-1 spec?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to see how ENS smart contracts actually work. Ex: Actual expiration time? 1 second earlier? 1 second later?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above implements seems correct due to the following ENS SC reference:

Captura de Tela 2024-08-06 às 21 01 31

Conclusion: both functions are saying a domain registration's timestamp needs to be greater than a domain's releaseTimestamp


// first label must be of sufficient length
return charCount(name.labels[0]) >= MIN_ETH_REGISTRABLE_LABEL_LENGTH;
if (releaseTimestamp && releaseTimestamp.time > atTimestamp.time) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (releaseTimestamp && releaseTimestamp.time > atTimestamp.time) {
if (releaseTimestamp && releaseTimestamp.time >= atTimestamp.time) {

return charCount(name.labels[0]) >= MIN_ETH_REGISTRABLE_LABEL_LENGTH;
if (releaseTimestamp && releaseTimestamp.time > atTimestamp.time) {
// if the name is released, we can't renew it anymore
// TODO: check for possible off-by-1 errors in the logic above
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Captura de Tela 2024-08-06 às 20 16 40

This function was extracted from BaseRegistrar and reveals that above logic could look different: added a commit suggestion above!

atTimestamp.time < existingRegistration.registrationTimestamp.time
) {
// if the renewal is requested before the registration, we can't renew it
// TODO: check for possible off-by-1 errors in the logic above
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK...

I'd say there is no problem with current logic.

If atTimestamp is the same than registrationTimestamp, it is already possible to renew it for longer periods, meaning canRenew should go on in the function scope, but, if it is smaller, it really is not possible to renew this domain: as per my review this has achieved its goal.

throw new Error(`Invariant violation`); // TODO: refine message... just making the type system happy.
}

// TODO: review for possible off-by-1 errors
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our logic seems to implement the same as below:

Captura de Tela 2024-08-06 às 20 29 09

When summing expiries[id] + duration to determine the new timestamp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants