An interesting use case for the Namecoin .bit domains

[Sven]

An interesting use case for the Namecoin .bit domain:

One thing that none of the current crypto-currencies are able to solve is the problem of lost private keys, if one looses them there is no way to get the funds back, i believe this model not only harms the user but also the crypto economic system, why? because resources should not be unused and wasted. If you loose the keys to a house why are you never able to get back in?

With the current crypto model you loose the key and all funds are inaccessible by you or anyone. Living systems does not seem to work like that, everything is used again. So what's the idea? It comes directly from the expiration time in .bit domains, if besides domain names, what if wallet balances also expire and get renewed?

All .bit domains have an expiration date, so if one looses the private keys, the coins will recycle back into the system after their expiration time, and will be given to miners, all the energy and time needed to mine those lost Namecoins will be recovered and recycled back, not lost forever. Even if there is a talented and devoted team behind Namecoin, its primarily the decision of the miners to keep the Blockchain alive and secure.

All sustainable systems work by feeding back into themselves, just like a fractals do, generating assured continuity by a feedback loop.
I believe it is not necessarily scarcity which makes a coin valuable but stability, disappearing coins from the ecosystem causes value and emotional instability, its quite interesting that Namecoin can easily solve this problem which plagues all crypto-currencies, with a little tweak it can be re-branded as an innovative coin and can serve as a model for sustainability.

Any feedback welcomed

[biolizard89]

Hi! Thanks for the proposal!

if besides the domain names Namecoin names should have associated balance and the the owner of the name can spend the balance

Name outputs already have a balance, although it's typically zero unless you're constructing raw transactions yourself. This is utilized by my "pure name transactions" optimization (which was designed in March 2017 during an ICANN58 discussion, but isn't actually implemented by any wallet software yet).

this can be either implemented in the current chain or in a hard fork.

That wording doesn't make much sense; "current chain" and "hardfork" are orthogonal. (The Namecoin chain is still the same blockchain as it was before the AuxPoW hardfork.) Your proposal is definitely a hardfork, which doesn't imply anything about whether it would be applied to the current chain.

Anyway, I'll be blunt: this proposal's game-theoretic properties make me want to run in the opposite direction (literally; see next paragraph). Look at it from the point of view of a miner (whom we'll call Eric). Eric sees a name that's nearing expiration, and there's a renewal transaction in the memory pool. What should Eric do? Under the current system, Eric is incentivized to mine the renewal transaction in order to collect the transaction fee. (Of course, whether this is sufficient incentive depends on a lot of other factors, including whether the block is full, but that's beside the point.) Under your system, Eric is instead incentivized to not mine the renewal transaction, so that he can collect the coins attached to the name.

Right now my opinion (and that of several other experts I've talked to) is that the incentive to mine renewals is too low. In particular, the concern is that an attacker (whom we'll call Keith) can pay Eric to refuse to mine renewals for a name owned by a website operator (whom we'll call Julian). If Keith pays Eric more per block than the miner fee that Julian is paying, then Eric is incentivized to let Julian's name expire and promptly allow Keith to register it for himself. This attack scenario is a major motivation for (long term) raising the miner fees on name transactions and (short term) decreasing the block size and/or block weight limit. Hence my comment about running in the opposite direction.

[Sven]

Could there be a technical way of fixing the problem you addressed? What I'm trying to say is that Namecoin technology could be used in a different manner therefore adding to its utility value. There are projects being done right now similar to Namecoin e.g. Handshake https://handshake.org It would be positive to enable multi-purposenes so it competes with the other DNS coins so as to not loose market cap. Namecoin technology is special because it has the unseen potential for re-interpretation, so why not take full advantage and experiment before the coin slides into obscurity or obsolescence?

regards

[domob]

I'm fully in favour of finding more innovative uses for Namecoin - however, as Jeremy said, I do not think "recovering lost keys" is a good such usecase. In fact, I don't even agree that lost coins are a problem in the first place. There have been countless discussions on Bitcointalk about this as well, where most experienced people agree that trying to recover those coins is not a reasonable goal (especially not if it creates other problems like the misaligned miner incentives Jeremy pointed out).

[Sven]

Do you think it will be an interesting experiment if it could be implemented for a Namecoin hard fork? I mean, just to see where it leads, I see it clear, its similar to the early history of viagra or sildenafil which was the original name, it was a hypertension medication, but researchers noticed an interesting side effect, longer-lasting erections. https://en.wikipedia.org/wiki/Sildenafil#History

[domob]

Sure, if you think it would be interesting to try it out "in the wild" with a fork (i.e. new coin you create), feel free to give it a go. Perhaps you can even utilise the Xaya platform (https://xaya.io/) that veterans from the Huntercoin experiment (including me) are currently building - that will make it much easier to implement the "balance per name" thing, and you would just need to add back expiration rules. Alternatively, you could add tracking of per-name balances to Namecoin's state. I'm not sure which would be simpler (and it probably depends on your preferred development style/language).

[Sven]

Easier said than made, my programming skills are limited to arduinos! The Xaya.io project looks quite interesting, an immersive ecosystem creating utility for a coin, similar in a way to the brave browser. Looks like a successful enterprise! congratulations.

[yanmaani]

Right now my opinion (and that of several other experts I've talked to) is that the incentive to mine renewals is too low. In particular, the concern is that an attacker (whom we'll call Keith) can pay Eric to refuse to mine renewals for a name owned by a website operator (whom we'll call Julian). If Keith pays Eric more per block than the miner fee that Julian is paying, then Eric is incentivized to let Julian's name expire and promptly allow Keith to register it for himself. This attack scenario is a major motivation for (long term) raising the miner fees on name transactions and (short term) decreasing the block size and/or block weight limit. Hence my comment about running in the opposite direction.

The long-term solution is likely to be infeasible, since miners can always charge fees out of band.

Isn't a simpler solution to just renew more often? If you renew once per month, you have a lot of time.

Another way could be to penalize miners for letting names expire. If the max blocksize now is 4M WU, it could be changed to 4M WU - f(expired domains). Alternatively, a haircut to the block reward. It might be possible to game (register names, let them expire, and crash the block size/reward to zero), but it might still be a less bad set of incentives.

You could decrease the penalty is the domain is not instantly registered. So the payouts for the miner are:

+0: The name did not expire, Julian renewed it in time
-1: The name did expire, but Keith did not register it in the same block
-2: The name did expire, and Keith registered it in the same block

To ensure everything still sums to zero, the haircut could be smeared over the following N blocks, so as to incentivize their competition to try harder.