Namecoin?

What about it?

What is really necessary though is micropayment middlemen. The set up and settlement costs for micropayment channels between the two parties exchanging money for services is going to be too costly on BitShares or Bitcoin for many micropayment applications. It is best to have a free market for micropayment middlemen where there are hopefully not too many choices splitting up buyers and sellers but also still a highly competitive market to drop profit margins to near zero thus saving costs.

Buyers and sellers could join one or more popular middlemen by setting up a micropayment channel with them that is intended to expire in a day. Buyers would have to pre-allocate some balance in the channel for each middleman that they suspect is large enough to get them through the days worth of micropayments they expect to make. For each connected seller, the middleman would need to pre-allocate some initial balance in each channel. This means the middleman needs a large amount of capital to meet the daily micropayment needs of all the sellers it wants to be able to service (it could have less but then it requires frequently settling and reopening the micropayment channels of buyers to get the funds to then fill up the balances of the seller's micropayment channels, which all adds up in fees). The middleman needs to collect enough revenue by taking a cut in the micropayments delivered in order to justify the opportunity cost of not investing all of that capital (as well as the less significant operational cost of running the servers). The middleman might require the seller to put up an equal amount of the initial balance in a separate fund as part of the channel which they fully get back when the channel is settled as a way to prevent distributed attacks by competitors trying to get the middleman to tie up large amounts of capital (since the attacker would also need to tie up equally large amounts of capital, which is costly).

These micropayment middlemen wouldn't care what the micropayment are being used for (torrenting, tips, bandwidth, etc.). As long as a buyer and seller are already on the same micropayment middleman and the balances on their existing channels are sufficient, they can deliver the micropayment via the middleman for a percentage fee rather than a fixed fee. If there are a few good middlemen, the likelihood of buyer and seller already being on the same middleman is high. Furthermore if there are many equally good options for buyers/sellers, buyers and sellers can filter each other based on the middlemen they are on to avoid needing to set up a micropayment channel with a new middleman and thus further save costs. If done right, this might mean that the fixed costs that buyers and sellers need to pay is on the order of a few cents per day to meet all of their daily micropayment needs with various different parties (this would of course not include the percentage fee they would need to pay on the total value transferred via micropayments).

Of course a lot of the above complications for middlemen could be avoided if buyers and sellers can just trust the middleman with the money they are owed (no more than a day's worth of payments need to be trusted) and the sellers are okay with waiting one day until they can get their payments. If the middlemen already have a strong reputation, trusting them may not be too much to ask for. In that case, the buyers need to just replenish their balance once a day and sellers can withdraw their balance each day (but delayed by one day). If buyers don't want to trust the middleman with even a day's worth of balance, they can set up the micropayment channels instead, but the sellers don't have that option. Again, the fixed costs would just be a few cents per day for buyer and seller. The percentage fees would also be lower since the middleman would not have to tie up a large amount of their own collateral.

tl;dr Basically ICANN on the blockchain but owned and controlled by UIA holders and also where new names can either be put on auction immediately or be purchased by the name claimer for a fixed fee that depends on the quality of the name (usually meaning the length). The fixed fee structure (and other properties of the system) can be controlled by a committee elected by the UIA holders (assuming a necessary quorum agree and with a 2 week delay just like with delegates), and it would be designed to force name claimers of shorter names (which are likely to be higher valued) to always prefer the auction route instead but name claimers of longer names (which are more likely to be used for account names) to be purchased for a reasonable fixed fee. The committee also can collectively act as a judge (or more realistically delegate responsibility to multiple trusted judges) who run their own private (and profitable) court system to listen to claims of trademark infringement (if that is the policy UIA holders choose to adopt) and can enforce their ruling by forcefully taking away a name from a current owner and giving it to someone else (assuming the necessary quorum is reached and again with the 2 week delay which gives the UIA holders the opportunity to veto the action by voting out members in the committee).


I would love to see the following experiment in one of the namespaces that could be potentially used for domains and even account names (see my post discussing various economic models that could be used for different namespaces). This namespace could be used to point to web sites and/or point to accounts (possibly in addition to whatever other account name system also exists).

The idea behind this naming system is to not have ownership only be determined by a set of rules on the blockchain but also by decisions by a group of elected people. These people can act as arbitrators in matters that the blockchain either cannot have knowledge of and/or cannot have the intellect to decide what is fair and just according to the vague human policy it is supposed to follow. That means this naming system could in theory respect existing trademarks making it more attractive to corporations, but it does not need to be limited to following the policies that ICANN currently follows or even necessarily follow the IP laws of a particular country (in that case, you better hope the necessary quorum to make decisions on the blockchain cannot be reached by a subset of the known elected arbitrators residing in the jurisdiction of that country).

There would be a special UIA that represents ownership of this naming system itself. The UIA holders can vote for the number of elected arbitrators (N) to have and the arbitrator candidates themselves. This would be the same system used for selecting delegates and the number of delegates to have. The top N arbitrator candidates would become the elected arbitrators and their weight would be determined by their relative approval votes (just like in the delegate system). If the necessary quorum (weight greater than some defined threshold) of elected arbitrators agree, they can forcefully move ownership of one of the names to another account. This could be useful in giving the legitimate trademark owner their name. Another possible action they can take with the proper quorum is to take away an existing name from an owner and putting it up for auction. Just like with the delegates, any action taken by these electors has a 2 week delay allowing the stakeholders the option to veto the action by voting out enough of the arbitrators.

All new names would be classified by a computer algorithm into the class they belong to. The algorithm would typically make the decision based on the length of name. A user trying to register a new name would either have the option of paying the fixed fee specific to the class the name belongs in to own the name, or putting it up on an open auction where they could then try to win the name by being the highest bidder. The user would have to pay a very small fixed fee (potentially growing with the length of the name) just for the privilege of bringing a new name into the system and getting the exclusive choice to either pay the fixed fee for the name or put it up on auction (this fee is to always at least compensate the network for the technical expense of managing the names, even if the market price ends up being 0). If the user believes the market will value the name at a lower price than the fixed fee for its class, it is rational to choose to put it up on the auction rather than paying the fixed fee. The fees for each class can be set and adjusted by the arbitrators (again with the 2 week delay).

I would expect really long names to belong to a class with a low fixed fee, so regular people could afford to get their full names (maybe with a number at the end) for low cost and use them as their account names. People with short first and last names (or a short pseudonymous handle) that are nevertheless uncommon would likely put the name up on auction and end up paying around the same fee as the low fixed fee (they just would have to wait 30 days before they were able to get their name). Short names would belong to a class with an intentional outrageously high fixed fee, forcing everyone who wants to get such names to choose the auction route instead. The auction system would try to fairly price the name. If the name is a high-valued name already owned by a big company, it is likely that the auction will not fairly capture its market value because the people with the big money to bid it up would not yet exist on the network by the time the naming system opens up. Because these would be well established names of big companies, the arbitrators would likely decide to take the name away later when the trademark owner complained, and this fact would likely cause squatters to think twice about paying a moderate fee to "own" this name.

I would like to see how such a system evolves. The arbitrators would likely act as judges (or rather delegate that task to selected judges they trust, which also allows them to scale their operation) running their own small courts where they listen to both parties and examine the evidence to see whether the prosecutor has a legitimate claim on the name (legitimate by the policy set by the UIA holders of course). The UIA holders would want to set a policy that was reasonable and mostly respected existing trademark laws since it would make their name system more attractive to people and therefore give it more value. The judges would get paid by the prosecutors who would have to put up funds to compensate the judges for taking the time to listen to their case as well as to set aside funds that would pay the defendant (the existing owner of the name that they claim belongs to them) for their lost time in the case the judges rule against the prosecutor. A few other major differences I would expect with this system compared to regular courts is that the entire thing could be done virtually using the internet (making it easier for all parties involved to "meet") and of course the defendant would not go to jail for "contempt of the court" due to not showing up or being rude (the worst possible thing that can happen to them is that they lose the name with absolutely no compensation). So I think this would be an exciting use case to try out the concept of private justice and see how well it actually works in practice (at least in this narrow field of trademark disputes).

The fees on the prosecutor may be set so that after compensating everyone needed there would be extra funds that could be placed into this naming system's special reserve pool (different than the BitShares reserve pool). I would expect the fees to be set pretty high to avoid spreading the judges too thin and to just focus on the high value cases dealing with the trademarks of medium to large companies (smaller trademark claims could probably be more cost effectively settled out of the courts between the existing name owner and the name claimer, but would also be less likely to be necessary since lower value names are less likely to be taken by squatters and also due to other methods we can devise [1]). The reserve pool would also have an income stream coming from the paid fixed fees and the funds collected from the auctions. It would also have an expense stream that paid the arbitrators some daily salary (which could be adjusted by the necessary quorum of the arbitrators but with the 2 week delay) to compensate them (and also allow them to compensate judges they may have delegates tasks to) for the ongoing costs they have regardless of whether any cases come up (and to motivate them to be available to do their job properly when a new case does come up). Finally, the arbitrators could (again with the 2 week delay) pay out a dividend from the reserve pool to the UIA holders. Ideally, I would like to see dividend support built in to the blockchain as an operation for any UIA. But short of that, the 2-week delayed operation might just move the funds from the reserve pool into another account collectively managed by the arbitrators without delays that would then be responsible for manually transferring those funds in proportion to a snapshot of the UIA holders taken on the block in which those dividend funds were first moved out from the reserve pool.

[1] One other thing the arbitrators might do (assuming the UIA holders allow) to help reduce squatting is to run an automated system on the side that does the following. It allows someone to submit a form requesting unauthorized registration of an already established domain name by providing the ICANN domain name of the same name (with some set of accepted TLDs). If the claimed name meets certain conditions (perhaps less than a certain length) and also the domain name was registered in the ICANN system (with one of the appropriate TLDs) before the name was registered on the blockchain, it then moves on to the next stage. The next stage involves providing a random large number to the claimer and requesting that they put that number in its own file accessible from a specified URL using the ICANN domain name. After the claimer does this and provides the URL back to the automated system, the automated system checks that the numbers match and if so moves on the next stage. This next stage involves waiting for some period of time for any counter claims. People who own the same name with another higher-ranked TLD (the appropriate set of TLDs this system recognizes will be ranked) can go through a similar process for their counter claim to either maintain existing ownership on the blockchain or to take ownership of the name themselves if they don't have it already. If the period ends without any legitimate counter claims, the system automatically coordinates with all other arbitrators (each one could be running this automated system and the claimer would be using a client that submits this info to all of their servers) to sign a delayed transaction that automatically takes that name from the current owner and puts it into an auction. This allows the claimer to own the domain by paying the fair market price for the name (which could be cheaper than the fees they need to pay to try to take it to arbitration courts directly). It means that the existing owner of the domain cannot extort the claimer by demanding them to pay higher than the fair market price. For this reason, the existing owner will be willing to sell the name to the claimer (assuming they prove they actually own the ICANN domain) for much lower than the market price because at least then they get some money out of it. This reality will make squatting on existing domain names far less likely even for small companies that could not afford the court fees. And the squatters speculating on names that are currently not owned by anyone in the ICANN system would be paying for the fair market price (at the time they claim it) because of the auction. So if they make any profit at all from that name, it is because they had the foresight to claim a name that no one else was using at the time and that no one else thought would be as valuable as it ended up being. And that isn't evil squatting but rather legitimate speculation. Also, the existence of this mechanism doesn't cannibalize the revenue source for courts. Those are focused on high value names where the market price of them would likely be higher than the court fees (therefore it is rational for those name claimers to settle the dispute in court and get the name rather than using this automated system to then have to bid on the name). However, it is also important to consider that from a squatters perspective they know that a name can be taken from them by the legitimate owner for only the cost of the high court fees. Therefore, it is in their best interest to just sell the name to the legitimate owner for a lower cost than the court fees. This also means that it wouldn't be rational to pay more than the court fees in an auction for a name legitimately owned by someone else. Thus these mechanisms effectively put an upper bound (worth approximately the cost of the court fees) on the cost of any given name.

- Now we have only one step in pricing (8 characters). Maybe there should be more? Short names would be very expensive and with every character price goes cheaper?

That is already possible with Graphene. You can charge a different fee depending on the number of characters in the name up to 8 characters (after that it is non-premium and the cost is fixed).

- Is auction possible? If you want to register a name, you would have to wait for a period (like 24 h or a week) and during that time everybody else could see what name you are going to register and make a bigger offer for it if they see it valuable. This would propably optimise the income that Bitshares gets from name selling.

The way I see it there are three significant economic models for names (there are infinite variations of course, but these are the three that are most important in my opinion):

• Pay a fee to register a name where the fee price is determined by an algorithm and not by the market (the algorithm could be as simple as a fixed fee, or it can charge different prices based on character length like Graphene does today), and then you fully own that name forever with no other costs (maybe a very small fixed "I'm still alive" fee every year).
• Use an auction to determine the initial price of a new name (or a name that has since been lost due to the owner not paying the small fixed "I'm still alive" fee), but after the name is sold, the owner gets to fully own that name forever with no other costs (other than the small fixed "I'm still alive" fee).
• Use a leasing model. The "owner" of a name does not truly own it. They initially use an auction to buy a limited time lease to control the name and the right to extend the lease without disruption. However, each time they get the opportunity to re-extend the lease, they need to pay a fee for the extension that is determined by market forces. An auction system could allow the blockchain to know what the market value of the lease extension would be, and it would require the current lease owner to pay some fraction (perhaps 100%) of that price before their lease expires to extend their lease or else they forfeit the lease to the highest bidder at the end of their lease.

We can implement any subset (including all three) of these economic models. However, each of them require their own namespace. This means the same name can exist in all three economic models and they are disambiguated by the namespace they belong in.

My thoughts are that we should have at most two namespaces (one for domain names and potentially one for account names). I think economic model 1 or 2 is appropriate for account names (if we even have any) and economic model 2 or 3 is appropriate for domain names. Domain names could also have a "default account" parameter that points to an account ID. Therefore, even if we get rid of account names, domain names could still be used as a sort of account name for those who choose to pay the cost of maintaining them (the rest of the people wouldn't bother with account names which as I have discussed elsewhere aren't actually necessary).

My first preference is to have account names follow economic model 1 (despite the squatting potential) and domain names follow economic model 3. My second preference is to have account names follow economic model 2 and domain names follow economic model 3. My third preference is the get rid of account names and only have domain names following economic model 3. My fourth preference is to get rid of account names and only have domain names following economic model 2.

One other possibility is to mix economic models in the same namespace depending on how an algorithm classifies the name. For example, we could have domain names follow economic model 3, but account names would either follow economic model 1 or 2 depending on the length of the name. An account name that is 10 characters or longer could follow economic model 1, but account names that are less than 10 characters long would follow economic model 2.

I already discussed this elsewhere but I think it is important to allow some semi-trusted third party to claim vote tallies from the blinded BTS balances of some selection of accounts. But it has to be done in a way that prevents the third party from changing the votes (they could only choose to exclude accounts from the vote tally, but not use their stake to vote for someone the stakeholder didn't vote for). So let's say some subset of accounts with blinded BTS balances decide to elect a particular third party to see their BTS balance (by privately sharing the blinding factor with the third party) and aggregate their vote. The third party would specify the account IDs of all the account's vote it will be aggregating. It will also specify a blacklist of delegates/witnesses/workers that it will not aggregate votes for because not enough of the specified accounts are voting for that delegate/witness/worker (which would compromise privacy for the few accounts in the selection that were voting for that delegate/witness/worker). Then for each member in the union of the delegates/witnesses/workers that were included in the votes of the selected accounts, the third party provides a plain-text stake tally and proof that the sum is valid. This proof is a commitment of the tally and a signature proving that fact, where the blinding factor of the commitment is selected so that the sum of commitments of the BTS balances for all accounts voting for the specific delegate/witness/worker (subtracted by the sum of the commitments of the BTS balances for all accounts voting against the specified worker, in the specific case of workers since they can be downvoted) equals the commitment of the tally provided as part of the proof. In other words, for each member X (delegate/witness/worker) add all the blinding factors of accounts approving of X and, if X is a worker, subtract all the blinding factors of accounts disapproving of X to get the blinding factor for the commitment to the tally. This transaction only needs to be provided to the blockchain once per maintenance period to save costs (it is okay if there is even a 1 day delay in incorporating all the votes).

Damn. I just thought of a complication to the above that can compromise privacy. If one account changes their vote from one maintenance period to another and they are the only one to do so, the public could compare the differences in the aggregated votes to determine the stake of the account. Even if a few accounts do this each maintenance period, it may still be possible to over time figure out their stakes as long as the members from that set change their votes in different unrelated sets in other future maintenance periods. Basically, unless you have a very large fraction of voters all changing their votes in the same maintenance period, you will likely leak  information over time. Extending the maintenance period for voting can help with privacy but at the cost of increasing the delay of incorporating the updates to votes by blinded stake.

Privacy is damn hard.

I would rather get rid of account names entirely than keep them non-transferable. But keeping transferable account names shouldn't be an issue if we design things right and teach users sensible practices.

tl;dr Just use account IDs for everything (especially for links on the internet and referring to identity in third-party databases). The only time account names should be used is to add a new contact to your address book that you were not able to add through better means such as trusted web links or mobile-to-mobile communication. The GUI shouldn't allow the user to do anything of value with an account unless they are first added to the address book (perhaps even added automatically to some obscure part of the address book because of some action where the smartphone is interacting with the real world, for example for POS payments). Adopting these practices should deal with the vast majority of the issues. What remains are edge cases dealing with what happens when a contact changes their account name after telling you their account name but before you have the opportunity to add them to your address book. Those cases can be handled through changes to the GUI of the client and proper education on how to use the client.


The first thing to realize is that if you want to allow account owners to be able to update all private keys associated with their account for security reasons, then it is impossible to prevent account names from being transferred. The current owner could just sign a transaction using the current owner key changing the owner key of the account to one specified by the buyer of the account name. Yes, all identity information would be transferred along with the account, but a name squatter buying valuable names for the purpose of later selling them isn't going to care about that. The security benefits of changing the owner key are very important that I would say it outweighs any other concerns about identity you may have when account name becomes transferable.

So once you accept that you cannot avoid allowing account names to be transferred, you might as well make it possible to transfer the account name without also transferring all the other identity information. In fact, there needs to be a clear separation between an identity and an account name. That brings me to my main point...

Your account name is not your identity! Your identity is your account which can be uniquely and immutably referred to by the account ID. This is the thing that can be stored in third-party databases, NOT the account name.

Now that is fine for computer databases, but human brains aren't good at remembering large numbers. So clearly people would prefer to instead remember a human readable account name over an account ID. How do we avoid the human error this can cause when we consider that the name of an account can change and the old name can belong to another account (meaning another identity)? The solution is for humans to not try to rely on their memory but rather rely on computer databases. The mapping between the human-understandable information describing an identity to a unique account ID should be local to each user. This is the information that will be stored as part of the wallet file (which is stored in the browser's local storage, but can also be exported and backed up elsewhere). In fact, I think it would be smart for the wallet hosts to provide a service where they store an encrypted version of the wallet file for the user and sync it as necessary to their clients. The point is that the mapping is local to each user and not global on the blockchain. This means that every user can specify the alias (and even picture and other information) that helps remind them who that contact in their address book really is. None of this requires any global blockchain name registration or management.

However, with all of that said, name registration on the blockchain is useful. Particularly, it is useful as a method to allow humans to add new contacts to their address book when the only way they are able to refer to the account is through a uniquely-identifying string/number that they are forced to remember. The context through which they came to know or meet this new contact may not have facilitated using better methods of adding the contact right then and there, such as direct mobile-to-mobile contact sharing or clicking on an add contact link from some trusted web source or even scanning a QR code with their smartphone that was presented to them in person by the contact. Perhaps they didn't have their smartphones or didn't have time to use them and the contact quickly shared the uniquely-identifying string/number before leaving. Perhaps this string/number was shared over a medium where the validity of the source could be readily verified thanks to biometric authentication or trust in the provider of the media, such as a well-known guest with recognizable voice on an audio podcast saying and even spelling her handle, a video podcast showing the respective handles of guests whose face people can recognize in the lower third overlaid when they are on camera, a presenter that people know displaying their handle in his slides during a live lecture, or just simply the new contact they meet telling them the handle in person. Now the number could just be the account ID or the string could be a sequence of dictionary words encoding the account ID (+ a checksum), in which case name registration is again not necessary. The problem is that since the user is not able to choose their account ID (and thus the deterministically derived string of words representing the ID either) it might still be difficult for humans to remember them (although the sequence of dictionary words encoding the account ID trick does get pretty close to being memorable). Also, from a vanity point of view, users may wish to have their own choice of the string that they present which will map to their account ID even if faulty memory wasn't that big of an issue. This leads us to registering globally unique account names on the blockchain and mapping them to account IDs.

So that is when all the various edge case problems come in that need to be dealt with. If a person registered the account name once and never changed it, there would be no problem other than typos and misspellings which could be solved by also remembering, sharing, and including a small easy-to-remember number that acts as a checksum. And once a user adds a contact into their address book using their handle, their client should be designed to protect them from account name changes because it can remember the immutable account ID of the contact locally (and this local data should be backed up with the rest of the wallet). The tricky part is in the case where the contact changes their account name in between the time the contact veritably shared their original account name in a way that the user could access and the time the user added that contact using the original account name that they remembered. Even this is not an issue if the old contact name is not transferred to or claimed by any other account before the time the user adds the contact since the client would respond to the user that the account name is not currently being used and could show the past history of ownership of that name. What we really want to avoid is another account adopting the old name before the user adds the contact using the old name causing the user to add this other account instead of the original account. But the blockchain tracks when account names are created, moved, revoked, and adopted, so this information history could be made available to the user's client. If the account name provided had recently (this could be a wallet adjustable setting but a default of two weeks seems like a good idea) changed ownership, the client can show massive warnings to the user, provide detail, and require further action before proceeding. The information provided would allow the user to determine which of the accounts they meant to add depending on when they got the information about the account name. This is an edge case, so usually these warnings would never appear since the account name would have most likely not been recently moved. As long as the user is not adding an account name from a very old source, they should be fine. If they do want to add an account name from an old source (more than 2 weeks old for example), the client could provide an advanced interface allowing them to specify a date to determine the ID of the account that owned that name at the date. Since I believe the use case for adding contacts using their account name should mostly be for in person interactions where smartphone contact transfer was not applicable, or live radio or TV, I don't think this will be a problem. If someone is consuming old recorded media, it is probably a better idea to not trust that handle and instead try to find the handle of the person they want to add from a more recent source just to be safe. And in the case of consuming the handle from an online source, the best practice would be for the website to just include links that point to the account IDs directly to just avoid these problems.

{Disclaimer} I did not get toast/Runes big break through idea that interest is bigger than collateral, so...take the above with a grain of salt!!!

Yeah, I'm not sure what any of that has to do with the changes discussed in this thread.

As far as I understand (and I am really not sure if I do), he is just talking about how things break down and require changes when something like BitUSD becomes the unit of account for goods and services (meaning when we have succeeded in world domination ). That is a very interesting discussion to me and would love to hear more about your thoughts, toast, about what the new system would need to look like and how the transition from the old system to new system could happen.