This approach simplifies implementing registration in wallets. Wallets already need to make an API call to see if an alias is available or not. If it is not available, return the price (and the next block, and the blockheight this price is good thru).
Details
- Reviewers
emack Fabien - Group Reviewers
Restricted Project - Commits
- rABC313627592385: [alias-server] Return price and price expiration blockheight from /alias…
npm test
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- server-pricing-state
- Lint
Lint Errors Severity Location Code Message Error apps/alias-server/src/utils.js:8 ESLINT no-unused-vars Error apps/alias-server/test/utilsTests.js:27 ESLINT no-unused-vars - Unit
No Test Coverage - Build Status
Buildable 24604 Build 48805: Build Diff alias-server-tests Build 48804: arc lint + arc unit
Event Timeline
apps/alias-server/src/app.js | ||
---|---|---|
44 ↗ | (On Diff #41451) | what's the context behind the +1000? |
apps/alias-server/src/app.js | ||
---|---|---|
44 ↗ | (On Diff #41451) | nvm, saw it in the updated spec |
This is not stateful and doesn't solve the problem. I still can't validate the fees against the past blocks.
For implementation in Cashtab: Note that calling the /prices/ endpoint is already calling the chronik.block endpoint, you are getting the current blockheight + 1000 returned.
So, it is not necessary to get the current blockheight from chronik in Cashtab. It's only necessary to make sure the price response from the API is not allowed to become stale to the tune of more than 1,000 blocks.
Repeating the API request every 30 minutes or so is enough to take care of this edge case.
The problem is still not solved. Before you had 1 endpoint that failed to do the job, now you have 2.
apps/alias-server/src/app.js | ||
---|---|---|
44 ↗ | (On Diff #41501) | That's not what you want, you want the price for the next block not the last one |
58 ↗ | (On Diff #41501) | ??? |
80 ↗ | (On Diff #41501) | It might be worth getting the data in an appropriated format from the beginning so this can be properly tested out. E.g: setting the prices constant in an array containing the starting block height, looping over it in reverse order to find if the requested height is in the range while storing the last starting blockheight. Once the requested block height >= starting block height, then you can return the associated prices and the stored starting block height from your loop is the output of the validThru (if there is one). Pseudo code below: The price storage format (some json so it doesn't need to be encoded in the response) prices = [ { startingBlockHeight: 100, registrationFeesSats: { 1: 10000, 10: 1000, 21: 550 } }, { startingBlockHeight: 200, registrationFeesSats: { 1: 20000, 10: 2000, 21: 1100 } } ] The loop: jsonOutput = { "error": "The requested block height for the alias registration fees is out of range" }: nextBlockHeight = 0; for price in reverse(prices) { if requestedBlockHeight >= price.startingBlockHeight { jsonOutput = { "blockheight": price.startingBlockHeight, "registrationFeesSats": price.registrationFeesSats }; } if nextBlockHeight > price.startingBlockHeight { jsonOutput |= { "validThru": nextBlockHeight }; } } return jsonOutput; |
Should get some helper functions and the new pricing format ironed out before adding to the API
improve comments
apps/alias-server/src/app.js | ||
---|---|---|
79 ↗ | (On Diff #41600) | either alias-server determines the chaintip, or we put this burden on implementing apps to call alias-server with a blockheight (i.e. make them determine the next block) it is burdensome to have alias-server do this, but the point of alias-server is to simplify implementation for wallets In Cashtab, for example, we would need to get the tipheight from chronik, then call alias-server -- so we might as well have alias-server get the tipheight, and limit cashtab API calls |
apps/alias-server/src/app.js | ||
---|---|---|
81 ↗ | (On Diff #41601) | I might be missing something here. The alias server is already validating the aliases in the blocks, so it should have the processed blockheight at hand, right ? Because this endpoint is responsible for telling you about the availability of an alias, that's the blockheight you're interested into. |
94 ↗ | (On Diff #41601) | How is that helpful ? You want to know the currently processed block height and the registration price (so fees for the next block). |
apps/alias-server/src/utils.js | ||
146 ↗ | (On Diff #41601) | I think we already discussed that. The expiration height only makes sense in one of these 2 scenarios:
If no expiration height is planned, this is completely wrong to return any value here. |
Use server state and not tipheight, only return priceExpirationHeight if change is incoming
arc lint
apps/alias-server/src/utils.js | ||
---|---|---|
146 ↗ | (On Diff #41601) |
omitting this as the function is not user-facing. |
apps/alias-server/src/app.js | ||
---|---|---|
30 ↗ | (On Diff #41609) | Nit: Please avoid this kind of useless comment. You're describing the code which brings no value. Interesting comments should explain why you chosed that solution instead. |
72 ↗ | (On Diff #41609) | That's a useful comment |
77 ↗ | (On Diff #41609) | But this one and the one above are not |
104 ↗ | (On Diff #41609) | It was a good idea to return the block height in the previous iteration. The bad idea was to return the next block height instead of the current processed height. |
apps/alias-server/test/app.test.js | ||
53 ↗ | (On Diff #41609) | ? |
apps/alias-server/test/app.test.js | ||
---|---|---|
53 ↗ | (On Diff #41609) | artifact from when this diff was adding a blockheight variable to the prices call, removed |
apps/alias-server/src/app.js | ||
---|---|---|
90 ↗ | (On Diff #41623) | Nit: do you really need a variable for that ? |