An easy way to remember a bitcoin address

[Nicolas Dorier]

I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)

However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.

Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index

Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)

I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)

[1714124016]

1714124016

[1714124016]

1714124016

[1714124016]

1714124016

[1714124016]

1714124016

[doof]

Only after enough confirmations.

[cakir]

I would by this short domain: "adr.ss"  (.ss is tld of south sudan)
Then I would use it to remember bitcoin addresses adr.ss/cakir redirects to my btc address etc.

[gmaxwell]

Basically this idea existed more or less before in the form of the ill fated 'firstbits'; I consider this proposal to be ill-advised for the same reasons.

Addresses should generally not be reused. Reusing addresses harms the your security and privacy as well as the privacy of all Bitcoin users. Extensive address reuse contributes to systemic risks which endangers the system (what happens when RPG wielding ninjas show up at mining farms with demands to not mine transactions belonging to their enemies?  If regular transactions are conducted so that they are indistinguishable to their author's enemies we never need to find out). While the community may not go so far as to prohibit reuse, building infrastructure that rewards it is not a good plan.

These short addresses are immediately subject to lookalike attacks-- a popular address is "wolf larceny tape butter" ... great, I go and create "golf larceny tape butter", "wolf larceny ape butter", "wolf larceny tape butler" and so on... I spam these clones out in various places or just trust human error to guide things along, and now I'm receiving funds from other people. We don't even need an attacker here, all outputs are constantly being assigned addresses, the space of working addresses dense-- instead of the very intentionally sparse case which we have with addresses today where its nearly impossible to send to an incorrectly entered address.

As you note, the security here is totally undermined by a reorg. So beyond chance reorgs breaking things for people and causing their funds to go off to be lost in space, now there is a great incentive to reorg that didn't exist before. (there also is some fun nuisance perversion like miners selling high value vanity positions in blocks with this particular scheme; spamming up the chain to make sure to register the really goods one, sometimes requiring large indexes.).

One could not resolve these addresses without a copy of the entire blockchain or at least a forever growing unprunable database (as with firstbits) which would need to be accessable to each and every wallet. In practice most people would depend on centralized services to resolve these (as  they did with firstbits), and in practice the services will eventually return wrong results, even without intentional fraud (as with firstbits).  Of course, any of these services would be prime targets for compromise; a well timed replacement could redirect huge flows of funds.

This also requires a separate registration step, which reduces the scalability of the system due to additional overhead, and makes the system less instant gratification. You end up with something where you have to pay fees to establish an 'identity' just to receive funds to pay the fees with. Necessitating multiple use modes.

Less critically the use of a particular fixed wordlist is culture/language laden and has seemed to be somewhat problematic for BIP39; though I mention this only in passing.

[Nicolas Dorier]

Basically this idea existed more or less before in the form of the ill fated 'firstbits'; I consider this proposal to be ill-advised for the same reasons.

Addresses should generally not be reused. Reusing addresses harms the your security and privacy as well as the privacy of all Bitcoin users. Extensive address reuse contributes to systemic risks which endangers the system (what happens when RPG weilding ninjas show up at mining farms with demands to not mine transactions belonging to their enemies?  If regular transactions are conducted in such a way as to make their enemies transactions indistinguishable we never need to find out).

I agree about privacy concern. But right now, we have no way of printing a payment destination on an unpowered and unconnected device (aka paper).
The exception is stealth addresses which I have great hope once we resolve the OP_RETURN problem.

What about publishing the stealth address on the blockchain instead of a Bitcoin Address ? This would solve your concern of privacy while still allowing to be remembered in a few words.

These short addresses are immediately subject to lookalike attacks-- a popular address is "wolf larceny tape butter" ... great, I go and create "golf larceny tape butter", "wolf larceny ape butter", "wolf larceny tape butler" and so on... I spam these clones out in various places or just trust human error to guide things along, and now I'm receiving funds from other people.

This is not the usage I am envisioning.
I don't want to use such address to be recognized. My use case is more between two persons wanting to exchange bitcoin without the need of a physical stuff that bear the address.
-"where to I pay your ?"
-"Pay me to : Red, Car, Building, Trigger"
For human recognition, encoding an address on an identicon is more appropriate. In fact, I'm also looking out how I can make an identicon safe from lookalike attacks.

Also, BIP39 lists are created by making it hard to confuse between two words. What is important in this case is not the string metric, but the "sound" metric of the words. Assuming words were wisely selected in bip39 dictionaries, we should be relatively safe.

One could not resolve these addresses without a copy of the entire blockchain or at least a forever growing unprunable database

Well, the only information that gives problems is the Transaction Index in the block.
If I can find another feature for identifying the address, a partial merkel tree would be enough for solving your issue about the need of having the whole blockchain.
The client would just rely on untrusted third party services (or by connecting to the bitcoin network) and just check that address given the words are correct.

This also requires a separate registration step, which reduces the scalability of the system due to additional overhead, and make it less instant gratification. You end up with something where you have to pay fees to establish an 'identity' just to receive funds to pay the fees with. Necessitating multiple use modes.

I don't want any registration needed, so I won't do that.

[Nicolas Dorier]

I would by this short domain: "adr.ss"  (.ss is tld of south sudan)
Then I would use it to remember bitcoin addresses adr.ss/cakir redirects to my btc address etc.

Thanks, but I don't want any registration needed.

[gmaxwell]

The exception is stealth addresses which I have great hope once we resolve the OP_RETURN problem.

There is a whole host of separate problems there, including needing to witness the whole blockchain to scan for payments (it breaks SPV and/or makes you again depend on a central server)

The usecase you're describing is addressed by the payment protocol.  You give people a payment uri.

For human recognition, encoding an address on an identicon is more appropriate. In fact, I'm also looking out how I can make an identicon safe from lookalike attacks.

You cannot generally. Look alikes can be ground. There is a nice example of this for openssl picture fingprints that I'm having trouble finding.

Also, BIP39 lists are created by making it hard to confuse between two words. What is important in this case is not the string metric, but the "sound" metric of the words. Assuming words were wisely selected in bip39 dictionaries, we should be relatively safe.

There are plenty of lookalke/soundalike/mean-alike words in it e.g. [choice, choose], [drip, script, trip], [risk, brisk], [load, road] (just picked single words at random and found the first obvious matches; what-- no one ever confuses "r" and "l" sounds?).

If I can find another feature for identifying the address, a partial merkel tree would be enough for solving your issue about the need of having the whole blockchain.

That would, in fact, be an improvement over firstbits.

I don't want any registration needed, so I won't do that.

The process you described fundamentally requires registration. Before I can give you a short address I must have registered one in the blockchain.

[Nicolas Dorier]

The process you described fundamentally requires registration.

My bad, I thought you were talking about a registration in a centralized service. (record off chain)

There is a whole host of separate problems there, including needing to witness the whole blockchain to scan for payments (it breaks SPV and/or makes you again depend on a central server)

Depending on another server for scanning is not really a problem for my case. I don't want to make an autonomous wallet.
My main concern is that all information needed for a "brain address" is in the blockchain, and verifiable by devices without direct access to the whole blockchain.
I assume that the device depends on an untrusted server. (preferably another bitcoin node, at worse a third party server)

If Bob gives its "brain address" to Alice, Alice does not need the blockchain for fetching the full address, she can ask the resolution of it to an untrusted server, with proof.
If I find a good feature set for encoding the address, then Alice might be a simple SPV node.
The proof would be : [merkleblock + tx].

If I don't find a better feature set and stick with [height+tx index+txout index], Alice would depends on a server, but do not need to trust it. She is still able to verify the fetched address is not replaced/faked/bugged by herself.
In such case, my server would return the transaction + all transaction ids in the block + block header.
The proof would be : [blockheader + transaction ids in the block + tx].

I would prefer the first solution though... will sleep on that, thanks for the input !

There are plenty of lookalke/soundalike/mean-alike words in it e.g. [choice, choose], [drip, script, trip], [risk, brisk], [load, road]

How about adding a checksum in the encoded data ? Having the wrong word would not result in user's fund losses.

[findftp]

Couldn't we just use the existing DNS for this purpose?
Let's connect whatever public address to your email address!

Then people are able to pay to your email address instead.
It's also much easier to change the underlying public address into a new one.

[JessicaSe]

i think someone should start a service where someone can store their bitcoin address online and get a personalized short link that they can open anywhere and get the address they stored there

[findftp]

i think someone should start a service where someone can store their bitcoin address online and get a personalized short link that they can open anywhere and get the address they stored there

That's called DNS, I just proposed it.
It already exist.

To make it decentralized, integrate the DNS into bitcoin, or use another alt (namecoin?)

[Nicolas Dorier]

i think someone should start a service where someone can store their bitcoin address online and get a personalized short link that they can open anywhere and get the address they stored there

That's called DNS, I just proposed it.
It already exist.

To make it decentralized, integrate the DNS into bitcoin, or use another alt (namecoin?)

No, I want someone to just take whatever address and find a way to memorize it easily, without registration except on the blockchain.
If you use DNS, then you use a payment address. (BIP70)
I don't want any data stored somewhere else than in the blockchain. (nor alt chain)

I think someone should start a service where someone can store their bitcoin address online and get a personalized short link that they can open anywhere and get the address they stored there

Same problem, out of blockchain registration, not something I want.

[DNS] It's also much easier to change the underlying public address into a new one.

It is not. People would need to depends on a central trusted service instead of just consulting the blockchain. (Giving rise to attack/bugs of address replacement that gmaxwell talked about above)

[Bitcoinmeetups.org]

Those with photographic memory can remember anything easily.

Can you offer Bitcoin memorization as a free service?

https://bitcointalk.org/index.php?topic=948359.msg10383498#msg10383498

[picolo]

I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)

