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

???

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;

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.

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"

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.

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.

That's a useful comment

But this one and the one above are not

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.

?