A collaborative multisig based replacement for ICANN would be awesome.
Discussion
Yes, another Aidan short proposal, big fan so far.
Time to NIP domain bureaucracy in the bud, heh . Yeah, yeah, I see myself out. Only to think over those proposals though. nostr:npub1reezn2ctrrg736uqj7mva9lsuwv0kr5asj4vvkwxnrwlhvxf98tsq99ty4 mentioned giving bits a try in BDK Wallet. I found some new, elegant options with transitions, no new unit though.
LOL.
The devil is in the details on the ICANN replacement. E.g. how to mine names, stop hoarders and squatters and probably tons of other stuff.
Handshake already tried a lot of this and failed, but Nostr provides some nice bedrock for another attempt, maybe.
Do Nostr key generation and BTC mining use the same algorithms, can BTC ASICs accelerate both?
How long should mining of a key with a few preset characters take on a conventional computer?
Can we set additional difficulty parameters to prevent bulk name occupations?
Does anyone actively work on the subject?
Both use secp256k1 curve
How does difficulty adjustment work there, decimal place precision?
Mining as it relates to asics is about generating SHA256 hashes, so I don’t think they would be repurposable for generating vanity keys.
So, where lies the difficulty in supposed key mining?
Does it take any significant processing effort to generate name keys?
It’s kinda orthogonal I think - you would want human readable names which couldn’t come from elliptic curve keys. So the question is how do you come up with these names and do so in a way that aligns incentives during growth of the network? Bitcoin didn’t have to deal with this type of challenge.
Can elliptic curve provide no way to calculate keys with a human readable segment? I imagined that as the mining process, admittedly quite loosely, expecting you or others here to already have explored the topic in depth.
I feel very convinced of the key pair, specifically BECH32 format. Also intent on avoiding a separate resolving step, the pubkey should provide both the full address and the human readable element. I could imagine an autocomplete step for the non human readable part based on some network traffic analytics, eg. completing to the most visited key containing the entered human readable part.
Again, I only loosely thought about this so far.