Opinion on DIP5-BlockchainUsernamePricingModel

[AndyDark]

Proposal: https://www.dashcentral.org/p/DIP5-BlockchainUsernamePricingModel
ID: 675c83fb78e06a0bea6af72cfd729df40ec083a1185af86fc86d87130cd27cb1

Hi GrandMasterDash,

Regarding your proposal DIP 0005 Blockchain Users, as one of the DIP authors from Core I’ll give my opinion here so that the network has all the information.

*Blockchain Username Constraints*

..please see https://github.com/dashpay/dips/pull/18

I think it’s better to start with a more limited name set; If we decide we need to reduce the name set later (e.g. removing hyphens as we find they break some compatibility somewhere), that’s basically impossible because it would be destroying user property, but its easy to HF new characters in later which just extends the name set users can choose from.

*Leasing*

I think it is important that BU names should be permanent and immutable. Requiring users to renew names means users can be caught out by not knowing / paying renewal fees, meaning it’s a ‘leasehold’ not a ‘freehold’ property, inconvenient and released names can enable phishing pretty easily in DAPs by the owner if the old owner didn’t realise their name could basically expire and be bought up by someone else - this would change the nature and economics of Dash Names as they are currently planned. Secondly, operators of the protocol are incentivised by rewards paid from economic activity of the users which is a market based mechanism and it’s a huge namespace (37 ^ 24 possible names), just burning Dash to keep a name owned isn’t really providing any great incentives or benefits to the network as I see it.

*Name length as a pricing model*

BU names are analogous to Domain Names in many regards but not that they should be leased and not that in shorter / memorable domain names are expected to have way more value. Domain names are used for website discovery (e.g. typing in a URL in a browser) so shorter (or “better” in some other way) can increase traffic and retention generally.

BU names are more like email or a twitter handles; they are human readable / memorable symbols primarily to discover/connect with counter-parties, to allow the aggregation of currently out-of-band messages and data that we are adding to the protocol to make the payment process easier through automation and reduction of complexity and overhead for end users. DAP creators have the option to use display names too, so like Twitter, the exact BU name might be a sub title to check the actual identity, with a display name that's using more characters, spaces, and easier to read, so again the BU name is less important in that case and doesn't need to be aesthetically perfect.

So when choosing a name it should be normal for a user who finds their desired name is taken to just choose a close alternative such as @alice1000 when @Alice is taken. So I would disagree with the squatter issue because unlike domain names its easy for a user to just change their name a bit like @alice1000 and @bob1000 rather than pay a premium to get their exact name as seems to be the assumption with the pricing model.

I think as Dash enthusiasts in a relatively small community today compared to what we are aiming for, it would be nice to get our exact name as we’re known in Dash already, but mainstream users don’t necessarily want the same as we do and I don’t think will care so much to get their exact name just like I don’t care if my Gmail address is slightly different to what I really wanted when I’m using my name more like a utility than a store front as per domain names. So the idea of land grab might not be such a winning strategy or even solved by this particular mechanism if it is and to me seems like a solution looking for a problem… and in the case that that’s wrong, names are a market so problems can always be resolved using market dynamics which is more of a Dash way than essentially price intervention in the name market based on some assumption of name length as a single pricing determination; if we wanted to implement a pricing model it could get a lot more complicated than that, and again why not let a free market determine prices rather than us trying to centrally plan that.

In reality making longer names cheaper incentivises users to just register really long names as they’re cheaper so this proposal might have negative affects not considered here so it I feel its better to keep it simple because that means we’re making the least assumptions before we launch it.

For these reasons I think DIP 0005 is good as is and I don’t think the proposed changes will be beneficial.

Thanks,

Andy Freer

 

[AndyDark]

For further information, I’ll post the bullet points on BU name requirements from a recent presentation I did internally. This is background info & design rationale on the public DIP 0005 content so it’s nothing new but might help provide more information:

Blockchain User requirements:

1. Pseudonymous alphanumeric symbols representing counterparties on the blockchain, plus mnemonic-seed for pubkey
2. Must be human readable and memorable, as per Email and Social Network handles
3. Must require a burn fee to create to disincentivize spam
4. Must be permanent & immutable to avoid hijacking or loss of funds
5. Must be transferable, to enable a Name market
6. Analogous to Domain Names in most regards, except purpose is counterparty connection not website discovery
7. Essentially each Name is a digital asset
8. Potentially subject to future quorum administration in the case of illegal usage
9. Separation of Dash Names with underlying financial transactions for privacy
10. Spendable rewards for updating user data; Doesn’t require a wallet or inputs/outputs; Names can be ‘topped up’ and spent with easily

 

