Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Quality Name Distribution & Namespaces #3189

Closed
bytemaster opened this issue May 18, 2018 · 41 comments
Closed

Quality Name Distribution & Namespaces #3189

bytemaster opened this issue May 18, 2018 · 41 comments
Assignees
Labels
code review in code review
Milestone

Comments

@bytemaster
Copy link
Contributor

bytemaster commented May 18, 2018

Currently EOSIO prohibits the creation of new account names that are less than 12 characters long and/or contain a ".". The purpose of this restriction is to discourage name squatting. That said, it is desirable to enable shorter names for usability and because they are a marketable commodity.

It is also desirable for organizations to have the ability to create a "trusted" namespace where everyone can trust an account suffix like ".edu" or ".com". Shorter suffix enable longer names pre-suffix and therefore have a larger namespace and are more valuable.

The most economically efficient and fair method to allocate shorter names and/or namespaces is to sell the names at market price. To get the most value for the premium names they should not be sold all at once, but over time.

Proposal

  1. Only account name "com" can register new accounts xyz.com
  2. At most one new "premium name" (those that don't contain a ".") will be sold per day and it will be the name with the highest bid.

Bidding on Names

bidname( account_name bidder, account_name desired, asset bid )

If 'bid' is greater than the highest bidder then bidder becomes the pending winner of the desired name. Each bid must be 10% higher than any existing bid. The existing bidder will receive a refund of their bid when they are outbid. This encourages parties to bid high enough that they don't get outbid in the first place and discourages parties from going back-and-forth fighting for the name. It also discourages "squatting" on names hoping no one comes along to outbid them.

Every 24 hours the name with the highest bid is closed. Once closed the "winner" can use the newaccount action to register the account. At this point the memory allocated for the bid is released back to the bidder.

Easy options for masses

The vast majority of users will not want to participate in the daily name auctions because it is a slow and highly competitive process. Instead name-registrars will bid on the good names and then create accounts for their users as "sub-names". Large DAPPs will probably want to reserve their own branded namespace and set their own policy on premium names.

Non-Revokable

Once account xyz.com has been created by .com it cannot be deleted and the owner of xyz.com can potentially transfer control over that account to anyone. If companies wish to retain control over all accounts with ".com" in the suffix then they will need to set the "owner" permission accordingly.

Auction Proceeds

The proceeds from the auction are placed into the system savings account along with other unallocated inflation and RAM trading fees.

FAQ

  1. All names can be bid on at any time, but only the name with the highest bid closes each day. Order of names being sold will be "most valuable first".

  2. Future worker proposals could allocate the proceeds from the name sales.

  3. 12 character limit applies to the full name including the ".suffix"

@bytemaster bytemaster added this to the Version 1.0 milestone May 18, 2018
@bytemaster bytemaster self-assigned this May 18, 2018
@aaroncox
Copy link
Contributor

An interesting proposal for premium namespace auctions. I can see how these sorts of account name resources would be a desirable asset in many use cases 👍

First thought - if the auction window uses static start/end times (e.g. auctions start/end at 0:00 UTC), it's design may encourage "sniping" of the daily auctions. I'm not sure if this is a major concern - but bidders under these conditions may be at a disadvantage if they participate earlier in the auction, as opposed to bidders participating towards the end. Combine this with the partial refund (75%) and this could turn into a frustrating situation.

Potential solutions to discourage "sniping" include:

  • selecting a secret/random time between X and Y each day that the auction will end, encouraging users to bid early enough to not miss the deadline.
  • each bid extends the auction window by 30 (or X) minutes, allowing users to counter bid any last-minute bid.
  • requiring all "new" bids for the day to be placed within the first 23 (or X) hours of the auction, and only allowing previous bidders (who had been outbid that day) to participate in the last hour of each auction.

One additional thought - would it make sense to prefix (as opposed to suffix) these namespaces (aka reverse-DNS style)? Instead of xyz.com, going with com.xyz. I'm not sure if it would have an impact on the indexes within EOS itself, but this is a common practice I've adopted when dealing with actual DNS domain names, primarily for organization, sorting and grouping. They can always be reversed for UX/presentational purposes.

@EOSIO EOSIO deleted a comment from stvenyin May 18, 2018
@EOSIO EOSIO deleted a comment from stvenyin May 18, 2018
@bytemaster
Copy link
Contributor Author

in terms of user experience, people will identify most with the "start of the name" so suffix is more appropriate.

in terms of ending it... I agree that it must be at least 24 hours after last bid.

bytemaster added a commit that referenced this issue May 18, 2018
@bytemaster
Copy link
Contributor Author

Items left to do:

  • update ABI for eosio_global_state, bidname, and namebids table
  • write unit tests to verify accounts cannot be created unless authorized

@tkaraivanov
Copy link

tkaraivanov commented May 18, 2018

I see 2 potential issues with this:

  1. Demand for premium names could be much higher than 1 per day, which would artificially increase the price of a premium name.
  2. Last-minute bid wars.

I propose the following to alleviate these potential problems:

  • Each day, the top Z% of the names that are bid for are awarded, but not less than 1.
  • Users submit both a current bid and a maximum bid. The maximum bid amount is used to automatically outbid (by X%) anyone who outbids their current bid, similar to how it works on Ebay.

@guaiguaihw
Copy link

guaiguaihw commented May 18, 2018

I wonder that who would get the cost of bid?BP? Or this part of tokens will be de destroyed by system?Or stake to system?

@btsfav
Copy link

btsfav commented May 18, 2018

disagree. no need to artificially limit a FREE and OPEN blockchain. let people do whatever they want.

thanks

@samupaha
Copy link

Good proposal, a few comments...

All names can be bid on at any time, but only the name with the highest bid closes each day. Order of names being sold will be "most valuable first".

If the system sells only one account a day, after year we'll have only 365 premium names. That's not much for an ecosystem like EOS. I'd like to see more names sold.

But on the other hand, it might not be a good idea to sell a lot of names in the beginning. Some tokenholders haven't registered their tokens, so they need to wait until they'll get their tokens to EOS blockchain. And generally people will be just learning how the system works and it takes time. So I propose that premium names are sold one per 24 hours for the first month, and after that there is more supply, for example, one account in every 10 hours.

Future worker proposals could allocate the proceeds from the name sales.

I think we could just burn these proceeds by default. The worker proposal fund will be getting a lot of money if the token price stays at this level or goes higher, so I don't see a need for extra funds. If the token price goes lower and extra funding is needed, this can be changed by the community.

@rogerone-shen
Copy link

@guaiguaihw as BM mentions, cost of bid goes into system saving account, just like WPF(worker proposal fund).

@rogerone-shen
Copy link

rogerone-shen commented May 18, 2018

At most one new "premium name" (those that don't contain a ".") will be sold per day and it will be the name with the highest bid.

It is not enough i think. Every DAPP developer wants a premium name. This limitation stops eosio adopting massive dapps.

@blahbax
Copy link

blahbax commented May 18, 2018

Does this proposal cover symbol namespace as well? There's going to be a lot of demand for 3 character tickers. How is this going to work?

@bytemaster
Copy link
Contributor Author

SYMBOL names will have to be allocated by the exchange and/or token contract in the future. We are not currently supporting that as part of this proposal.

@wanderingbort
Copy link
Contributor

Should we consider renaming our reserved names/permission levels to be consistent with the suffix approach.

For instance eosio.* is currently a reserved namespace for accounts enforced at a base level. This was done so that only privileged accounts (chain level administration) could allocate names in this space (eg eosio.token)

However, this is the reverse of the proposed scheme here and ideally we would have consistency such that the token contract would be emplaced @token.eosio, msig @msig.eosio etc. We should also consider re-renaming the special accounts from #2325 to conform as well.

@blahbax
Copy link

blahbax commented May 18, 2018

Hmmm ... could you please clarify @bytemaster - are you saying it will not be possible to create EOS standard tokens with unique tickers at launch?

Currently on private testnet we can create token ABC:

user@localvm:~/eos$ cleos push action eosio.token create '[ "eosio", "1000000000.0000 ABC", 0, 0, 0]' p eosio.token executed transaction: 632985632c04cca957e630c8c174689166177d4849dd0479008148212e419f79 120 bytes 314 us #eosio.token <= eosio.token::create {"issuer":"eosio","maximum_supply":"1000000000.0000 ABC"} warning: transaction executed locally, but may not be confirmed by the network yet

and then attempting to create that same token again results in an exception as the ticker already exists:

user@localvm:~/eos$ cleos push action eosio.token create '[ "eosio", "1000000000.0000 ABC", 0, 0, 0]' -p eosio.token 59247ms thread-0 main.cpp:2444 main ] Failed with error: Assert Exception (10) condition: assertion failed: token with symbol already exists

@bitcoiners
Copy link

Token SYMBOL names should also have a custom distribution mechanism for the same reasons as premium account names.

@roger-eosuk
Copy link

Hi Dan, Petty typo comment http://tinyurl.com/yd8pyvnu (I can't help it they just jump out at me).

When names are transferred, as per your example xyz.com, can the current owner sell this to the new owner for whatever price they like and using whatever payment mechanism they like, and will they then be the owner of this name until the end of time?
(Unlike current domain registrations which have to be renewed) If so I can see a whole new EOS namespace industry springing up from this.....

@bitcoiners
Copy link

bitcoiners commented May 20, 2018

Will account names work across multiple eos sidechains, or will each sidechain have own account names?
Same question for token symbol names.
In other words, does multi-chain eos have unified namespace for account names and token symbols?

@dali1986
Copy link

Having .com or other generally known gtlds as namespaces could be potentially confusing between domain names and eos account names e.g. coinbase.com - could a different separator rather than period be used e.g. @ or * = tortoise@com or boatface*com

Also not clear how namespaces would be auctioned or allocated.

@bytemaster bytemaster added the code review in code review label May 22, 2018
@bytemaster
Copy link
Contributor Author

Side chains will likely import accounts from the main chain

@KINGdotNET
Copy link

Do we see this live now?

@EurekaChen
Copy link

EurekaChen commented Jun 11, 2018

Because the account name is different from the domain name, if only this rule, then most of the account name will never be used, which is absurd.

BM(bytermaster) can explain why you want to set it up such rule? Just like domain suffix, or is it possible to open up a wider range of account name registrations later after taking part of the premium name suffix? Or does BM have other considerations, For example, does he not want widely use the same one mainnet, but rather want more EOS mainnet launch?

in chinese (用中文表述一下)
因为账号跟域名是有些不一样的,如果仅这样的规则,那么绝大部分的账号名称就永远得不到使用了,这是很奇怪的。

BM能出来解释一下为什么要这样设置吗?
是不是拍出部分黄金名称后缀后,考虑在后期开放更广泛的名称注册?或者说BM是不是有另外的考虑,例如,他是不是不希望很多人使用同一个主网,而是希望有更多的EOS主网? 还是其它什么目的?

@stvenyin
Copy link

See.

@connethk
Copy link

Sells only one account a day is too slow for the whole community. I suggest name auction to be take place in different classes every day . like:

Premium class: sells 1 name per day with the highest bidding price
Medium class: sells 10 names per day within the medium price range
Low class: sells 100 names per day within the lowest price range

We are a small Dapps developer that want a low class name only while we can't wait too long to acquire.

@emkman
Copy link

emkman commented Jun 15, 2018

This is painful. ENS did it right, the end time for each name should start when it receives its first bid and then can be delayed as long as bidding continues. The fact that I will have to wait months to bid for randomjunk because I am waiting for someone to pay tens of thousands of dollars for eos or games is crazy.

@sportsminer
Copy link

only one name perday is weired.

@policej
Copy link

policej commented Jun 19, 2018

why not just start from 12 characters for the first year combine with the one day per account;
Just like ENS, still cannot register 7 characters for now.

@jjnetcn
Copy link
Contributor

jjnetcn commented Jun 21, 2018

For most people, it seems to be in an auction that will never be finished, and the auction funds will not return, so no one wants to go to the auction in the future. i means user should can refund funds if
nobody rise the price for long time.

@Damon1002
Copy link

Can anyone tell me what time exactly for the first round of bid ends in UTC TIME? Thanks

@heifner
Copy link
Contributor

heifner commented Jun 23, 2018

from producer_pay.cpp of eosio.system contract onblock:
if( (timestamp.slot - _gstate.last_name_close.slot) > blocks_per_day ) {

1 day after last name close and hightest bid has not changed in 1 day.

@Damon1002
Copy link

can anyone help me confirm which exact date is the first bidding opening date? Thank you very much

@rixst3r
Copy link

rixst3r commented Jun 28, 2018

The human element and time zones is already potentially creating a slow bid problem which could mean literally weeks or months between each name closing as parties bid higher only after they see what other parties bid the night before.

It would be better in my opinion if it would award one name per day that has the highest bid and no bids for 24 hours (so the next name in line with no bids in the last 24 hours). That way there is always one name per day that gets awarded, and names with high bid activity stay in auction but less popular names make their way out sooner and allow app devs to actually have a chance getting a namespace.

This has essentially the same per-name economic impact, as parties willing to pay more can get their name and also get it sooner... but it doesn't cause the entire bidding system to sit in stale-mate for weeks on end.

Let's assume I want the name "zrrbg" ... I would have to pay more for zrrbg then someone wants to pay for "eos" or "com" just because those other names keep getting bids and potentially never leave the auction block if two whales keep out-bidding eachother and obviously neither of them want to put more money than is needed and both potentially have no deadlines to deliver a product...

A name which has an actual use case would create incentive to pay a higher bid, but it would also create incentive to apply the bid immediately... where as someone who is just rich with eos and has no use case and all the time in the world can just tire out all the people who actually need the name some time this year and slowly bid it up once every 24 hours. You are enabling people who have more money and less actual use cases to be able to frustrate hard working developers with actual products to ship and actual deadlines. This essentially makes the bidding useless to people who would be MOST LIKELY to actually benefit the community.

@blockminellc
Copy link

blockminellc commented Jul 17, 2018

@bytemaster

In seeing how the bidding process has gone and only 2 premium names have sold in two weeks I would agree with @rixst3r -

  1. Allow the highest price name that has not been bid on in 24 hours to sell.

ie day 1
"NET" is at 90,000 EOS but was bid on 6 hours ago.
"WYSIWYG" is at 85,000 EOS and was last bid 25 hours ago
"JENGA" is at 15 EOS and was last bid 1 hour ago
"DOORMAT" is at 5 EOSand was last bid on 6 days ago.

WYSIWYG sells in round 1 because it was the highest bid that did not have any action in 24 hours

day 2
"NET is at 99,000 EOS and last bid 1 hour ago
"JENGA" is at 17 EOS and last bid on 22 hours ago
"DOORMAT" is at 5 EOS and last bid on 7 days ago

DOORMAT sells in round 2 because it was the highest bid that did not have any action in 24 hours

At least we have a sale per day and at least some of the non uber premium names have a chance to sell early so developers can acquire their proprietary names that no one else really wants like ZUMBLAR.

The other issue is that I have potentially tied up my EOS indefinately by bidding on premium names that are under 1000 EOS range since it will take about a million years for them to raise in price or come up for sale. And since the bylaws dont allow me to bid again on the same auction on the same name just to hopefully push it through, my EOS are possibly tied up forever, or at least my lifetime. With no ability to raise my bid or cancel it, my EOS are tied up and unusable which I dont see as good for the EOS platform. If you use the current rate of sale, added to the increase in BPs mining rewards allowing them to gorilla bid indefinately, We will likely only sell 10-15 premium names this year and they will all be owned by BPs and possibly 1 or 2 eccentric billionaires....not really an ideal system.

I have great respect for the slow and experimental way you have approached the entire project, but I think as far as experimentation has gone, this needs to be addressed sooner than later. I understand this is a unique approach to deter domain squatting, but the ultra rich and BPs will ultimately create lease models for the sub accounts they have won, creating the most prolific domain squatting event ever!

Just a thought. But also thank you for such an incredible project!

@crx-master
Copy link

Winning bid from starteosiobp, 90,088 EOS for "io" premium name at Thursday, 12 July 2018, 7 days ago!

Has the auction rules been modified?

The only different thing was last winner, geztaobygene account that paid 50,000 EOS for the "one" premium name, claimed the account only yesterday , 18 July 2018.

@blockminellc
Copy link

Yesterday it only shows EOS and COM sold. Today on EOSPark it additionally shows ONE, IO, and CN sold, but on EOSFlare IO and CN are still at auction with highest bid 90,088 and 35,200.00001 respectively...

Something really strange is going on.

@andresberrios
Copy link

andresberrios commented Jul 21, 2018

Reading this thread I've noticed there used to be a plan of imposing a partial refund on the bids that got outbid.

The existing bidder will receive a <partial?> refund of their bid when they are outbid. This encourages parties to bid high enough that they don't get outbid in the first place and discourages parties from going back-and-forth fighting for the name. It also discourages "squatting" on names hoping no one comes along to outbid them.

I was unable to see the previous versions of @bytemaster's comment, but I think the word partial was later removed, as the following sentences only make sense with it there. Also there is @aaroncox's comment saying:

Combine this with the partial refund (75%) and this could turn into a frustrating situation.

I checked the commit history of the system contract and saw that it was implemented with full refund from the start, so apparently this idea never got coded.

I would like to know why the idea of a partial refund was rolled back. It sounds like a good idea (although I'm not sure about what percentage would make sense), and I'm failing to see good reasons not to do it. Maybe it is actually desirable to have the auction go slowly? Since without disincentivizing the continuous outbidding, the auction's close time would continue to be delayed.

Please shed some light on this, I would like to understand the reasons and thought process.

@blockminellc
Copy link

Also I noticed on STARTEOSIOBP, if I'[m readig it correctly, they are receiving a combined (roughly) 1000 EOS a day in Block Producing and Votes. It will make it impossible to ever compete with that if they can use those EOS to bid!

@crx-master
Copy link

By the premium name auction rules, gm3denbwguge offer of 25,000 EOS for game premium name should have been set as a winner days ago!

For me, there is a problem with the bids table index, and the -35200.0001 EOS winning bid from f2poolshenyu for cn name is returning first.

So, as long as f2poolshenyu do not claim his premium name, the auction will remain stalled.

@andresberrios
Copy link

@crx-master yes, I noticed the same thing today.

@andresberrios
Copy link

I just submitted a fix in #4849.
I hope it will get merged soon so the auctions can continue, as some people must be pretty frustrated with their money locked in there as the top bid for several days.

@crx-master
Copy link

@andresberrios 15 days or so since last winner... do you know when your patch (or any other) will fix the broken names auction?

@blockminellc
Copy link

blockminellc commented Aug 17, 2018

@crx-master

Last I checked the ".ex" extension was bid on consistantly every day for the past 10 days up until the 14th.

However, something doesnt smell right. It looks actually like a stall tactic being used to bid ".ex" as the same two bidders keep bidding every 22+ hours back and forth at the 110% min, keeping the auction stagnent. I worked in auction for many years, buyers who really wanted to actually win would immediately bid after being outbid or they would gorilla bid a huge increase to scare off the other bidders. Wearing people down over time is ultimately a way to lose money in buyers premium...something this type of auction doesnt employ (like if you only got back 75% of your bid qhen outbid). Huge flaw in the design. I bet someone is either trying to break the system by creating doubt in its mechanics, or is a BP amassing more tokens over time to then only have to contend with 20 other BPs for all the other names, wiping out all the devs and other potential buyers.

@rixst3r
Copy link

rixst3r commented Aug 17, 2018

It's turning into a marketplace that favors those with more time/money with no actual use case or deadline over those whom have actual use cases and even also may have the money to spend but can't get what they need without potentially wasting a ton of EOS compared to what the name they need is actually worth.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
code review in code review
Projects
None yet
Development

No branches or pull requests