suggestion: add a call for defining a new namespace

[shea256]

In the current system, all namespaces simply exist and don't need to be created. If you want to start operating in a namespace, you simply use a prefix that has the namespace properties in it (like pricing rules and whether names expire or not) and a human-readable identifier of length 1 (in order to distinguish it from other namespace with the same properties).

I'd like to explore a new system, whereby namespaces are explicitly defined and then they can be used from that point on. In this system, names could only be registered in existing namespaces.

Namespaces would be created with a namespace creation operation with the following effects:

1. the properties of the namespace are laid out, including the identifier of the namespace, the name pricing rules, and the name expiration rules
2. a namespace creation fee is paid (to prevent spam)
3. the namespace is added to the list of existing namespaces

Here is an example of a possible namespace creation operation as part of this system:

CREATE NAMESPACE
Operation fee: 1 BTC
TLD: .cool
Name lifetime: 1 year
Baseline name price: 0.01 BTC
Name auctioning: false
Name price decay per letter: 2x

There are 26^4 or 0.5M possible 4-letter TLDs. This means that 0.5M bitcoins would have to be spent to initialize all of the possible namespaces. People would be wise to choose TLDs that don't conflict with existing ICANN TLDs. Further, TLDs don't have to be used in practice. At minimum they act as a unique identifier for the namespace.

To be clear, if a namespace is defined it is not owned by anyone. The person who defines the namespace simply gets to set the properties of that namespace.

[shea256]

@muneeb-ali @taoeffect thoughts on this?

[taoeffect]

@shea256 cool stuff. A few questions:

• What is the "Operation fee"?
• What's the interface for creating one of these? Do you use the CLI and answer questions? Is there a file format that is read in? CLI arguments/options?

[arbedout]

I know this isn't an open call for comments, but reading through the issue, I had some thoughts for the initial implementation:

Bootstrap the 'root' namespace manually (let's call it ns/ in this example); Further namespaces will exist as k,v pairs in this namespace, with the key being the namespace name and the value being a list of policy parameters.

This would allow a structure like the following for shea256's .cool example TLD:

ns/ 
ns/cool,[{fee:1BTC,life:365D,created_on:032420151920,modified:032920150014,base_price:0.01BTC,auction:false,letter_decay:2}]

This way registering a namespace would only require registering a key in the ns/ namespace. Once a key is successfully added to the ns/ namespace, a new namespace will automatically be created (e.g. if ./ represents the root of the namespace tree, once ./ns/cool exists, ./cool will be created), and the k,v pair in the ns/ namespace will be used to confirm and enforce namespace policy (e.g. fees and decay rate). This also provides a neat way of modifying namespace policy independent of changes to the namespace itself.

[arbedout]

To add to this: I think namespaces can be extremely powerful, and more than just delimiters, with a bit of structure added client side. I'd like to propose a special record type for namespaces, let's say the ons record, that encodes namespace policies. Here's an example adding on to the cool TLD we've just created above:

cool/
cool/ons,[version:2015-03-30-001; bytes:86753095; records:100000; created:201501102104; modified:201503302105; desired_latency:100ms; desired_country:mx,us,ca;  desired_speed:100Mbps;  minimum_replicas:20; digest: false; md5sum:dfe4e46054224e0957c20c1e0931c824]

A client setting this record is saying "the cool TLD is specifying policy as defined in API version 2015-03-30-001; the total number of bytes in this namespace is 86753095, with 100000 records total; created date is such and such, last modified on such and such (UTC timestamps here), and we will provided additional incentive to DHT participants who serve records with a desired latency of at most 100 milliseconds, or if DHT nodes are located in IPs that are in mexico, canada or the US, or if they are hosted on connections with 100Mbps or more of bandwidth available. We want data spread across at least 20 unique nodes. Digest mode is set to false, and the checksum of all the records is dfe4e46054224e0957c20c1e0931c824."

This allows namespace owners to communicate to DHT participants their incentives for serving different namespaces, and a means of making the network more responsive to buyer demand. Put it another way: different data will want to live in different places and different speeds, and should pay different prices. We should let the market participants work out which data lives where with as much granularity as possible. Communicating this policy can be as simple as performing a lookup for the ons.cool record and parsing the response.

Digest mode is an idea for cutting down on blockchain bloat: if digest mode is set to true, we should only need to assign unspent BTC outputs once, to the ONS record itself, which contains the size of the namespace, total # of records, hash of the contents, and last modified date. This way we certify the contents and integrity of the namespace on the blockchain without having to account for every single record with an unspent output. This needs to be fleshed out more but could pave the way for namespaces with thousands to millions of records (dewey decimal system on the blockchain? or maybe the human genome? :) since we wouldn't have to tie a bitcoin transaction to each record.) The first potential problem I can think of would be assuring that the underlying records aren't deleted/tampered with - e.g. checking and verifying that the details specified in the ONS record jibe with the reality of what the DHT participants are serving up.

This ties into issue #59 as DHT incentives are still being worked out. I'd definitely vote for latency/location/"goodput" being part of the parameters that DHT participants can/should be incentivized for.

[shea256]

@taoeffect

What is the "Operation fee"?

By "operation fee", I meant the mining fee that must be paid in order for clients to recognize the transaction as a valid blockstore operation. It could be also called "name operation fee" or "action fee" or something. Can't think of a better word for it.

What's the interface for creating one of these? Do you use the CLI and answer questions? Is there a file format that is read in? CLI arguments/options?

I was thinking you would use the command line and specify a JSON file with the parameters. If the data is compact enough, then it would be encoded into the OP_RETURN of the transaction. If it's not, then it would probably have to have it's own entry in the DHT. My guess is that 40 bytes wouldn't be enough for the options previously specified but 80 bytes would.

@arbedout

Bootstrap the 'root' namespace manually (let's call it ns/ in this example); Further namespaces will exist as k,v pairs in this namespace, with the key being the namespace name and the value being a list of policy parameters.

I think this is a great idea. It seems like this parallels the traditional DNS system. I'm sure @muneeb-ali will have some good thoughts on this.

[shea256]

Also, as a side note, I just floated this idea out there because I thought it would be good to explore. There are definitely downsides to it and I'm not convinced myself, but it's possible this would be a great addition.

Incorporating this would be an alternative to the existing mechanism of establishing TLDs, where someone creates a namespace like d/ on namecoin and then decides the community decides to refer to it as ".bit".

The upside of this pre-existing process is the TLD naming is a human/community convention, so the TLD for a given namespace can be changed through discussions within the community.

The downside of this pre-existing process is when you start to have many namespaces, this can lead to immense confusion and an actual lack of convention formation. Further, developers will continue to see "d/wikipedia", which is a much worse developer user experience than being able to see wikipedia.bit directly in the code.

[shea256]

@arbedout very interesting ideas around DHT and data retrieval settings. That said, I'm not so sure the namespace is where we'd want to set these parameters. It seems like a "layer on top" thing. There will be many resolvers that cache all of the data and return it, and I'm sure a market will develop around that. Also, we have no way of incentivizing nodes to date. Again, a good area for @muneeb-ali to chime in, as he'll know more on this than I will.

[arbedout]

@shea256 agreed, I'm not sure that policy for a namespace belongs in that namespace either (or at least that it should be enforced by the ONS record). I do think different policies per namespace would be very useful, along with the option to tie bitcoin outputs to a single verification hash for an entire NS's worth of k,v pairs. The main benefit of an ons record at this stage would be that it isn't set in stone - you can test policy and implementations without having to build the 'layer on top' first, and if you change your mind then only a few lame ons records need to be deleted. The drawback is that this almost certainly guarantees that the ons record would be the final implementation of the feature - once it ships, it's in production...

Incentivizing nodes is a bit of an issue :) My main concern would be, without incentives (and per-namespace incentives as well), all the nodes participating in the DHT will either be charitable endeavors, or be collectively compelled to race towards a Nash equilibrium of latency and throughput performance. But that discussion belongs in #59 I think, so I'll move it there.

[shea256]

I'd like to modify this proposal and suggest that a namespace can be instantiated with a list of pre-registered names and their owning ScriptPubKeys (consult https://en.bitcoin.it/wiki/Transaction if you're not familiar with this term).

