Hey John, thanks for your reply. The TL;DR of my response is that there are details on how these features will be implemented that will require the use of a layer-2 token. Let me see if I can answer some of your questions.
You can do this already with bitcoin using cross-chain atomic swaps.
https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts#HTLCs_in_cross-chain_atomic_swaps1
We would like it to be possible for someone to set the price of a name they own and then allow anyone to buy it at that price within a given window of time. We would like to be able to do this efficiently on-chain, so no 3rd party registrar service (like GoDaddy) will be required. However, this cannot be done with HTLCs alone to the best of my knowledge, since HTLCs require the seller to learn the address of the recipient before sending the transaction (which would require a 3rd party discovery service).
You could also use a protocol like BitMarkets to do this - completely trustless and p2p.
You have to know the recipient’s address and network location in order to construct the transactions necessary for their 2-party escrow to work. This also necessitates an off-chain 3rd party service for discovering willing buyers, which we’re trying to avoid.
I suggested in the Part 1 thread that voting could also be done using blockchain IDs by inserting a vote into the zone file for a given ID and then weighting the vote according to the registration price of the ID.
Name ownership is not an accurate measurement of economic stake in the ecosystem, nor is it a measure of the system’s overall success. For example, Namecoin has over 3 million domains registered, but hardly anyone uses it. Notably, the protocol for signaling Namecoin upgrades is proof-of-work, not proof-of-name-registration. Good thing for them, since most of their domains are squatted for nearly free.
The most reliable way to signal economic activity that I know of is to do so via irreversible and sustained resource expenditure (e.g. burning electricity). Acquiring and burning a layer-2 token through virtual mining to send a signal is equivalent to doing so by mining and burning layer-1 tokens—energy (or its monetary equivalent) is irreversibly and consistently spent to send a signal.
There are two other problems with using names to signal upgrades. First, it’s inefficient, and second, the number of names you own and the worth of those names does not reflect how strongly you feel about a particular upgrade. Regarding point (1), if you own more than one name, you have to send a transaction to update each name in the signaling interval. If you feel strongly about the upgrade, you’d be incentivized, perversely, to squat a bunch of names just to send your signal. If instead signaling were done by burning a token (be it layer-1 or layer-2), you’d only have to send one transaction per signaling interval (and no names would be locked up). Moreover, the signaling system would require a proof-of-burn for every signaling period, since this would make it equivalent to spending electricity to signal in proof-of-work by block-mining.
Regarding point (2), let’s walk through an example. Suppose a protocol upgrade is proposed that causes all compliant resolvers and registrars to disable support for names with underscores in them. This might be pushed by a coalition of users who want all names to be DNS-compliant, for example. But if I’m an app developer and my app’s name has an underscore in it, it would be very important for me to block this protocol upgrade. I would be willing to spend much more money than the cost of my name to signal “no.” As we can see, the value of my “no” signal is much higher than the cost of my name, and the choice to purchase my name at its given cost (which was purchased before the upgrade proposal) was not related to the signal I chose to send.
Anyway, the point I’m trying to make is that acquiring and burning a token for signaling (be it layer-1 or layer-2) is a more efficient and more accurate way to signal protocol upgrade preferences than updating name zone files. The reason you’d want to use a layer-2 token specifically is that doing so limits signaling to the system’s stakeholders, and thus makes the signal more reflective of their wishes. We see this in other contexts as well–for example, when you’re playing the board game Monopoly and trying to auction off a deed, you would only settle deed ownership with Monopoly money from other players instead of USD from a complete stranger. If you want to have a say in the auction, you must first acquire Monopoly money by participating in the game. It would not be fair to the game players if random strangers could interfere with the game without any stake in it.
(re: namespace auctions) Are you sure this couldn’t be done with bitcoin? If not, why not?
We’d like to be able to implement a Dutch auction system for namespaces. In a Dutch auction, the price of the item being sold is set at a high price, and decreases at a fixed rate with time until someone buys it. For example, a namespace might cost 1 BTC at block X, 0.99 BTC at block X+1, 0.98 at X+1, etc. We’d prefer to implement a Dutch auction over e.g. a Vickrey auction (what ENS does for names), since it only needs two transactions: one to start the auction, and one to place the bid.
To the best of my knowledge a Dutch auction cannot be implemented with Bitcoin script, since the price of the namespace would be a function of the block height after the auction started. In order to implement the Dutch auction, the amount debited from the bidder would need to be determined by the block height at which the bid transaction was included in the blockchain. This information is only known after the transaction is sent; it cannot be included by the bidder. To the best of my knowledge, there is no way to express the necessary command “pay X BTC to address A, minus Y BTC for each block after the height H at which this transaction was included.”
I don’t see why people couldn’t just buy tokens for the new blockchain if they plan on moving over to it anyways.
We’d like it to be possible for people to “load up” their names with tokens, so they auto-renew every expiry period. Their balance would be automatically debited at the expiry block without the need to send a name-renewal transaction. The biggest reason to have this feature is that it lets us spread out the transactions required to renew names—you can pay as you go, and you can pay in advance. In the event of a migration, we’d like the balance a user has accumulated on their name to come with them.
This can’t be done with Bitcoin alone. While it is possible to restructure the NAME_RENEWAL transaction semantics so that users can preemptively renew a name for the next K expiry periods, keeping track of whether or not the users have paid enough and keeping track of how many expiry periods remain for a name is functionally equivalent to creating a separate unit of account for measuring the name’s remaining lifetime (i.e. an implicit layer-2 token).
You’ll have to explain this part in more detail, because with the given information I do not see the relation between tokens and SNV.
Sure thing. SNV (Simple Name Verification) lets you prove that a past transaction happened, given a later consensus hash. A layer-2 token would let you distinguish between two consensus hashes to identify which one’s virtualchain has a greater overall resource expenditure (e.g. by looking at how many layer-1 and layer-2 tokens are destroyed for name registration, mining, and protocol upgrade signaling). While the layer-2 token does not resolve conflicts between virtualchains (recall that virtualchains are fork*-consistent), it does give a bootstrapping user a hint as to which virtualchain has more economic activity. Name registration fees alone cannot do this.
Anyway, I hope this is helpful.
