Future Fee System for Names - step 1 : minimal requirements

[Ademan]

3. The enforced fee is the median of the 2048 previous votes. (This number is chosen mainly for the balance between stability against randomness and flexibility against market instability. The exact number is open to debate.)

I like that the formula for the fee is well defined, but I'm worried about having a moving window like that. Consider if I submit a name transaction with the bare minimum fee, but it doesn't make it into the next block. By the next block, the median may have changed, and my previously valid name registration is now wasted.

5. Most miners will choose to use the default settings from the Namecoin dev team assuming that they are reasonable (similar to Bitcoin tx fees).

Can you elaborate on why they would choose default settings? If they're given freedom to choose, I assume they will reasonably price things to maximize their rewards.

6. If the Namecoin dev team does something unpopular with tx fees, the community of miners can choose not to honor it, which acts as a check on the power of the Namecoin dev team.

I do like that.

7. Miners have an incentive to (1) not make the name fees so high that people won't want to pay them (because then they won't collect tx fees); and (2) not make the name fees so low that Namecoin is devalued due to squatting (because then the exchange rate will go down, which impacts the collected tx fees).

I definitely agree with 1, but 2's effects are so disconnected from the action, I'm not sure miners will really take this into account. *Luckily* there's also 3 which is "miners want to maximize their reward".

9. The data structure could support varying fees for different names, in terms of namespace, name length, and/or value length. This is not a requirement of the proposal, but I think it could potentially be useful.

I like that as well.

10. The data structure could support name fees on renewals. This makes things harder for squatters, since holding onto a name would have a recurring fee. This is not a requirement of the proposal, but I think it could potentially be useful. (If we started requiring name fees on renewals, I'm not sure if that would require an initial hardfork... my guess is that it could be done without a hardfork, but I don't know enough to be sure... can snailbrain or khal comment on this?)

Does this really punish squatters disproportionately to legitimate users?

11. We would not have to return locked coins to name holders after names expire. As coins are destroyed, the USD price of Namecoin would go up slightly (small amount of deflation), and the name price would decrease accordingly (so that the NMC price of a name will decrease as the supply decreases, meaning we will never run out of coins). This makes things harder for squatters, since they can't squat a name, and then get their money back if no one wants to purchase it. This is not a requirement of the proposal, but I think it could potentially be useful.

I'm all for slow deflation, but I'm not sure I want to be destroying coins when it's avoidable, unless we counter act that with an infinite supply of Namecoins. Effectively though what I'd prefer is to just award them to miners.

Anyways I like the idea overall, but I'm a bit worried about the implementation, specifically with regards to insufficient fees.

EDIT: I decided to omit it earlier, but I had a proposal for an alternative to a moving window, but this may not be any better. Basically the fee proposals to be examined are taken from the past two "chunks" of 1024 blocks. So if the last block mined was 10239 the two intervals considered would be 7168 to 8192 and 8192 to 9216. Then, once block 10240 is mined, the two intervals would be 8192 to 9216 and 9216 to 10240. So you have complete certainty of the minimum fee for 1024 blocks at a time, but it introduces significant uncertainty near the edges of intervals. I'm not positive it's an improvement but I thought I'd throw it out there.

In python it uses

Code: Select all

