Human Memorable Coin address system: Proposal

[crazy_rabbit]

One of the things I had been thinking about was how although QR codes make dealing with coin addresses easier, they still aren't human memorable the way email addresses are.

I was thinking of a system of how one might be able to turn their coin address into a human readable (and thus memorable) string , and thus make your coin address as easy to tell someone as it is your email. Sort of like an open distributed "phone book" of sorts.

The basis of the idea is the way brainwallet generates a bitcoin address and private key from a long passphrase.  (http://brainwallet.org/)

The idea is to combine a user_generated_string with a known long standard string (perhaps this long standard string could be called the "domain") and make a hash/generate bitcoin public and private key from these two strings a-la brainwallet.

To then associate your personal bitcoin address to this user generated string you send some small amount of coin onto this bitcoin public key that was generated above. As it is impossible for anyone to know of the existence of the generated address prior to your creation of it, the first time it would appear in the blockchain would be marked as receiving a payment from your real bitcoin address.

The first person to send money to the generated coin address would be considered the 'owner'.

To check and address you simply take the user_generated_string, plus the known long string, do the hash, find the address, check the block chain, and the first address to send money to it is the owner.

The known long string could also be considered the domain- at first I imagine just one long string "bitcoin_coin_address" for example and thus everyone when checking a users string could use this. However there is no reason why others couldn't come up with their own domains "McDonalds" or non-publicly announced domains ("Somali Pirate")

The amount sent to the generated addresses should be small, as the private key can be generated by anyone checking the address. It might be a nice idea if the payment sent was large enough to only cover transaction fee's. Perhaps we can set an arbitrarily large amount  required to be sent in miner fees to prevent 'squatting'. The transaction fee would be yet another way miners could continue to profit into the far future. For user_generated_strings that prove to be popular, and are perhaps registered simultaneously, there is a natural 'silent auction' characteristic- the person who pays the largest transaction fee to the miners would theoretically be confirmed faster.


The idea is rough, and I would like to hear any thoughts about it. The implementation could be built into the client directly or 3rd parties could offer it.

 I think a major stumbling block for wider acceptance is the very human non-friendly nature of coin addresses. QR codes are helpful, but there are many situations where QR codes won't work. For example, if the sender doesn't have a QR reading device with them, and the receiver doesn't have their QR with them. This provides an economic opportunity for miners, a universally confirmable system like first bits, and perhaps mitigates squatting to some extent.

[1715285808]

1715285808

[1715285808]

1715285808

[jim618]

Interesting idea to have the first transaction sent to an address to define the owner.

It gets round the whole 'strength of key generation' problem as the address that did the first send can be completely random.

You do not need a long domain text. It's main purpose is to create namespace. You could just use:

SHA256("bitcoin.myName") to generate the private key.

I think the most confusing thing would be that it it would be trivial to namesquat/ impersonate.
There is nothing to stop anyone claiming, say, "bitcoin.potus" for instance.

You also want to come up with a catchy name for this algorithm.
Names mean everything !

(For definiteness, I think you want to specify that the owner is the bitcoin address of the private key that is used to sign the transaction output consumed by the first transaction input for the first confirmed transaction at the generated address.)

[markm]

How do you re-assign a name to a new address, such as when you lose control of the address you sent that first transaction from?

Namecoin seems to be designed to solve this kind of problem, and can be merged-mined right alongside bitcoin so wherever bitcoin is, namecoin can easily also be. Maybe even designate a new namespace in namecoin, specifically for associating a bitcoin address with a label?

-MarkM-

[crazy_rabbit]

How do you re-assign a name to a new address, such as when you lose control of the address you sent that first transaction from?

For the moment I think you can't- sort of like how your bitcoin's are lost if you lost the private key. At first glance it would seem you would be in a similar situation here.

As ownership is communicated by a transaction sent to this generated address, and thus interpreted by others, it leaves open the possibility for others to interpret the ownership differently over time.

For example, we could collectively decide that all addresses require a yearly maintenance fee, and thus each year in order to recognize that initial claim of ownership we would need to see a yearly 'deposit' in miners fees to this generated address from that original ownership address to keep it in good standing.

Similarly we could also over time raise or lower the maintenance fee.

I imagine changing ownership could be done, it would somehow require the original address to send some new transaction to the generated address that would communicate change of ownership. Perhaps a transaction with multiple outputs (I don't quite understand how this works, so I'm just mentioning it in passing) or the use of a 2nd generated address.

A second generated address could signify a 'change of ownership address'. The original address that owns the 'human readable string' could generate a new address through this process (perhaps appending "change_of_ownership" to the public known string. The new address that the Human_readable_string would be transfered to, would send the first transaction to this new generated address, and then the original address could send a transaction immediately following, signifying a chance of ownership.

If the private key of the original owner is lost, then we could take away his/her ownership of the string after a year goes by without any maintenance fee paid.

Namecoin seems to be designed to solve this kind of problem, and can be merged-mined right alongside bitcoin so wherever bitcoin is, namecoin can easily also be. Maybe even designate a new namespace in namecoin, specifically for associating a bitcoin address with a label?
-MarkM-

I'm not very familiar with how the name coin system works, but I was motivated to try and out-think the problem of 'domain squatting'. No reason multiple systems couldn't exist, although perhaps impractical and confusing.

[crazy_rabbit]

Interesting idea to have the first transaction sent to an address to define the owner.

It gets round the whole 'strength of key generation' problem as the address that did the first send can be completely random.

You do not need a long domain text. It's main purpose is to create namespace. You could just use:

SHA256("bitcoin.myName") to generate the private key.

I think the most confusing thing would be that it it would be trivial to namesquat/ impersonate.
There is nothing to stop anyone claiming, say, "bitcoin.potus" for instance.

True, but that was the same problem with web addresses at first as well. Eventually if the bitcoin developers add this into the client, there could be devised an official method of revoking ownership. Of course, if Mcdonalds wanted in, and someone name squatted there trademark, McDonalds could pay some fee to the bitcoin project to initiate a review, and through some (I assume democratic process of the community or otherwise) ownership could be transfered and the profit could be distributed in any fairly decided way (to the miners, the developers, etc...)

While I know that it seems at first to be a centralized control- its important to know that it doesn't affect the protocol in anyway. It's just organizing a way of 'interpreting' activity on the blockchain.

But this is just an idea.

You also want to come up with a catchy name for this algorithm.
Names mean everything !

Good point. Email has '@' and twitter has '#'. What could this algorithm have? Any ideas?

(For definiteness, I think you want to specify that the owner is the bitcoin address of the private key that is used to sign the transaction output consumed by the first transaction input for the first confirmed transaction at the generated address.)

Wow that is specific. Thanks!

[markm]

So basically it is turning out not to be simple at all, but more and more complicated.

So might as well just leave name stuff to namecoin and let bitcoin stick to the money stuff.

-MarkM-

[CIYAM]

Another possible approach that would allow for transfer of ownership would be to have one of several "special" firstbit vanity addresses (with each being able to be considered as a "domain registrar") used to send a tx that can be used to identify the current owner.

With this approach it would be the last tx that identifies the current owner and an owner could sell their "domain" (in a way that can be publicly verifiable) by having the coins first sent to the registrar by the "buyer" which will be confirmed by another small tx from the current "owner" (to "release" ownership).

If the owner doesn't release within a certain period (say 48 hours) then the coins for the purchase would be refunded to the "buyer" - if the owner does send a confirming tx then the coins for purchase are sent to the owner (minus a fee) and another tx from the "registrar" is issued to the address.

Agreed that maybe namecoin could be useful in providing a solution for this but whatever the solution it would be best to utilise a block chain in order to have things publicly verifiable.

[crazy_rabbit]

So basically it is turning out not to be simple at all, but more and more complicated.

So might as well just leave name stuff to namecoin and let bitcoin stick to the money stuff.

-MarkM-

I am tempted to think that Namecoin presents the more complicated solution. As I've described it so far, it's extremely simple- a script to support it could be drawn up probably in a matter of minutes for a more talented programmer (I am a novice programer) and as it sits on top of bitcoin, already fairly secure (once again I can't claim this to be 100% true).

I like very much the idea behind namecoin, but domain squatting has not been solved and the developer community lacks the vibrancy of the bitcoin community. Also I'd prefer to have a system relying upon just one set of developers (Bitcoin) rather then two (Namecoin in conjunction with bitcoin).

Ideas of course are cheap, and it's all in the actual 'making it happen' that counts. Assuming that I will try to make this idea work, and I won't use namecoin but rather build a protocol on top of bitcoin, would there be anything obvious I should be keeping in mind?

[markm]

Squatting can only be battled by letting whoever pays the most get the name (always; you must sell it if anyone offers more) or some similar (or maybe even not so similar) algorithm executable by machines, or by human crap not executable directly by computers and likely not algorithmic thus subject to political machinations, bribery, violence, whatever. I think? Any other potential approaches?

-MarkM-

[labestiol]

I also don't see other ways to fight name squatting. And I'm not even sure auctions would be a desirable solution.
As for easy to remember btc address, I also think namecoin is the way to go. Sure we're a long way from that system being implemented, but it'll come at some point.

[crazy_rabbit]

Squatting can only be battled by letting whoever pays the most get the name (always; you must sell it if anyone offers more) or some similar (or maybe even not so similar) algorithm executable by machines, or by human crap not executable directly by computers and likely not algorithmic thus subject to political machinations, bribery, violence, whatever. I think? Any other potential approaches?

-MarkM-

Perhaps you don't have to sell it if someone offers more immediately. Perhaps once a year when renewal comes up a bidding process can be used to decide the new owner. However this isn't so fair to people who might be building a service but then get outbid by someone who recognizes the potential and snaps it up.

I think the squatting is a problem in a system with no centralized authority and low cost for registration, and I don't see a way around it.

I'm not really proposing that this system stand for the decentralized pure equality that bitcoin itself stands for. Rather it would be more of an 'end user' interface for people who otherwise can't get their heads around bitcoin addresses. (Some People would still use the internet if we just used IP addresses, but not regular people- even if it worked it would just be outside most people's perception).

In this system the organization that controls the 'interpretation' of the protocol would have final say- sort of like ICANN. Not that ICANN has any love here, but it functions well for normal people and allows big companies like NIKE to come in and say "give me that domain". I'm not against that here. It doesn't prevent anyone from using QR codes or regular bitcoin addresses, but it does allow for a billboard over the highway for donating to a charity to have a QR code and a line that says: "Send your donation to 'save-a-child'" and people can remember that for when they get home, rather then try and take a picture of the QR code while driving on the highway.

Also it suggests the possibility of finding a profit avenue for miners and the bitcoin organization itself. In the future when it's (hopefully) enormously popular, relying upon donations to keep developing the new-world-financial-system might not really cut it. If regular people would pay a small premium to have the convenience of a simple type of address, that premium could be used to fund quite a lot of development.

It's a small trade off, but its for the 'end users' and doesn't effect us 'pros' in the slightest.

[markm]

For "end users", ultimately maybe the solution to all problems of this type will be copy-and-paste routines that copy and paste not only the displayed visible thing the user sees and performs the copy on, but also the actual data that visual cue represents.

Sort of like how web pages have a whole URL, possibly with extra fields such as whether to open a new window, in their links and modern software often copies the URL along with or even instead of the human visible tag the user clicks on when the user copies the link.

Really the cases where label collision actually matters might get less and less, since labels can become more and more a user-side thing; what I mean on my computer by "coke" might not be same thing an organised crime lord in bolivia or an executive in a cola company likes to use that word as a convenient human-readable label for.

Even things like telling someone over the phone where to send you money we see nowadays phones are no longer limited to just a low bandwidth human-audible-sound channel but in fact have things like drag and drop, so maybe you'd just drag your receiving purse onto the icon you click to phone the person and presto, their phone, next time it connects, will know your recieving purse...

-MarkM-

[Pieter Wuille]

The idea is to combine a user_generated_string with a known long standard string (perhaps this long standard string could be called the "domain") and make a hash/generate bitcoin public and private key from these two strings a-la brainwallet.

...

The first person to send money to the generated coin address would be considered the 'owner'.

I don't think this is a good idea:

• It is incompatible with clients where the private key associated with the sender address does not belong to the sender (mostly e-wallets now). Bitcoin transactions do not have a real from address anyway, just potentially an address its coins were previously sent to, and using this as a 'refund' address breaks some uses of the protocol.
• It is incompatible with blockchain pruning, in which case there is no guarantee that information about the first send to a given address is easily accessible. You could of course set up a service that maintains this information, but at that point you don't have any advantage over just a third party that maintains bitcoin address books.
• It re-enforces the notion that we should associate addresses with people, while over time, we will have to move to separate addresses for every transaction to maintain privacy in the system. I know that I'm an offender myself here by showing a vanity address below, but that's only as long as no better well-supported payment methods exist.

[crazy_rabbit]

The idea is to combine a user_generated_string with a known long standard string (perhaps this long standard string could be called the "domain") and make a hash/generate bitcoin public and private key from these two strings a-la brainwallet.

...

The first person to send money to the generated coin address would be considered the 'owner'.

I don't think this is a good idea:

• It is incompatible with clients where the private key associated with the sender address does not belong to the sender (mostly e-wallets now). Bitcoin transactions do not have a real from address anyway, just potentially an address its coins were previously sent to, and using this as a 'refund' address breaks some uses of the protocol.
• It is incompatible with blockchain pruning, in which case there is no guarantee that information about the first send to a given address is easily accessible. You could of course set up a service that maintains this information, but at that point you don't have any advantage over just a third party that maintains bitcoin address books.
• It re-enforces the notion that we should associate addresses with people, while over time, we will have to move to separate addresses for every transaction to maintain privacy in the system. I know that I'm an offender myself here by showing a vanity address below, but that's only as long as no better well-supported payment methods exist.

"It is incompatible with clients where the private key associated with the sender address does not belong to the sender (mostly e-wallets now). Bitcoin transactions do not have a real from address anyway, just potentially an address its coins were previously sent to, and using this as a 'refund' address breaks some uses of the protocol."

This is interesting, and raises a good point- as the same user base that would be likely to use a system like this would also most likely use an e-wallet.

I hadn't really considered using this as a 'refund' address a-la SatoshiDice however, (a good example of how people will get around the e-wallet problem) but rather have a person send some really trivially small amount that you can afford to lose (as the generated private key would be known to anyone who does the calculation. The miner fee would encourage fast confirmation, but I had not thought of a 'refund' address unless I am interpreting what your saying incorrectly.

"It is incompatible with blockchain pruning, in which case there is no guarantee that information about the first send to a given address is easily accessible. You could of course set up a service that maintains this information, but at that point you don't have any advantage over just a third party that maintains bitcoin address books."

Good point, unless of course the system becomes *the* 3rd party that maintains bitcoin address books. Which is entirely possible.

"It re-enforces the notion that we should associate addresses with people, while over time, we will have to move to separate addresses for every transaction to maintain privacy in the system. I know that I'm an offender myself here by showing a vanity address below, but that's only as long as no better well-supported payment methods exist."

But doesn't your vanity address illustrate the convenience trade off so eloquently? The human temptation to personalize the ultra-anonymity that bitcoin touts as it's supreme advantage? In some ways it's a perfect system for commerce among machines, rather then people.

Perhaps it calls for a 'proof-of-concept'. :-)

[markm]

Are vanity addresses squatted much?

Even firstbits vanity addresses?

-MarkM-

[CIYAM]

Are vanity addresses squatted much?

Even firstbits vanity addresses?

-MarkM-

If you are talking about any dictionary word (or English first name and many company names) that are less than 7 characters then yes.

Somebody put 1 satoshi into each of thousands of such names over a year ago (start with 1google and click on the two tx's to get an idea).

[HeavyMetal]

There is no need to reinvent the wheel, we already have an existing directory service on the internet that is already implemented and massively scalable. What is more you do not need to change the existing servers at all to use it.

Why not just use DNS? Just put something like this in the text record:

Code:

;heavymetal.bitcointalk.com.			IN	A

heavymetal.bitcointalk.com.		117	IN	TXT	{'BitcoinAddress':'1AuAgBTyRED81JX5PMsekeTjLYiaDo9Fii'}

This would allow any domain owner to host their own phone book, a simple DNS query would fetch the info. Viola.

[crazy_rabbit]

There is no need to reinvent the wheel, we already have an existing directory service on the internet that is already implemented and massively scalable. What is more you do not need to change the existing servers at all to use it.

Why not just use DNS? Just put something like this in the text record:

Code:

;heavymetal.bitcointalk.com.			IN	A

heavymetal.bitcointalk.com.		117	IN	TXT	{'BitcoinAddress':'1AuAgBTyRED81JX5PMsekeTjLYiaDo9Fii'}

This would allow any domain owner to host their own phone book, a simple DNS query would fetch the info. Viola.

While that is quite brilliant, DNS entries aren't immutable, and don't keep a immutable record of their history. But that does open itself to a whole bunch of other interesting ideas.

[HeavyMetal]

While that is quite brilliant, DNS entries aren't immutable, and don't keep a immutable record of their history. But that does open itself to a whole bunch of other interesting ideas.

Exactly, you don't want it to be immutable. You might have your wallet compromised and need to move your incoming transactions to another address. This would let you publish a single payment address and change where it goes to by altering the DNS records. DNS servers are even capable of sending round robin records so that your incoming monies can be spread over a set of addresses.

No reason to have a 1-1 relationship.

The lack of auditable history is not ideal, but on the plus side DNS entries already have extremely secure systems set up for critical apps.

[crazy_rabbit]

While that is quite brilliant, DNS entries aren't immutable, and don't keep a immutable record of their history. But that does open itself to a whole bunch of other interesting ideas.

Exactly, you don't want it to be immutable. You might have your wallet compromised and need to move your incoming transactions to another address. This would let you publish a single payment address and change where it goes to by altering the DNS records. DNS servers are even capable of sending round robin records so that your incoming monies can be spread over a set of addresses.

No reason to have a 1-1 relationship.

The lack of auditable history is not ideal, but on the plus side DNS entries already have extremely secure systems set up for critical apps.

I actually think the audit able history might be more important then the mutability of the entry. After all, no one really worries about needing to reuse an email address. If you have "sparkythemagicdog@gmail.com" someone else will just think of some different combination or give it a shot at hotmail. The maintenance fee could solve the problem of someone snapping up "payforlove" and doing nothing with it for the next several years.

In some sense being able to change ownership of a string really only serves to support speculation. If you can't sell ownership of something, you will discourage those who might purchase it solely to speculate on it's resell value, and you would certainly prevent people from acquiring enormous amounts of strings if a small registration fee is required to be paid to the miners.