[GrandMasterDash]

In this case, I fail to see what is being achieved with BU names. Just take a public key and display the first and last 6 characters. There's no meaning, authority or verification anyway because there's a user selectable Display Name. I'm sorry but I don't get it. We're going to spend millions educating people that the email they received to pay "IRS" is not genuine. And then forever.

People tack those numbers to the end of a username, not so much because they don't care, but simply out of necessity. Other payment apps don't need a username with numbers appended, they just use a telephone number. How are BU names easier than that? Easier to type? Easier to remember? Easier to verify authenticity? How are BU names making crypto easy? Other platforms, such as Waves, had huge problems because of a similar namespace structure.

A flat fee in perpetuity is an attack vector. Usernames "DCG", "DashCoreGroup", "StayDashy" and "DashForceNews" will all be taken by scammers, on day one and dragging our reputation down to the lowest common denominator.

Can we not make the minimum length 6 characters and come back to this later?

 

[GrandMasterDash]

I think, regardless of the decisions made here, we should at least acknowledge that 3, 4 and 5 character usernames serve a very real purpose; they are short and easy to recall. If we believe this to be true, then why should they sit within the same structure as 6+ character usernames? - after all, we are being led to believe that a username with random numbers tacked on to end isn't that important / significant.

 

[geolibertarian]

First, I'm glad Andy clarified there will be a "display name" separate from a BU name. It wasn't clear that there would be one before, but I'm relieved to see it here.

Can we not make the minimum length 6 characters and come back to this later?

This is a good point. The minimum length should be 6 characters, not 3 characters, because of the potential for abuse and controversy within the community.

Once they're taken (IRS, DCG, USA, etc.), that user can sit on it indefinitely. Why should anyone be able to control those names at all? Like Andy said, if people don't care about adding suffixes to a name, then they won't mind being required to choose IRS666 instead of simply IRS. But having a username of 3-5 characters is not only prone to abuse as GrandMasterDash said, but it's also unfair. Many people will desire them, and if they're willing to bid for them, at least that would be a more fair way of distributing them than a first-come-first-served bot/script with the fastest connection.

in the case that that’s wrong, names are a market so problems can always be resolved using market dynamics ... why not let a free market determine prices...

But how about the initial distribution? The initial distribution is not a free market if everyone that wants to pay a price in the market cannot bid on it. It's unfair if someone who is willing to pay more, closer to its "market value", cannot do so (as opposed to someone that gets it for nearly nothing just because he got in first - he definitely didn't pay a "free market" value for it).

So at least for now, require names to be a minimum 6 characters until there's more consensus about what to do. If you want to go ahead and include 3 characters..... then at least hold an auction for the names (at least for a set period of time - if no one bids on it in the first, say 6 months, then it likely has low-to-no value). If it is a very popular name, then an auction will find a closer "free market value" than just letting the first one who lucks out and gets their script into a block sit on the name indefinitely and decide whether he ever wants to sell or not.

 

[GrandMasterDash]

For the record, I agree with Andy to removing non-alphanumeric characters, they're not central to my proposal. The meat of my proposal is that short BU names have intrinsic value.

 

[AndyDark]

For the record, I agree with Andy to removing non-alphanumeric characters, they're not central to my proposal. The meat of my proposal is that short BU names have intrinsic value.

I don't think increasing the minimum length to 6 would have negative effects at launch (even though I don't agree that shorter names have a higher intrinsic value and even if they do the Name market can resolve that). And if we up the minimum length to 6 it just means the shorter names are not allocated into the possible name set and could be later without destroying user property. But I don't control the design, I (or anyone) can only propose things, for example PR this to the DIP repo then its down to what the other core devs want to do (with the exception of a governance decision).

About display names, there is no concept of a display name in the protocol. But a DAP creator could easily make a display name property in their contract and use that however they want on a frontend. So its likely people will do that.

 

[GrandMasterDash]

Can someone tell me, what is stopping a DAP developer from storing a DNS A record on Dash Drive and associating it to a username?

 

[AndyDark]

Can someone tell me, what is stopping a DAP developer from storing a DNS A record on Dash Drive and associating it to a username?

For an A record to work it needs to be configured in a DNS name server, i.e. there'd need to be some 3rd party bridge between Dash protocol and DNS.