However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.

Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index

Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)

I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)

If someone wants to remember its priv key he can remember a few words that will lead to it and I think your proposition poses problems when we can get around not remembering our public key.

[DeathAndTaxes]

I have to agree with gmaxwell address reuse should be discouraged.  Yes I know people will do it anyways but I would not go out of my way to make it easier.  Firstbits was a valid system and easier to adopt/use that what you propose but it was still a bad idea and I am glad adoption died off. 

The major problem is that re-use reduces the privacy not just of the person who re-uses their addresses but for everyone else because it makes it easier to track transactions.  If all keys were used only once it would make graph mapping the blockchain much more difficult. If you want to enhance your wallet how about reducing the information leak from change addresses.  In theory any output can be the change but as practice most wallets implement this so poorly it becomes trivial to determine the change output.  There is a lot that can be done to make transactions more opaque so I would consider that an area to improve.

It isn't just wallet designers however.  It requires effort from all parties.  It would be useful if services provided the option for a user to provide an extended pubkey.  For example since people love change addresses a forum like this could have a field on the profile where the user provides an extended pubkey.  The site would not display the address publicly but would compute the next address from the extended pubkey and display that.  When a transaction is detected it would increment and display the next address.  Similarly mining pools could in a similar fashion send all user payments to a new address by just having the user provide an extendedpubkey instead of a static address.