def interval(h, x=0): return ((h // 1024) - x) * 1024

and

Code: Select all

[interval(last_known_block, x) for x in xrange(3)]

gives you your three interval endpoints, although I suppose you don't really need the middle one...

[indolering]

3. The enforced fee is the median of the 2048 previous votes. (This number is chosen mainly for the balance between stability against randomness and flexibility against market instability. The exact number is open to debate.)

I like that the formula for the fee is well defined, but I'm worried about having a moving window like that. Consider if I submit a name transaction with the bare minimum fee, but it doesn't make it into the next block. By the next block, the median may have changed, and my previously valid name registration is now wasted.

Just require that the client sends enough to cover a price hike. If it doesn't go up, the money is returned.

5. Most miners will choose to use the default settings from the Namecoin dev team assuming that they are reasonable (similar to Bitcoin tx fees).

Can you elaborate on why they would choose default settings? If they're given freedom to choose, I assume they will reasonably price things to maximize their rewards.
[/quote]

Well, we can't even CEX.io to respond to any of our emails regarding overwhelming the NMC network. I doubt they would even notice the change.

6. If the Namecoin dev team does something unpopular with tx fees, the community of miners can choose not to honor it, which acts as a check on the power of the Namecoin dev team.

I do like that.

Yeah, that my favorite part too : ) Even if the miners go crazy, we can change the mining method. In the long run, the best actors are rewarded.

10. The data structure could support name fees on renewals. This makes things harder for squatters, since holding onto a name would have a recurring fee. This is not a requirement of the proposal, but I think it could potentially be useful. (If we started requiring name fees on renewals, I'm not sure if that would require an initial hardfork... my guess is that it could be done without a hardfork, but I don't know enough to be sure... can snailbrain or khal comment on this?)

Does this really punish squatters disproportionately to legitimate users?

I scraped the entire namespace and a simple blacklist filter > 99.97% of names are just squatted. So, yes

I think the default should be a trimmed mean based off of multiple APIs USD/NMC rate. I know people don't like the idea of using data sourced outside of the swarm, but there are half-a-dozen major exchanges now and they all offer an API. Between the trimmed mean of the 6 data feeds and the moving average, an attacker would have to compromise => 3 of the API feeds of an exchange for 2 weeks without the exchanges, the miners, or the developers noticing. The miners can manually change the APIs if they don't want to wait for us to push out a patch.

I just don't see a legitimate threat here, unless someone can build a mechanism which extracts the price from the exchange based currencies (Ripple, et al.) we will always be reliant on a hard-coded default and the political headaches it causes.

In regards to the consensus mechanism, I would like to see some models of the price volatility for various weighting mechanisms. I think the median price idea is probably the simplest for now.

I'm more worried about multiple miner implementations and messing up the delicate system that mining is. Domob, would your suggestion would it harder to subtly mess up what the exact price consensus is at a given point in time and more testable?

[khal]

I think the default should be a trimmed mean based off of multiple APIs USD/NMC rate. I know people don't like the idea of using data sourced outside of the swarm, but there are half-a-dozen major exchanges now and they all offer an API. Between the trimmed mean of the 6 data feeds and the moving average, an attacker would have to compromise => 3 of the API feeds of an exchange for 2 weeks without the exchanges, the miners, or the developers noticing. The miners can manually change the APIs if they don't want to wait for us to push out a patch.

I just don't see a legitimate threat here, unless someone can build a mechanism which extracts the price from the exchange based currencies (Ripple, et al.) we will always be reliant on a hard-coded default and the political headaches it causes.

In regards to the consensus mechanism, I would like to see some models of the price volatility for various weighting mechanisms. I think the median price idea is probably the simplest for now.

I'm more worried about multiple miner implementations and messing up the delicate system that mining is. Domob, would your suggestion would it harder to subtly mess up what the exact price consensus is at a given point in time and more testable?

There is a way to base the price on USD/NMC rate without forcing it :
- let people choose the price "they want", in $/€ when they register a name and display the value in NMC (by using the price on several exchanges)
- later, use the median (or else) price with limits : 50%min / 150% max [enforced by miners], and propose the median price in GUI

To limit the impact of price change on block retarget :
- put limits like for block difficulty => this requires the median price to be store in the chain, otherwise you need to calculate from the genesis block
or :
- the GUI can warn people, and if the future price is still in the current limits (it should always be the case), propose a lower range (ex: 100% to 150% instead of 50% to 150%).

To prevent the case where no NMC are available to register a name :
- use a upper limit on price to allow an unlimited amount of names (can be added later ?)


This should allow a dynamic price adjust based on NMC value in $.
I'm not sure the median price would suffice to balance people who want to register a lot of names for the minimum price ? Would the price fall to 0 at the end ?


ps : in command line, you could use "name_getprice" which would return min, max & median.

[indolering]

There is a way to base the price on USD/NMC rate without forcing it :
- let people choose the price "they want", in $/€ when they register a name and display the value in NMC (by using the price on several exchanges)
- later, use the median (or else) price with limits : 50%min / 150% max [enforced by miners], and propose the median price in GUI

I'm not sure I understand the rational, are you just trying to move the $/€ query to the GUI?

To limit the impact of price change on block retarget :
- put limits like for block difficulty => this requires the median price to be store in the chain, otherwise you need to calculate from the genesis block
or :
- the GUI can warn people, and if the future price is still in the current limits (it should always be the case), propose a lower range (ex: 100% to 150% instead of 50% to 150%).

I generally agree with the GUI just covering up what is going on with the backend. Remember that the VAST majority of people will pay a registrar to do everything for them (convert their fiat into Namecoin, anticipate price changes, handle renewals, etc).

To prevent the case where no NMC are available to register a name :
- use a upper limit on price to allow an unlimited amount of names (can be added later ?)

This should allow a dynamic price adjust based on NMC value in $.
I'm not sure the median price would suffice to balance people who want to register a lot of names for the minimum price ? Would the price fall to 0 at the end ?

I don't think I understand, this sounds like you are trying to make it cheaper for people who want to buy names in bulk?

[khal]

I'm not sure I understand the rational, are you just trying to move the $/€ query to the GUI?

"Just" moving the $/€ query to the GUI removes the hard dependency between the blockchain rules & some external data. So yes, that's what I want to do, but it makes a big difference.
To make things more clear, it is a 2 steps process.
First, let people chose the price of a domain in $/€ for a given period (ex 2016 blocks or more) by using exchanges API to convert to the right amount of NMC when registering the name.
Second, make the hard fork to force the use of the median price with an allowed margin upper/lower of 50% (or 80% or else).

I generally agree with the GUI just covering up what is going on with the backend. Remember that the VAST majority of people will pay a registrar to do everything for them (convert their fiat into Namecoin, anticipate price changes, handle renewals, etc).

The GUI, or RPC will propose a price and some margin to chose another one. This will change the future median price according to people desires.

I don't think I understand, this sounds like you are trying to make it cheaper for people who want to buy names in bulk?

My fear is that by using the median price it would be possible to push the price very low. Register a lot of name at the minimum price, wait 2016 blocks, renew them at the new minimum price, etc...
That's why I'm not sure if the median price would be sufficient. We may need a different formula (median + percentile, ignore extremity prices, give a different wheight if price are farer from the median, etc).

[indolering]

"Just" moving the $/€ query to the GUI removes the hard dependency between the blockchain rules & some external data. So yes, that's what I want to do, but it makes a big difference.

Right, but the price setting voting mechanism would still be in the miners control, i.e. the miners could ignore what the users want, right?

My fear is that by using the median price it would be possible to push the price very low. Register a lot of name at the minimum price, wait 2016 blocks, renew them at the new minimum price, etc...

Ah, right, that was my first concern too. User price manipulation is much cheaper than buying actual mining power. However, we could also factor in things like IP subnet diversity, time, etc.

That being said, with 99.97% of all domains being eaten up by squatters, it will be a while before the data coming in from the buyers is at all reliable.

That's why I'm not sure if the median price would be sufficient. We may need a different formula (median + percentile, ignore extremity prices, give a different wheight if price are farer from the median, etc).

Agreed, the median is less resistant to extremes but eventually someone will need to do some statistical analysis and model the different pricing schemes.

[khal]

"Just" moving the $/€ query to the GUI removes the hard dependency between the blockchain rules & some external data. So yes, that's what I want to do, but it makes a big difference.

Right, but the price setting voting mechanism would still be in the miners control, i.e. the miners could ignore what the users want, right?

Miners can accept of refuse txs based on their own criteria. But the default rule for every client (and miners too, as a consequence) would be to reject txs (and blocks containting tx) outside of the price limits.

Ah, right, that was my first concern too. User price manipulation is much cheaper than buying actual mining power. However, we could also factor in things like IP subnet diversity, time, etc.

Everything that is not stored in the blockchain (IP for ex) won't be a suitable criteria.

That being said, with 99.97% of all domains being eaten up by squatters, it will be a while before the data coming in from the buyers is at all reliable.

They may have some interest in making price of names more expensive (it may increase the value of 1 NMC and they may own some too). We'll need to convice them :p
But, we can also set the first price in the code and make all in 1 step (the hardfork would happen at a given block), to start at a "reasonable" price (I prefer the other solution. We would have an indication of wanted prices from people).

[indolering]

Everything that is not stored in the blockchain (IP for ex) won't be a suitable criteria.

You've supported using external data in the past, are you just saying that in regards to weighting factors?

That being said, with 99.97% of all domains being eaten up by squatters, it will be a while before the data coming in from the buyers is at all reliable.

They may have some interest in making price of names more expensive (it may increase the value of 1 NMC and they may own some too). We'll need to convince them :p
But, we can also set the first price in the code and make all in 1 step (the hard-fork would happen at a given block), to start at a "reasonable" price (I prefer the other solution. We would have an indication of wanted prices from people).

Maybe, but in the future the biggest buyers will be domain registrars. Even ignoring large buyers or collusion among buyers there is no incentive for buyers to pay more: buyers will always vote for the lowest price.

I think I understand why you want to have the price set dynamically by what people want to pay, it sounds like that has been a major pain point in the past. Sadly, I think we still have some experimenting (and screwing up) to do. Thems the (engineering) bricks :p

/me wishes he had a crystal ball.

P.S. I screwed up my math on the above, 2459/90527 = 0.027, or ~ 97.3% of domains have no usable information. Messing around with the definition of squatter will get that down to ~95%.

[domob]

P.S. I screwed up my math on the above, 2459/90527 = 0.027, or ~ 97.3% of domains have no usable information. Messing around with the definition of squatter will get that down to ~95%.

It would be interesting to know how that percentage looks like for ICANN domains. I have the feeling that it may not actually be any better.

With respect to the dynamic fees: I have to admit that I'm a bit "frightened" by all the complicated schemes proposed (especially of course by ideas to connect the fees to a real-world quantity like NMC/USD). While I fully understand the motivation for doing this, I do not see me able to fully understand the dynamics this may create and thus it seems a bit risky when the system is so complicated that it could very well create firstly bugs and secondly weird incentives no one has thought about before. I would really prefer to have a system as simple as possible. (But no, I also don't have a good and simple suggestion for how to design the future fees best.)

