Bitcoin Naming System / Alias Idea

[rebelofbabylon]

I'm sure I'm not the first one with the idea, but I'd like to potentially pursue this if there was sufficient interest and support from the community.

The idea would be for an alias system which could be used within bitcoin wallets. Instead of having to ask someone for a new BTC address or for their lightning node url, we could instead just ask for their alias. Something like @rebelofbabylon would resolve to my LN node or BTC address.

Taking inspiration from projects like Namecoin, it would ideally be decentralized. Instead of Merged Mining, Blind Merged Mining with the help of SIGHASH_ANYPREVOUT (more info here) would be used as to not create a competing coin. There could be some sort of standard for names (32 character length limit, numbers, letters, some special characters, perhaps rules to avoid "i" and "l" being used in an alias or something like that). I'd also like if it were easy to run this on top of your LN node (which is also a BTC node).

I found this abandoned project which suggests a way to enable privacy with this kind of system. Perhaps instead of storing the association between an alias and a BTC address, the association is with a pubKey and an incrementor state variable is also stored to ensure no address reuse.  

I'm still doing research and gathering ideas. I'm by no means an expert (I realize to seriously undertake such a project, I have a lot of learning to do) and would love any feedback  :-)  

EDIT: I want to add that this sort of system would be optional and in no way would I want to replace BTC address scheme (I couldn't even if I wanted to)

[1714507821]

1714507821

[1714507821]

1714507821

[1714507821]

1714507821

[NotATether]

The Bitcoin Core frontend already has a feature to assign labels to addresses and while they are not universal, it allows people to reuse names that otherwise would be taken and this reusability is perhaps important because most people's transactions are not to other people, they ar to services, so being able to use the service name as a label is handy.

As far as a global labeling system is concerned, that's not possible without making transaction sizes bigger (all labels will have to be stored on the blockchain).

[rebelofbabylon]

The Bitcoin Core frontend already has a feature to assign labels to addresses and while they are not universal, it allows people to reuse names that otherwise would be taken and this reusability is perhaps important because most people's transactions are not to other people, they ar to services, so being able to use the service name as a label is handy.

Interesting I didn't know about this. Ideally though, a global system would be better, that way anyone can use whatever wallet software they want.

As far as a global labeling system is concerned, that's not possible without making transaction sizes bigger (all labels will have to be stored on the blockchain).

I definitely would not want to hardfork. I propose we use a spacechain and SIGHASH_ANYPREVOUT. Basically, 1 tx on the BTC blockchain becomes the anchor for the spacechain. Block producers for the spacechain would compete for their tx to be included on the BTC blockchain by outbidding eachother (with fees). A better explanation for this is found here.

[icopress]

The Bitcoin Core frontend already has a feature to assign labels to addresses and while they are not universal, it allows people to reuse names that otherwise would be taken and this reusability is perhaps important because most people's transactions are not to other people, they ar to services, so being able to use the service name as a label is handy.

For some reason, it seems to me that songchunlai meant a username system similar to the one used on Twitter or any other social network, in which it will not be possible to select one and the same username for two bitcoin addresses, (except for the case when there are several bitcoin addresses for one @u'name). If so, then I see catastrophic consequences for confidentiality, although this issue fades into the background due to the impossibility of implementation, (at least globally).

[rebelofbabylon]

(...)I see catastrophic consequences for confidentiality,

Can you elaborate? I found an interesting project that addresses some of the issues with confidentiality here. Any thoughts? The way I see it, no matter what, assigning an address or a set of addresses to an alias has privacy issues. But we aren't limited to only using these addresses, we can also use coinjoin or payjoin between these tainted addresses and our more confidential addresses much like you would to break deterministic links from an exchange. There are use cases where confidentiality isn't as much of a concern (like sending to the alias of a business, sending money between trusted friends) and this would be an optional feature. 

although this issue fades into the background due to the impossibility of implementation, (at least globally).

Impossible to implement? Can you elaborate on this position?

[franky1]

channels dont last forever.
unlike webaddresses that are registered for like a decade

so the downside of having a alias blockchain is everyone needs to store the blockchain even after names are out of date after a couple months.
so you might want to invent some prune method

having a dns server is more centralised and thus more risk of messing with the names

..
other ideas are not to have a public registry of
name=channel&IP

and instead just have 2 participants that make up 2 names
eg rebelofbabylon1433   and frank17331

so you broadcast frank17331:yourIP
everyone sees this but no one knows the required response.
so i knowing its meant for me. then IP connect to you with my response rebelofbabylon1433
so you get that and know its me.
after all everyone else wont know they are looking for rebelofbabylon1433 so you decline all connects trying to connect but not using your specific name

which is much the same as relaying namespaces in a alias blockchain. but without storing the names in a blockchain

so best of both words decentralised. but not archived

[rebelofbabylon]

channels dont last forever.
unlike webaddresses that are registered for like a decade

I'm not sure what you meant here. To connect to a node, you need their node uri. I was under the impression it doesn't change. For example, yalls.org in the "Join the Yall's Community" . the node uri never changes.

so the downside of having a alias blockchain is everyone needs to store the blockchain even after names are out of date after a couple months.
so you might want to invent some prune method

having a dns server is more centralised and thus more risk of messing with the names

..
other ideas are not to have a public registry of
name=channel&IP

and instead just have 2 participants that make up 2 names
eg rebelofbabylon1433   and frank17331

so you broadcast frank17331:yourIP
everyone sees this but no one knows the required response.
so i knowing its meant for me. then IP connect to you with my response rebelofbabylon1433
so you get that and know its me.
after all everyone else wont know they are looking for rebelofbabylon1433 so you decline all connects trying to connect but not using your specific name

which is much the same as relaying namespaces in a alias blockchain. but without storing the names in a blockchain

so best of both words decentralised. but not archived

So you're proposing almost like an address book type of feature. Instead of a global namespace, local namespace in LN wallets that you can assign to node uri's. That would be a useful feature.

Do you think that a global namespace for node uri's or BTC wallet addresses like domain names for webpages is a worth while idea? Genuienly asking.

[BitcoinBarrel]

While it's an idea, it sort of defeats the whole purpose of Bitcoin to begin with.

Bitcoin is useful because you can use and reuse as many addresses as you like. If everyone has assigned a single alias or handle, then they will soon be the target of hackers and scammers amongst other privacy issues.

[rebelofbabylon]

I wouldn't want to replace the current UX, just add to it. Maybe I ought to have specified, would an alias type feature for specific use cases like sending to a business be good? You could also avoid address reuse with such a scheme if you associated a pubkey to a name and then just used a random number or a known number to generate a new BTC address that you send too. This process would be abstracted away from the user and would be entirely optional.

[franky1]

my idea is a two stage process
instead of having to store validate and read some blockchain directory(another network)
instead of connecting to a central DNS directory

..
its have no directory.
instead you and someone else. agree on a shortname unique for that channel attempt
one person broadcasts out that name to the network. and they relay it around. and obviously the intended recipient gets it and responds to that shortnames IP with the other shortname. this travels back and they connect together and handshake. because they both recognised their responses.

if other hackers tried this they wont have the valid response to call back with. thus no handshake

why is this better then a blockchain directory
because a blockchain directory involved relaying shortnames and ips and channel uri PERMENENTLY where all nodes store it
my idea is not a store and not permanent but temporary relay. where the channel URI(coin address info) is not sent until the username handshake is complete

thus more private

it does not rely on any third party database(dns) nor third network
many already complain that having to be a bitcoin node and an 24/7 online LN node is too much. so also having then include a namecoin node is having 3 networks running. which is even worse

however just having a name peer-relay-message system resolves many flaws of having directories in blockchain or central dns format

[qwk]

I recall something called "firstbits" from ages ago, where people would basically just lay a sort of "claim" on the first few "letters" of their respective addresses.
It was quite popular at the time, but somehow it's not being used anymore.

[DannyHamilton]

I recall something called "firstbits" from ages ago, where people would basically just lay a sort of "claim" on the first few "letters" of their respective addresses.
It was quite popular at the time, but somehow it's not being used anymore.

There was no check-sum or error correction built-in.  A typo would EASILY result in the wrong person receiving the bitcoins. It also encouraged address re-use which is generally a bad idea.

An address isn't an account number or a wallet identifier.  It's an invoice number.  Creating systems that encourage users to re-use addresses is as dumb of an idea as creating systems that encourage businesses to re-use invoice numbers. In the long run, only bad things will come of it.

[franky1]

danny is right. which is why central DNS registry for invoices are dumb
                                         blockchain addressbooks for invoices are dumb


before even making an invoice that has a lengthy URI. and avoiding having that lengthy uri logged in some database for eternity. (centrally or distributed to all nodes)

a simply ping message. or a push message of simply a username can be used.
after all if he wants a third network that relays these invoice uri's to everyone and they then store it in a namecoin blockchain.. just remove the blockchain part. and just use the relay part.. simples

nodes dont need to keep everyones Uri. the relay just needs to pass a unique username to nodes and be recognised by the node that needs to see it. and then they send back their response to gain the handshake.
and once connected. then they can invoice and pay each other.
thus no invoice relayed openly and no database collection of invoices everywhere.

but here is the more simple idea.. diverting further away from rebels idea
bitcoin addresses are long. they found a solution
invoices are long.. but can be solved by same solution
. what is that solution.
.. QR codes.. or copy/paste

[rebelofbabylon]

Just want to clarify a couple of things. This blockchain/spacechain for name space wouldn't store the association between a name and a singular BTC address. It would store a name, a pubkey, an LN node uri and potentially some sort of state variable that is updated every time a call to a name server for that association is made. This last one might pose too much overhead on a network.

So let's imagine a decentralized naming system where a name, a node uri and associated pubkey are stored. To send to, for example, @rebelofbabylon, you would need to get association from a node running this software, then connect to LN node via the given node uri. If sending on-chain, you multiply the pubkey with a random value which can then become a btc address. Because presumably you as the alias holder would store a pubkey for which you own the corresponding private key, if I told you this random number, (via our connected LN nodes), you would then also have the corresponding priv key for the address. This way, no address reuse. Atleast that is what I understood from this .

The advantage of doing so is it simplifies the UX. Currently to send someone BTC onchain, you have to ask them every time for a new address, whereas here, this protocol abstracts that away. Your alias compatible wallet would abstract the exchange of secret random value away, you simply would just type in the alias and send. The receiver would also need to run a wallet that is alias compatible to receive the random value and be able to derivate the private key for the wallet the BTC was sent to.

For off-chain via LN, I guess this protocol wouldn't be necessary. You can currently set an alias for your node uri. And once connected, it's possible to design a wallet right now that would ask the receiver for an invoice without the receiver being aware (so long as their node is online). So the UX isn't very complicated. And then there's also different ways to send without the invoice protocol used in LN right now.

Also, as Franky mentioned, QR codes do abstract away a lot of the issues with long, complex BTC addresses or invoices. But QR codes are good when dealing with an online service or in person interaction. Sending a friend BTC when not together in person isn't as frictionless. This is where I see an alias protocol working best.

Also I appreciate all the feedback here. Like I said in the original post, I wouldn't pursue this idea if people didn't like it. I just want to frame the idea as clearly as possible, something I think I've failed to do at this point.  

[LoyceV]

I recall something called "firstbits" from ages ago, where people would basically just lay a sort of "claim" on the first few "letters" of their respective addresses.
It was quite popular at the time, but somehow it's not being used anymore.

It shouldn't be used, a centralized system to give out addresses is an unneccessary risk:

I just tried FirstBits.com to look for an address "1bbbb", it gets resolved to 1bbbb2oiLBohHtd9uo6o3JeEbMG3ZtFUs, the first use of the address is today (24 May 2012). However, when I use blockchain.info, "1bbbb" becomes 1BBbBqtJcwqSQDTJ2hqVnoMozGxh97vnH3, and the first use of the address is 05 Feb 2011.

I'm still doing research and gathering ideas.

I remember a system where Byteball (now Obyte) allowed to buy a name for an address. It's registered in the DAG^*, so no external party needed. I can imagine a charity using this for donations, in which case address reuse isn't so bad.

Sending a friend BTC when not together in person isn't as frictionless. This is where I see an alias protocol working best.

Assuming you're not trying to give a Bitcoin address over the phone, I don't see a problem with the address length.
Even worse: I can imagine phishing attacks happening to aliases, just like what happens to domain names.

^* I'm actually not sure, it could have been an Oracle. Unfortunately I can't find back the post about it, the thread is too long.

[franky1]

Just want to clarify a couple of things. This blockchain/spacechain for name space wouldn't store the association between a name and a singular BTC address. It would store a name, a pubkey, an LN node uri and potentially some sort of state variable that is updated every time a call to a name server for that association is made. This last one might pose too much overhead on a network.

So let's imagine a decentralized naming system where a name, a node uri and associated pubkey are stored. To send to, for example, @rebelofbabylon, you would need to get association from a node running this software, then connect to LN node via the given node uri.

just to clarify

to even connect to a naming system blockchain. you have to initially make a connection to some network, *just to sync the blocks*. and then relay out your special alias and some connection id. *to then get added to a block to then be propagated to the network*

so just do away with the block syncing propogating and storing part. and just use a network connection relay part for your temporary namespace WHEN YOU WANT TO FIND YOUR CHANNEL PARTNER

let it relay around the network. and then the specific recipient can see its a message to him. and he just responds to it


.. anyway thats the best solution for your namespace directory idea.. however a QR code on some app/website payment page is much easier then trying to decide on alias's to temporarily use.. and then propagate around the network
just getting a QR code from a websites payment checkout. is much easier

[PrimeNumber7]

(...)I see catastrophic consequences for confidentiality,

Can you elaborate?

Reusing addresses is bad for privacy. If you reuse an address, it is known to the public that the same person was part of multiple transactions. If you use a new address each time you receive a payment and use a new change address each time you receive change as part of a transaction, it will become less likely that someone can determine each of your addresses is associated with the same person/entity.

Further, when you use coinjoin, it is obvious you are using coinjoin, and someone researching if two addresses are associated with each other can back out CJ transactions accordingly. CJ transactions don't necessarily make it impossible to determine which output is associated with each input, it just makes it more difficult. This is even true if your CJ inputs/outputs are standardized if your CJ "partners" do something bad for privacy.