[Nicolas Dorier]

Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index

minaddress.info is based on similar concept.

If Full Address is 1PPJ5x74KEo9euEiSJKxyBUfHMRQrXKL1f
MinAddress will be 4e0fd-1ppj

Except you can't easily remember as 4 english words.

I have to agree with gmaxwell address reuse should be discouraged.  Yes I know people will do it anyways but I would not go out of my way to make it easier.  Firstbits was a valid system and easier to adopt/use that what you propose but it was still a bad idea and I am glad adoption died off.

The major problem is that re-use reduces the privacy not just of the person who re-uses their addresses but for everyone else because it makes it easier to track transactions.  If all keys were used only once it would make graph mapping the blockchain much more difficult. If you want to enhance your wallet how about reducing the information leak from change addresses.  In theory any output can be the change but as practice most wallets implement this so poorly it becomes trivial to determine the change output.  There is a lot that can be done to make transactions more opaque so I would consider that an area to improve.

It isn't just wallet designers however.  It requires effort from all parties.  It would be useful if services provided the option for a user to provide an extended pubkey.  For example since people love change addresses a forum like this could have a field on the profile where the user provides an extended pubkey.  The site would not display the address publicly but would compute the next address from the extended pubkey and display that.  When a transaction is detected it would increment and display the next address.  Similarly mining pools could in a similar fashion send all user payments to a new address by just having the user provide an extendedpubkey instead of a static address.

