discuss fee algorithm

[shea256]

The current algorithm for calculating the price of a name is as follows:

def calculate_name_price(name):
    # establish the base price
    price = PRICE_FOR_1LETTER_NAMES
    # adjust the price by a factor X for every character beyond the first
    price /= PRICE_DROP_PER_LETTER**(len(name)-1)
    # apply other rules
    if has_numerics(name) or has_underscores_or_dashes(name):
        # for names with numerics or special chars, reduce the price further
        price /= PRICE_DROP_FOR_NON_ALPHABETIC
    else:
        # for alphabetic names, enforce a price floor
        if price < ALPHABETIC_PRICE_FLOOR:
            price = ALPHABETIC_PRICE_FLOOR
    # return the calculated price
    return price

How could this be improved? What other options do we have?

[shea256]

One more idea is to have namespaces be identified by the price policy. For example:

"10-2/ryan" would refer to the name "ryan" registered in the namespace "10-2", which has the fee policy of 10 BTC for a 1-letter name and a decay rate of 2, which means as you add on one letter, the price gets half as expensive.

"0.001-1/ryan" would result in names that cost 0.001 BTC. Since the decay rate is "1", all names cost the same, regardless of length.

So if you want a different fee policy, just start using a namespace identified by that policy and register names in there.

[muneeb-ali]

Yes, we'd love to get more feedback on the pricing of names. We're approaching this as:

-- Opennamed creates a "namespace universe" (thanks @rxl for the term) and gives people the ability to create different namespaces e.g., d/ for domains, u/ for openname usernames etc.

A big question is about pricing for these names. @taoeffect pointed out that if the names are not free then people would try to fork opennamed and reduce the price and it's a valid concern.

Building up on what Ryan said. Here is an addition:

-- Let the creator of a namespace specify the pricing as a prefix (same as above comment, can debate how exactly to specify the prefix)
-- And once names expire, implement a bidding system for those names

What this enables is that the creator of the namespace can specify a price (could even be a flat price i.e., no decay e.g., $10 USD for domain regardless of length) and then when domains expire we let the market decide what are people willing to pay for it. This has the properties that:

a) addresses initial squatting problem (can decide what price will keep squatters away)
b) don't need to worry about "stealing names" from people by offering to pay a higher price close to expiration time (bidding works only on names that expired)

[shea256]

So one question about this name bidding process after first expiration:

Let's say the name price is $10 / 0.25 BTC. Then let's say the name expires. I assume bids after that all have to be above $10. Will the name then go to the highest bid that clears the $10 bar? Then what happens if it expires again? Will the name once again go to the highest bid above $10?

Also, why is this better than having a name bidding period upon first register as well? The problem I see with not having this is that it still allows squatters to get a "deal" if they are early. It doesn't make any effort to put the name in the right hands.

Another idea is to have a "bidding" flag. If a namespace has a bidding flag, then names must be bid on AND clear the minimum bar outlined by the fee algorithm. If the namespace doesn't have a bidding flag, then names are registered immediately so long as the clear the fee bar.

[shea256]

Side note: thought of an alternative term for "name universe" that's a bit easier to work with: "nameset".

Here, the established nameset would refer to all names ever registered on all possible namespaces. The nameset is the superset of all namespaces, and the nameset has multiple namespaces within it. In a sense, the nameset refers to a given snapshot of reality.

If we extend this to ICANN DNS, then one nameset is the representation of all names ever registered with all TLDs at a given time. If a name is registered at t seconds later, then the nameset that takes into account that name is the most current one.

[taoeffect]

I like @rxl's both of your ideas of giving namespace "owners" maximum control over their namespace. I also like "nameset". 😄

Allowing namespaces to specify:

• If bidding is enabled or not
• The curve algorithm (exponential, linear, s-curve, etc.)
• The constants to the bidding algorithm/curve (minimums above base txn fee, curve degree, etc.)

Etc, that seems like a win-win, resulting in maximum adoption and little reason for forks or competitors (since you're facilitating competition within opennamed's protocol).

Edit: sorry for all the edits. _Verryy_ long day.

[muneeb-ali]

Liking the sound of this! Having a generic way to define namespaces helps a lot in people converging to the same underlying platform. There shouldn't be any need to start your own blockchain or your own protocol on top of a blockchain if all you want to do is start a namespace with certain properties.

I was thinking that one option for defining names on namespaces can be:

<prefix> <namespace> <name>

The prefix is like a header that fully defines the policy of the namespace (kind of like headers in IP packets), namespace can take the usual format of 'u/' and so on (it just needs to uniquely identify a namespace) and finally a name complies to some regrex. Due to size limitations of OP_RETURN, we might want to put size limits on prefix, namespace name etc (or maybe not and just a single size limit is enough?)

[shea256]

Yeah, I like it as well.

And I think there should not only be size limits on the prefix but there should be a fixed defined size. For example, if we use the equation y = a*x^-(b-1) for name prices, there could be one byte for a, one byte for b, and one byte for flags (a flag for bidding, a flag for name expiration, etc.). IMO 3 bytes is already pushing it and I'd say we should try to get it down to 2. Names are already restricted to 16 bytes and that's pretty paltry (ICANN domain names are allowed to reach 63 characters).

Greg, I understand your desire to specify various types of curves, but I feel like it can get real complicated real fast. The curve would have to be specified in a byte somewhere and then each of the following bytes would have different meanings. If we did that, we'd have something like a language for fee policies like Bitcoin's script, which we might want to avoid. Further, with each curve, you'd have to ask what would be the "x" in the equation? The number of letters? And if the price is only dependent on the number of letters then why would you conceivably want anything other than a price that decreases as x increases (or has a 0% decrese/doesn't decrease at all)? It turns out that the exponential function can cover everything from constant name prices to rapidly decreasing name prices/free names across the namespace. One would have a very high degree of control by being able to manipulate the exponent and base constant. If you were to allow more specific curves, when there are only a dozen or so possible x values, you probably wouldn't even notice the difference. On the other hand, if "x" is not the number of letters but in fact something else, then what would that something else be? And would we need another indicator of what the "x" value is? Also another unnecessary level of complexity, I feel.

As far as the fee policy prefix + namespace identifier + name format, I like it but I'd simplify it more. For example, why do we need both a policy prefix and a namespace identifier like "u/"? If we go with the format proposed here, it wouldn't be the namespace identifier that would need to be unique but rather the "policy + namespace id". So 10-10-u/ would be the real unique identifier and would be distinct from 10-5-u/ because they have different policies. In other words, users should not be able to register a name in one and have it be excluded from the other. Once we establish that it's really the policy prefix + namespace id combo that needs to be unique, we show that the namespace unique identifier really includes the policy prefix. And then from there, I wonder why we even need the u/ part at all. You could imagine namespaces simply being identified like so: 10-10/ and 10-9/.

[shea256]

Here's one way we could encode the namespace fee policy:

Equation for price calculations

y = a0*10^a1*x^-(b-1)

...where x is the number of letters in the name and a0, a1, and b are all integers from 0 to 15.

Equation Encoding

constant	bits
a0	4
a1	4
b	4
flags	4

Flags

One possible flag set:

flag	bits
name bidding flag	1
name expiration flag	1
non-alphabetic discount flag	1
non-vowel discount flag	1

This entire policy encoding takes up only 2 bytes.

[shea256]

Another alternative to "nameset" and "nameuniverse": "nameview".

Contexts: "build nameview", "verify nameview", "update nameview", "ensure all nodes have the same nameview", "all the namespaces in the nameview".

[jcnelson]

This has been addressed and implemented. Please find the relevant documentation in the Usage document.

[shea256]

👍