If what you're implying is, is it possible to create subdomains per BU name on some domain then yes, e.g. andydark.somedap.tld, and that's one of the reasons for my PR I linked in the OP.

But it's a manual step. A DNS client can't resolve the domain / IP unless someone has bridged that manually.

It would be possible to bridge to domains obviously (e.g. andydark.tld) but there'd be collisions with existing domain names, only subdomains would be a clean space.

 

[GrandMasterDash]

For an A record to work it needs to be configured in a DNS name server, i.e. there'd need to be some 3rd party bridge between Dash protocol and DNS.

If what you're implying is, is it possible to create subdomains per BU name on some domain then yes, e.g. andydark.somedap.tld, and that's one of the reasons for my PR I linked in the OP.

But it's a manual step. A DNS client can't resolve the domain / IP unless someone has bridged that manually.

It would be possible to bridge to domains obviously (e.g. andydark.tld) but there'd be collisions with existing domain names, only subdomains would be a clean space.

Yes. So earlier, you said usernames are more utility than store front.. but given we don't know what apps will be built, it's possible someone comes along and creates a killer app where the username does behave like a store front? I mean, many alternative DNSs have been built and failed, but you never know, someone might actually succeed. How can we be sure the usernames will not become a store front to a future app?

 

[AndyDark]

How can we be sure the usernames will not become a store front to a future app?

Because there's no integrated way to do that trustlessly because DNS is a separate protocol.

In other words, I can create http://grandmasterdash.somedap.tld or even http://somedap.tld/grandmasterdash today and claim thats you. Then lets say BU are released and you register that exact name - there's still no integrated proof that that's actually your BU i.e. anyone can create those URLs and any site that's doing that users basically have zero trust of.

Even if someone created JS in an HTML page that would verify the code on that page was signed by that BU, every request would need to be verified in the same way, and anyhow its in a browser so this is still inadequate - there's no way to tie Dash protocol to DNS in a trustless way right now so using BU name for DNS discovery is basically a fully external 3rd party step that users would need to trust. (if the network buys the .dash tld this may change)

 

[AndyDark]

Yes. So earlier, you said usernames are more utility than store front.. but given we don't know what apps will be built, it's possible someone comes along and creates a killer app where the username does behave like a store front? I mean, many alternative DNSs have been built and failed, but you never know, someone might actually succeed. How can we be sure the usernames will not become a store front to a future app?

If I can try to break this down in a simpler way: in DAPs BU names will be used to remember a connection you make with a counterparty, within a wallet. Whether that's B2B, B2C or C2C, the purpose will be having a symbol you remember so once you do a single trusted step (a user proves to you that that symbol is them) then from that point you will sign messages and pay to them and they will do the same back to you.

I can make any website i want that's integrating a DAP, but you shouldn't trust that unless I sign a message with my actual BU name that you already know, and you verify that in a wallet via the blockchain.

Therefore BU names are really for identity confirmation/verification between counterparties within wallets, not discovery of commercial entities (as those can use any URL / display name / blah) - users will always need to trust that messages are from a BU name they already confirmed themselves through some trusted step.

edit: i mean there are discovery usecases. But i don't think these are predominant or a reason to try to preempt pricing models etc etc

 

[GrandMasterDash]

Okay, I understand, it's like someone choosing a variable name in computer code. The Blockchain User could well be computer generated and never exposed to end users. Call it semantics but I'm beginning to think "user" is the wrong terminology.

 

[moradielle]

If I can try to break this down in a simpler way: in DAPs BU names will be used to remember a connection you make with a counterparty, within a wallet. Whether that's B2B, B2C or C2C, the purpose will be having a symbol you remember so once you do a single trusted step (a user proves to you that that symbol is them) then from that point you will sign messages and pay to them and they will do the same back to you.

I can make any website i want that's integrating a DAP, but you shouldn't trust that unless I sign a message with my actual BU name that you already know, and you verify that in a wallet via the blockchain.

Therefore BU names are really for identity confirmation/verification between counterparties within wallets, not discovery of commercial entities (as those can use any URL / display name / blah) - users will always need to trust that messages are from a BU name they already confirmed themselves through some trusted step.

edit: i mean there are discovery usecases. But i don't think these are predominant or a reason to try to preempt pricing models etc etc

Okay, I understand, it's like someone choosing a variable name in computer code. The Blockchain User could well be computer generated and never exposed to end users. Call it semantics but I'm beginning to think "user" is the wrong terminology.

 

[Joao77]

Nice info...