Like I said, an alternative is to publish a stealth address on the blockchain and referencing it by 4 words. It fix completely every of your complains.
I need a solution that work can be printed on an object or in the head without central trust. So I don't consider ext pubkey usable in my scenario.

Also my scheme is nothing like Firstbits, because it does not depends on centralized trust.

If you want to print an address on paper/phone shell/tee-shirt, you have three way of achieving that : Either a regular bitcoin address, either depending on a service with centralized trust weak to replacement (like payment url BIP70), either stealth addresses. Sadly there is no other alternatives.
We can scream all we want about privacy leaking, there is a specific problem and I see only two solution (but stealth address are not widely supported and very limiting because of OP_RETURN limit), privacy leaks are worth it for my users.
Telling them "don't do that because you put others at risk" is not an option. If this is the only downside, I'll implement my scheme with a fixed Bitcoin address and just wait better support for stealth address + a lift of OP_RETURN.

[xingming]

I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)

However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.

Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index

Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)

I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)

remebering an bitcoin address is good but  what will you do if you made a mistake will sending some bits
to it ? I think you can just create a simple email or text file in you computer and save it simply there .

[DeathAndTaxes]

Also my scheme is nothing like Firstbits, because it does not depends on centralized trust.

FirstBits didn't require centralized trust.  Anyone could using the algorithm and a copy of the blockchain determine the firstbits of an address or the address from a firstbits.  It is no more or less centralized then the scheme you proposed.  It is more efficient but no more secure.  If you compute it yourself it is secure and if you don't you are trusting the person who computes it.

Telling them "don't do that because you put others at risk" is not an option. If this is the only downside, I'll implement my scheme with a fixed Bitcoin address and just wait better support for stealth address + a lift of OP_RETURN.

Well that isn't the only downside. What happens when someone who uses a wallet that doesn't support this scheme sees the mnemonic and wants to send funds to it.  How are they going to convert "yellow happy dog runner" into the proper address?  Well they could download some additional open source software, make sure it is legit, and use that along with the blockchain to compute the proper address.  They "could" do that but lets be honest they won't.  We already they won't because they could have decoded firstbit addresses on their own but they didn't.  What they will probably do is google "name-of-your-scheme" and very likely find a dishonest site which will decode "yellow happy dog runner" to an incorrect address owned by the site operator.  Maybe they even show the wrong transaction in the blockchain with a link to blockchain.info to make it look more legit.  They send funds to the address they think is right, the money is gone and your user and the sender are both confused as to what happened.

So yes if 100% of wallets natively supported your scheme it wouldn't require any third party trust (beyond trusting the wallet developer which is implicit to some degree).  Of course if 100% of wallets supported firstbits it also wouldn't require third party trust but we know how that turned out.

[Nicolas Dorier]

FirstBits didn't require centralized trust.

Indeed, I messed up with another service. By the way "1kk5k" is hardly memorizable, using words should be better.

So yes if 100% of wallets natively supported your scheme it wouldn't require any third party trust (beyond trusting the wallet developer which is implicit to some degree).  Of course if 100% of wallets supported firstbits it also wouldn't require third party trust but we know how that turned out.

Such argument apply to any new products.
"X will not be used by all, so you should not bother. proof, look at Y !", then we should stop innovating altogether.
The thing is, I have already people ready to use it, it takes me 1H to code in the wallet I am developping. So I'll just throw that out and see how it goes.
If wallet developers think it is a good idea, they'll decide by themselves.

The difference between 1kk5K and "Car Yellow Dog Building" is big for a user. (btw, I did not managed to make firstbits work for my address )
However I don't find the implementation details of firstbit, do you have a link ? I would like to know how they encoded the address reference.

[gmaxwell]

FirstBits didn't require centralized trust.

In practice it did, because it required an unprunable copy of the whole blockchain to do anything with it. So everyone used it with various services and eventually the services returned inconsistent results (due to differently mishandling reorgs).

There are lots of things that can be done which are merely decentralization theater, sometimes because the design obfuscates the hidden decentralization, in other times because they're  not practical without it.  I'd say that was true for firstbits in practice, its true for the scheme here too though I believe it could be improved to be SPV-ish; but that still leaves the other downsides.