Page MenuHomePhabricator

[alias-server] Return price and price expiration blockheight from /alias endpoint for unregistered aliases
ClosedPublic

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

Details

Summary

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).

Test Plan

npm test

Diff Detail

Repository
rABC Bitcoin ABC
Branch
server-pricing-state
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 24537
Build 48673: Build Diffalias-server-tests
Build 48672: arc lint + arc unit

Event Timeline

emack added inline comments.
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 revision is now accepted and ready to land.Jul 15 2023, 05:56
Fabien requested changes to this revision.Jul 17 2023, 08:46
Fabien added a subscriber: Fabien.

This is not stateful and doesn't solve the problem. I still can't validate the fees against the past blocks.

This revision now requires changes to proceed.Jul 17 2023, 08:46

remove useless try..catch blocks, add stateful price endpoint

return blockheight with prices

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.

Fabien requested changes to this revision.Jul 18 2023, 12:40

The problem is still not solved. Before you had 1 endpoint that failed to do the job, now you have 2.

This revision now requires changes to proceed.Jul 18 2023, 12:40

Remove tipheight lookup, return blockheight with prices for all requests

Fabien requested changes to this revision.Jul 18 2023, 20:40
Fabien added inline comments.
apps/alias-server/src/app.js
44

That's not what you want, you want the price for the next block not the last one

58

???

80

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;
This revision now requires changes to proceed.Jul 18 2023, 20:40

Should get some helper functions and the new pricing format ironed out before adding to the API

Adding price info to the /alias/alias endpoint for unregistered aliases

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

bytesofman retitled this revision from [alias-server] Add state to prices endpoint to [alias-server] Return price and price expiration blockheight from /alias endpoint for unregistered aliases.Jul 26 2023, 20:02
bytesofman edited the summary of this revision. (Show Details)
Fabien requested changes to this revision.Jul 27 2023, 09:18
Fabien added inline comments.
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).
Like in "alias 'foobar' is available at block 10000 (current tip) and the registration fees is 100 XEC to have it processed at block 10001"

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:

  • There is a planned price change in a future block that you know about
  • The price is requested for a block height too far in the future, so you should refuse to return a value

If no expiration height is planned, this is completely wrong to return any value here.

This revision now requires changes to proceed.Jul 27 2023, 09:18
bytesofman marked 2 inline comments as done.

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)

The price is requested for a block height too far in the future, so you should refuse to return a value

omitting this as the function is not user-facing.

Fabien requested changes to this revision.Jul 28 2023, 08:34
Fabien added inline comments.
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)

?

This revision now requires changes to proceed.Jul 28 2023, 08:34
bytesofman marked 3 inline comments as done.

return processedBlockheight, remove dumb code comments

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

Fabien added inline comments.
apps/alias-server/src/app.js
90 ↗(On Diff #41623)

Nit: do you really need a variable for that ?

This revision is now accepted and ready to land.Jul 28 2023, 18:54