[alias docs] Better language and implementation rule for possible price changes
ClosedPublic
Actions

Authored by bytesofman on Jul 14 2023, 17:27.

Details

Reviewers

emack
Fabien

Group Reviewers

Restricted Project

Commits

rABCdc76a6995ca1: [alias docs] Better language and implementation rule for possible price changes

Summary

Best case scenario, alias pricing never changes. However, we want price changes to be possible. We also want to ensure that valid alias registrations are not invalidated by a price change.

Hence, any price change will need to come into effect for alias registrations confirmed in a specified blockheight.

1000 blocks is arbitrarily chosen as a minimum notice period. This allows alias-server to provide a stateful price response that Cashtab may parse for assessing whether or not its registration txs are valid.

Test Plan

Review for typos, comment if 1000 blocks seems inappropriate, comment any questions or ambiguity about how this could work

Diff Detail

Repository

rABC Bitcoin ABC

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

bytesofman created this revision.Jul 14 2023, 17:27

Herald added a reviewer: Restricted Project. · View Herald TranscriptJul 14 2023, 17:27

bytesofman requested review of this revision.Jul 14 2023, 17:27

Harbormaster completed remote builds in B24498: Diff 41450.Jul 14 2023, 17:27

better language

Harbormaster completed remote builds in B24500: Diff 41452.Jul 14 2023, 17:51

bytesofman mentioned this in D14247: [Cashtab][Alias] Switch alias registration fee lookup to api.Jul 14 2023, 17:51

emack added a subscriber: emack.Jul 15 2023, 00:19

emack added inline comments.

doc/standards/ecash-alias.md
60 ↗	(On Diff #41452)	We're not changing a schedule, but rather the fees themselves
62 ↗	(On Diff #41452)	Since pricing validation has been deprecated from Cashtab, that means the only check Cashtab needs to do is ensure the response from the pricing API has `validThru <= blockheight` right? If it was > blockheight then throw an exception on the pricing API call as this would mean Cashtab was connected to an out of date alias-server?

emack added inline comments.Jul 15 2023, 00:22

doc/standards/ecash-alias.md
60 ↗	(On Diff #41452)	unless you mean a schedule as in an appendix to a legal document, then pls ignore comment

more clarity

bytesofman marked 2 inline comments as done.Jul 15 2023, 04:11

bytesofman added inline comments.

doc/standards/ecash-alias.md
62 ↗	(On Diff #41452)	Cashtab will have to ensure that the `currentBlockheight <= validThruBlockheight + someSafetyIntervalSayFiveBlocks` at the time a registration tx is broadcast Practically, we probably won't really ever hit this edge case with Cashtab --- because alias-server and Cashtab and this spec are all in the monorepo and coded / reviewed by understanding parties. However, other implementations may be different.

Harbormaster completed remote builds in B24503: Diff 41455.Jul 15 2023, 04:11

emack accepted this revision.Jul 15 2023, 05:54

This revision is now accepted and ready to land.Jul 15 2023, 05:54

FYI this will also mean Cashtab has to make a separate API call to get the tipheight everytime it calls the pricing endpoint.

Fabien accepted this revision.Jul 17 2023, 08:51

Fabien added a subscriber: Fabien.

Fabien added inline comments.

doc/standards/ecash-alias.md
62 ↗	(On Diff #41452)	FYI this will also mean Cashtab has to make a separate API call to get the tipheight everytime it calls the pricing endpoint. Ethan is right, this is a bad API and it's not necessary. The spec update is OK to me (so was the previous version but it's certainly more clear after the change), but the implementation is backward. See the comment in the other diff.