Reject claiming of revoked name immediately about aeternity HOT 7 OPEN

My general opinion is that the node should not accept a TX if (is known to be) would be then dropped immediately from the pool. I'm not very familiar with the NS protocol to comment on the specific issue.

from aeternity.

Isn't this one different, though? A revoked name is only blocked for a period of time, right? While a non-payable account is never going to become payable.

Still, it could be added, but it would need a bit of logic comparing the TX TTL to the revoke-height, etc. Would be a bit finicky to test 🤔

from aeternity.

A revoked name is only blocked for a period of time

I was thinking that it is forever, but protocol says it is revoked only for 4 days.

comparing the TX TTL to the revoke-height

Won't be more accurate compare a minimum between TX TTL and max amount of blocks a TX can stay in mempool?

from aeternity.

You also have the case where there is a PreClaim involved, that is only valid for 300 generations (I think??) - so lot's of cases to cover in testing... Is it worth it?
cc @happi @dincho @ThomasArts

from aeternity.

I don't think this should be solved on the node level.
If you claim a revoked name, you must have a reason to do so. For example, you may want to have that name. If you then claim it before the revoke period is fully completed, just to be sure to be the first with that claim, then posting it a bit earlier and have it in the mempool until you get allowed would make sense.

I think a reasonable wallet could warn a user that the name they try to get has been revoked and won't be available until .... The user is then free to choose whether to post it or not. If the transaction gets rejected and disappears from the pool, then the wallet may have a strategy to resend.

Otherwise, we are making nodes more and more complex to test, get all kind of exceptional logic for all kind of corner cases optimizations. I would dislike that.

from aeternity.

I agree in general with @ThomasArts as well, however the logic for that validation is already there, but runs on mempool level

from aeternity.

then posting it a bit earlier and have it in the mempool until you get allowed would make sense

To address this case, the node may compare tx's ttl with a block at which the name would be available. And still, reject a tx if the ttl is too small or if ttl is 0 but tx would be removed from mempool by timeout.

For historical reasons, sdk tries to be developer-friendly by validating transactions before submission. A stuck tx in mempool without an error message is a poor developer experience as I see. If the node won't have a such check then it looks consistent to implement it on the sdk side, but it is expensive because it requires an extra http request.

Actually, the node doesn't expose a block height at which the name would be available

// http://localhost:3013/v3/names/cQ6QywWtsqEyo8AwktmdK8DShhkRBH.chain
{
  "reason": "Name revoked",
  "error_code": "name_revoked"
}

from aeternity.