Delegated Name Price Discovery

Post Reply
biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Delegated Name Price Discovery

Post by biolizard89 »

Here are some thoughts on name price discovery. I mentioned some of these ideas on IRC, but figured it would be good to get it all written down here. Credit for the idea of using delegated votes goes to BitShares, although BitShares is still completely broken security wise, so please don't take this as an endorsement of BitShares or DPoS.

============================

Delegated Transaction-Based Name Price Discovery

For each transaction in each block:
Define luck = H( H(block) cat H(tx) ) / [age vector of inputs] dot [NMC value vector of inputs]

Define the transaction with the lowest luck in each block as a vote.

All transactions should include an output containing OP_RETURN vote pv/domob, where pv/domob is an arbitrary name. Transactions that do not contain such an output are rejected from blocks.

The delegates for block height N are defined to be the values of names (duplicates allowed, no post-processing such as imports) referenced by OP_PRICEVOTE in the votes of blocks [N-2047, N], at the block height immediately before the vote.

Each delegate must contain a JSON object, consisting of {"price": 10.0} where 10.0 is any floating point number. Any delegate for which delegate["price"] is not a floating-point number or integer is removed from the delegate set.

The enforced minimum NMC value of a name output in a block is enforced to be the median of all delegates for the current block height. Name outputs in blocks are not affected by the enforced NMC value in subsequent blocks, but will still expire after 36 kiloblocks if not renewed with a current NMC value.

Advantages:

Miners cannot easily influence the selection of a vote, since even picking between 2 votes would cut the effective hash power of the miner by a factor of 2.
The above is important, because mining hardware can be accumulated in secret using currencies like USD which have a huge market cap. Old NMC inputs of large value can only be accumulated transparently, and attempting to buy huge amounts of NMC is very difficult for an adversary who is rich in another currency, since doing so will simply inflate the value of NMC, making NMC holders richer and the attacker poorer.
The enforced name price adjusts smoothly and predictably; it is possible to precisely predict the minimum and maximum price of a name from up to 1024 blocks in advance. Rapid fluctuations in name price are resolved within 1024 blocks (if no attack) or 2048 blocks (if 49% of votes are attacking).
Old OP_RETURN outputs and delegate values can be pruned after 2048 blocks.
If a delegate attacks the network, voters will see, and can avoid voting for them BEFORE the attack would have taken effect. There are a large number of delegates, and it is unlikely that they will all collude.
If a voter really doesn't trust any delegates, they can vote for themself. This requires the extra effort of deciding what a reasonable price is, but is otherwise only equivalent to the cost of a name.

Failure points:

51% of miners reject blocks with votes or delegates they don't like.
51% of NMC holders vote for evil delegates.
Encryption of NMC amounts (e.g. Zerocash or Appecoin) would be problematic.
Allowing non-NMC currencies to purchase names (e.g. as a Bitcoin sidechain) would be problematic.
Division by the transaction weight is not the mathematically correct way to do it; it incentivises certain transaction amounts over others. Someone with a better math background than me can find the correct way to implement the weighting function.

============================

Delegated Miner-Based Name Price Discovery

Same as above, but miners directly vote for a delegate in their coinbase, rather than using transaction votes.

Advantages:

The enforced name price adjusts smoothly and predictably; it is possible to precisely predict the minimum and maximum price of a name from up to 1024 blocks in advance. Rapid fluctuations in name price are resolved within 1024 blocks (if no attack) or 2048 blocks (if 49% of votes are attacking).
Old delegate values can be pruned after 2048 blocks.
If a delegate attacks the network, miners will see, and can avoid voting for them BEFORE the attack would have taken effect. There are a large number of delegates, and it is unlikely that they will all collude.
If a miner really doesn't trust any delegates, they can vote for themself. This requires the extra effort of deciding what a reasonable price is, but is otherwise only equivalent to the cost of a name.
Large exchanges which hold NMC cannot exert undue influence.
Encryption of NMC amounts (e.g. Zerocash or Appecoin) is not a problem.
Operating as a Bitcoin sidechain is not a problem.
No need to have mathematically sensitive luck calculation.

Failure Points:

51% of miners can control the price, even if they don't reject any blocks.

============================

GetBlockTemplate for Namecoin

If a decentralized mining pool system like GetBlockTemplate were implemented for Namecoin, this would prevent a large pool from behaving badly, as long as the miner clients were mostly honest. This would most likely be a hardfork to the merged mining system.

============================

Min/max prices

To limit the impact of an attack on the name price, we could implement a min/max price constraint in blockchain validation. Indolering has also suggested the possibility of making the min/max constraints adjustable by supermajority miner vote.

============================

Dynamic pricing schemes by name length

It makes sense to have different pricing schemes for d/ and id/ (high) versus dd/ and idd/ (low), since d/ and id/ names are human-readable while dd/ and idd/ can effectively be randomly chosen names. However, allowing custom prices per namespace constitutes a method of censoring a namespace. I think it makes more sense to have the pricing scheme be dependent on name length. For example, a d/ name must be 66 characters or shorter, and an id/ name must be 67 characters or shorter. We could therefore allow different pricing schemes for names <75 chars versus names >=75 chars, which would allow cheaper dd/ and idd/ names as long as those names are sufficiently long.

============================

My suggestion:

Delegated miner-based price discovery, with a non-adjustable min/max price range of [0.01, 5] NMC for under 75 chars and [0.01, 0.75] NMC for at least 75 chars. This is relatively simple, is as decentralized as the miners, does not require GetBlockTemplate to be implemented, is unlikely to break the system short-term even if miners attack us, and doesn't break the system long-term if we later decide to add Zerocash or sidechain support. Getting something that works as long as 5 NMC isn't too much money to buy a domain name, will be an effective stopgap for the foreseeable future, unless for some reason NMC increases more than roughly 20-fold in exchange rate followed by a miner attack (seems unlikely).

Prior to accepting this proposal (or anything similar), we should talk to the various pools to see if they have any problem with embedding a delegate vote in their coinbase. And of course, we should also get this vetted by the various experts to see if this has any weaknesses I haven't thought of.

(This post was edited for formatting.)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply