Bitcoin usernames / domain names instead of DNS-based NIP-05

Problem - keys are cumbersome and hard to remember, but DNS names and usernames can't be self-custodied. Previous fix attempts seem distracted with trying to make money instead of actually solving the problem.

Solution - Bitcoin fixes this. We can encode aliases in Bitcoin transactions, and use the Bitcoin chain as a lookup table for them.

A name could be registered in 3 transactions to yourself, of any size/amount -

1. Generate a new wallet and send Bitcoin to yourself, with the alias encrypted using AES-256 in the OP_RETURN field. For example, my username - 𝐰𝐡𝐨𝐞𝐯𝐞𝐫

2. After the transaction has confirmed, send it back to the wallet it came from with the AES-256 decryption key in the OP_RETURN field. This process should prevent anyone from copying your alias in the time between sending and confirming your transactions.

3. After the second transaction has confirmed, yet again send the same UTXO back to the other wallet you sent it to in step 1, with the associated long address in the OP_RETURN field. For example, my nostr key with the nostr URI prefix - 𝐧𝐨𝐬𝐭𝐫:𝐧𝐩𝐮𝐛𝟏𝐰𝐚𝐦𝐯𝐱𝐭𝟐𝐭𝐫𝟓𝟎𝐠𝐡𝐮𝟒𝐟𝐝𝐰𝟒𝟕𝐤𝐬𝐚𝐝𝐧𝐭𝟎𝐩𝟐𝟕𝟕𝐧𝐯𝟎𝐯𝐟𝐡𝐩𝐥𝐦𝐯𝟎𝐧𝟎𝐳𝟑𝟐𝟒𝟑𝐳𝐲𝐪𝟐𝟔𝐮𝟑𝐥𝟐

Optionally, additional addresses could be linked to the same alias by continuing to send OP_RETURN transactions back and forth between the same 2 wallets after step 3. For example, you could have an alias with 2 nostr keys, or an alias with a nostr key and a webpage link.

This mechanism could also be used to attach a backup Bitcoin address that's allowed to re-register the name under its own control, in case you lose the wallet you're using. Alternatively, you could seal the package and signal no further addresses should be added, by sending a final transaction with no OP_RETURN data.

It would make sense to consider some aliases invalid. For example, we might want to consider an alias invalid if it contains dots, so that we can use dots for subaddresses similar to DNS subdomains. In that case, we might also want to consider well-known TLD aliases like com invalid, so someone can't just register com and then freely generate fake .com subaddresses.

Likewise, we might want to consider any alias containing @ invalid, so @ can be used structurally in ways like twitter tagging or email addresses.

If 2 wallets try to claim the same name in the same block, they should both be invalid. This should help encourage people to think of unique usernames, instead of trying scalp sought-after ones.

However, scalping would still be possible. An alias could be transferred by entering the recipient as a backup wallet address, enabling them to re-register the name under their control.

Some of these design choices have pros and cons that may be worth considering.

The destination:

Letting users send their money to themselves makes sense, but searching and verifying names will require scanning every transaction in every block. The community could instead agree on a set of addresses to send these transactions to, such as charities or Satoshi Nakamoto's first wallet.

This way, a search index would only have to download and store the transactions for those wallet addresses, instead of every transaction in the Bitcoin network.

OP_RETURN / formatting:

Some people hate OP_RETURN, and some would even speculate the feature might be removed completely and have all its data purged from the blockchain someday. If that's a concern, we can instead encode data as numbers and transmit the numbers as transaction amounts in a long chain of transactions. People might also have other suggestions or concerns on exactly how the data should be formatted.

Invalid names:

Some people might be against blocking characters like . or @ or blocking .com names. It might make sense for some of these restrictions to be context-specific instead of baked in.

For example, maybe email apps or twitter apps using this protocol could just not allow names with @ even if those names are able to be registered on the protocol. A browser extension that adds URL bar support could ignore .com names. In this case, any app that helps users register names should simply warn them if they're trying to register a name that might not work everywhere.