The remarkable thing about this is it would essentially upgrade the "create namespace" call into an "import namespace" call. Namespaces could be migrated over seamlessly from other blockchains like Namecoin. And the best part is that users would be able to use their existing private keys to manage the names.

[jcnelson]

This has been implemented. See the Usage document.

Further things to work through, on top of what we have:

• how do we upgrade a namespace's version?
• do namespaces expire, and if so, what happens to their names, and can they be renewed?
• should there be Blockstore to not track all namespaces?

[shea256]

:+1:

As for the first two questions, those are tough ones that we should probably revisit in another thread.

should there be Blockstore to not track all namespaces?

That seems like a reasonable feature. Maybe there can be a setting for only tracking select namespaces.

[jcnelson]

That seems like a reasonable feature. Maybe there can be a setting for only tracking select namespaces.

Can do; will implement :) Tracked in #117

[arbedout]

Very cool @jcnelson ! Reading up more on Usage now.

Question: Can namespace fee policies be updated? If prices are denominated in BTC, then a reasonable price set today might not be so reasonable in X months / years due to price volatility. (I guess this ties into whether namespaces expire - renewing a namespace could serve as an opportunity to update the fee structure).

[jcnelson]

@arbedout At this time, namespace fees are set once the namespace is revealed, and do not change. This is because there isn't a feasible way to retroactively alter the price of the names in a way that is fair to everyone. Even if we came up with a decentralized way to get a quorum of name-holders to vote on the price, namespaces could still get taken over by a quorum-holding sybil that could then impose prices on everyone else.

Renewing a namespace could be a way to update the price structure, but it's not clear to me who should have the power to do so (especially in the face of a sybil threat).

One idea we were considering is to release a new version of Blockstore on a fixed schedule, and have it adjust prices accordingly according to the BTC exchange rate at the time. Since each new version of Blockstore can introduce new features, a user would need to choose between having the latest features or staying on the current pricing levels (the latter of which could be advantageous, since the prices could increase in the new version). However, if there are applications that a user needs that depend on the new features, then we expect that the need to run the application would eventually overcome the reluctance to upgrade.

We already employ a weaker version of the above strategy: we currently embed the Blockstore version number into a NAMESPACE_REVEAL operation on the blockchain, and have Blockstore ignore namespaces created by newer versions than itself (because newer versions could use incompatible name rules and different operation formats). This means that users who opt out of price updates will not see any new namespaces, which can also help encourage them to upgrade to the latest version (and prices).

[shea256]

@jcnelson this can be closed correct?

[jcnelson]

@shea256 Yup. closing...