User:Gmaxwell/namecoin that sucks less

From Bitcoin Wiki
Revision as of 00:55, 13 August 2013 by Gmaxwell (talk | contribs)
Jump to: navigation, search


First, start with a committed UTXO set— I originally proposed[1] commited UTXO for namecoin use. This can be used to make lite resolvers which get provable strong results.

Next, degrade the security model to SPV for the past history. Unlikely a currency, naming doesn't really require strong evidence that in the past the name authorities weren't cheating (inflating names? who gives a ?!#@). On syncup a node would grab headers, then pull the (say) last month of blocks and the UTXO from a month ago then apply forward and only check the recent updates.

Data older than a month ago would be deleted forever.

Next, any kind of to-address of internal capacity tokens must be P2SH with a two layer hash like hash160. When you pay to an address you must also provide with the transaction (but external to it) the interior hash value (this would be the real address). Thus its not possible to store arbritary data in payment addresses. (this is called P2SH^2)

Next Key=value data must always store H(H(name)) and never name. Registrations of names must disclose the inner hash to prove that the key is a hash and not something else. If you haven't guessed a name, or someone hasn't told you about it— it's none of your business that it exists.

Value data must always be stored as Enc(H(name||2), data). When a resolver returns a result, unless it has guessed a name it can't decode the update records. Only people who know the names have any business seeing a record. If necessary two levels of encryption could be used p2sh^2 style to prove that the data is encrypted at insert time.

The idea of the above measures is to strongly inhibit the use of the database as an anonymous broadcast communication channel and to allow resolver operators to be honest when they say they don't know and don't care about the specifics of their queries. It discourages some forms of censorship by at least requiring the censor to have become specifically aware of they want to censor.

Because of the UTXO tree data used in results a resolver couldn't lie and give an NXDOMAIN, but it could certainly return back that its refusing to answer a query for a particular name. If a resolver operator gets ordered to not serve a particular record, in spite of the above privacy, they can just return the hash of the record and a message saying its been censored.