[indolering]

TL;DR:
I doubt squatters hold even 10% chunk of ICANN domains.

Let's not confuse figuring out how how much will people pay for a domain with determining the NMC/FIAT exchange rate.

I like Khal's idea of a cost floor, $5.00 would eliminate the most egregious forms of domain squatting. We could setup a $0.10-$0.20 SLD for people that just want to test things (free domains attract scammers).

For the target price, I suggest we use a round number based on ICANN domain pricing:$10-$30?

We can use the exchange API's to calculate the NMC/FIAT rate and still be protected from government censorship and hacking. It's WAY easier than reimplementing the Ripple protocol.

Anything based on Jeremy's scheme can be updated in the future without a hardfork, so let's follow the IETF motto: rough consensus and running code.

Messing around with the definition of squatter will get that down to ~95%.

It would be interesting to know how that percentage looks like for ICANN domains. I have the feeling that it may not actually be any better.

Afternic claims to have some ~6 million listed domains, Sedo claims 16 million but only lists ~350 active auctions. Both estimates presumably indicate domains owned by individual sellers as well as pre-release domains (which no one is spending money to occupy). Even Sedo's inflated 16 million figure would be ~10% of all domains.

I think we are conflating two different problems, figuring out the price per domain and how to determine the NMC to reserve currency (euro, dollar, etc) rate. If either one is out of whack, the same set problems ensue. However, the solutions to both are entirely different

Khal's solution appear to be geared towards addressing the price per domain issue. I think Khal's suggestion of a one-time hardfork to institute a hard-floor price-floor is totally reasonable. The question is what that pricefloor should be.

Correct me if I am wrong, but I believe that the last downward price change was to address the need for people to experiment without paying a lot of money. What about designating a low cost SLD, with something like $0.10 - $5 per domain (because free domains attracts scammers). We could tie it's price to some fraction of the cost of a normal .bit domain....

The limiting factor for people purchasing domains is not the price but the time and effort required buy and maintain a .bit registration. I have had programmers with legitimate concerns about loosing their domain give up on figuring out how to register because it was a PITA. It has gotten better since then, but, honestly, who is willing to setup a wallet, exchange Bitcoin (if they even have Bitcoin), and figure out how to build Namecoin just to register a domain virtually no-one can visit?

I think setting the price is best determined by just looking at the prices of current domain names. I will try to do some research in this area to come up with a weighted average but, I'm guessing that if we remove the extreme outliers, we would find a $5-$100 range. I think a realistic price-point is probably between $10-$30.

As I see it, we have three options for figuring out the NMC/USD or NMC/EUR conversion:

• Guess and hardcode the price (as we have been doing).
• Rely on data feeds from exchanges.
• Rely on an exchange currency like Ripple or some future P2P exchange.

Based on my limited knowledge of Ripple and conversations with some devs, it is possible to retrieve current offers on exchanges in the Ripple network. While a P2P mechanism is obviously, the ideal solution, I think we are getting side-tracked on the centralized vs decentralized debate. I see four basic concerns:

1. Governmental/legal censorship
2. Hacking
3. Bugs resulting in hardforks.
4. The need for running code.

As I outlined previously, we can satisfy 1 and 2 using API feeds from exchanges.

The use of external API feeds have no impact on #3 because they are only used as the default mechanism to set the miners "vote." Once the votes are written to the blockchain we determine the median price but even then this is enforced in the index, not the blockchain. Any bugs here are fairly low impact.

Finally, implementing an entire additional currency or the communication protocols for a P2P exchange would require more resources than we have: it just won't get done. But even I, a lowly web hacker, can write something which can call a few rest API's and figure out the price. And even if we screw up, any perverse incentives we introduce can be easily reversed since this is enforced at the index level, not within the blockchain.