-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Quality Name Distribution & Namespaces #3189
Comments
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:
One additional thought - would it make sense to prefix (as opposed to suffix) these namespaces (aka reverse-DNS style)? Instead of |
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. |
Items left to do:
|
I see 2 potential issues with this:
I propose the following to alleviate these potential problems:
|
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? |
disagree. no need to artificially limit a FREE and OPEN blockchain. let people do whatever they want. thanks |
Good proposal, a few comments...
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.
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. |
@guaiguaihw as BM mentions, cost of bid goes into system saving account, just like WPF(worker proposal fund). |
It is not enough i think. Every DAPP developer wants a premium name. This limitation stops eosio adopting massive dapps. |
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? |
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. |
Should we consider renaming our reserved names/permission levels to be consistent with the suffix approach. For instance However, this is the reverse of the proposed scheme here and ideally we would have consistency such that the token contract would be emplaced @ |
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:
and then attempting to create that same token again results in an exception as the ticker already exists:
|
Token SYMBOL names should also have a custom distribution mechanism for the same reasons as premium account names. |
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? |
Will account names work across multiple eos sidechains, or will each sidechain have own account names? |
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. |
Side chains will likely import accounts from the main chain |
Do we see this live now? |
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能出来解释一下为什么要这样设置吗? |
See. |
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 We are a small Dapps developer that want a low class name only while we can't wait too long to acquire. |
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 |
only one name perday is weired. |
why not just start from 12 characters for the first year combine with the one day per account; |
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 |
Can anyone tell me what time exactly for the first round of bid ends in UTC TIME? Thanks |
from producer_pay.cpp of eosio.system contract onblock: 1 day after last name close and hightest bid has not changed in 1 day. |
can anyone help me confirm which exact date is the first bidding opening date? Thank you very much |
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. |
In seeing how the bidding process has gone and only 2 premium names have sold in two weeks I would agree with @rixst3r -
ie day 1 WYSIWYG sells in round 1 because it was the highest bid that did not have any action in 24 hours day 2 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! |
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. |
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. |
Reading this thread I've noticed there used to be a plan of imposing a partial refund on the bids that got outbid.
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:
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. |
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! |
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. |
@crx-master yes, I noticed the same thing today. |
I just submitted a fix in #4849. |
@andresberrios 15 days or so since last winner... do you know when your patch (or any other) will fix the broken names auction? |
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. |
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. |
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
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
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".
Future worker proposals could allocate the proceeds from the name sales.
12 character limit applies to the full name including the ".suffix"
The text was updated successfully, but these errors were encountered: