A new standard for Representing Bitcoin addresses as Mnemonics

[gauravggg21]

Hey everyone,
One of the problems we have seen common users struggle with in Crypto is dealing with the alphanumeric public addresses. We have been thinking, if there could be way to convert addresses into human readable mnemonics just how seed phrases are human readable words for private keys. Do you think this would be useful and help in driving adoption?
 
We developed a standard on the same.

Would love to have your review/feedback on it.
 
https://www.notion.so/cypherock7/Blockchain-independent-Address-Mnemonics-0f5b4e3b04de4b0992b5d76ce45691d4

[1715420240]

1715420240

[1715420240]

1715420240

[1715420240]

1715420240

[1715420240]

1715420240

[1715420240]

1715420240

[BlackHatCoiner]

While working on getting rid of the 66 hex characters in order to encrypt/sign easily, I though of what you just presented too. But I don't know if that could work in action. I mean, sure, this is clearly easier to write than a base58 encoded string, but I don't know if it'd be useful for the average user.

Since you've written your paper explaining it and no one has yet implemented it, I'd be interested to do it as an address converter.


Edit:

Convert base-58 / base-32 (bech32) to binary. This would produce 160 bits of the address. Above address in bits -

160 bits is the RIPEMD-160 hash. But an address isn't just an encoding of the hash. There is a prefix in front of the hash which is also encoded too, which means that the final result won't be 160 bits. Correct me if I'm wrong.

[witcher_sense]

Here is my feedback:

I didn't get what problem are you trying to solve by representing addresses as human-readable words? I mean, BIP-39 mnemonic is essentially an efficient way of representing binary numbers, which allows humans to interact with sensitive information without risking making errors while interacting with it. Interaction with sensitive keys implies storing, making backups, importing, memorizing in some cases. In other words, a set of words is better than a set of numbers when it comes to humans and their ability to read and memorize things. It is important to manage your private keys carefully and if they are represented in a convenient format, it will make managing less painful. I keep saying "sensitive" and "private" for some reason. Bitcoin addresses are not sensitive and private, they are public and should remain so. More importantly, users should not be encouraged to memorize their addresses because in an ideal situation you use your address only once when receiving a payment. You don't need to reuse your address, once you received a payment, just forget about it and generate another one. You don't need to make backups of or store your address either. We need none of the things that we do with our mnemonics when dealing with the bitcoin address. Your proposal will make things too complicated for the average user because the user may start doing things he shouldn't do. For example, he may mistakenly send the sensitive mnemonic instead of his address or he may confuse backups and accidentally delete his private keys instead of "temporary" bitcoin address. It will create more problems than it will solve, an inexperienced user may lose all their funds due to new standards and the hassle of distinguishing between mnemonic phrases and bitcoin addresses.

[gauravggg21]

While working on getting rid of the 66 hex characters in order to encrypt/sign easily, I though of what you just presented too. But I don't know if that could work in action. I mean, sure, this is clearly easier to write than a base58 encoded string, but I don't know if it'd be useful for the average user.

Since you've written your paper explaining it and no one has yet implemented it, I'd be interested to do it as an address converter.


Edit:

Convert base-58 / base-32 (bech32) to binary. This would produce 160 bits of the address. Above address in bits -

160 bits is the RIPEMD-160 hash. But an address isn't just an encoding of the hash. There is a prefix in front of the hash which is also encoded too, which means that the final result won't be 160 bits. Correct me if I'm wrong.

Great. We can definitely move to the implementation once we have acceptance from the broader community around its usability.

Here is my feedback:

I didn't get what problem are you trying to solve by representing addresses as human-readable words? I mean, BIP-39 mnemonic is essentially an efficient way of representing binary numbers, which allows humans to interact with sensitive information without risking making errors while interacting with it. Interaction with sensitive keys implies storing, making backups, importing, memorizing in some cases. In other words, a set of words is better than a set of numbers when it comes to humans and their ability to read and memorize things. It is important to manage your private keys carefully and if they are represented in a convenient format, it will make managing less painful. I keep saying "sensitive" and "private" for some reason. Bitcoin addresses are not sensitive and private, they are public and should remain so. More importantly, users should not be encouraged to memorize their addresses because in an ideal situation you use your address only once when receiving a payment. You don't need to reuse your address, once you received a payment, just forget about it and generate another one. You don't need to make backups of or store your address either. We need none of the things that we do with our mnemonics when dealing with the bitcoin address. Your proposal will make things too complicated for the average user because the user may start doing things he shouldn't do. For example, he may mistakenly send the sensitive mnemonic instead of his address or he may confuse backups and accidentally delete his private keys instead of "temporary" bitcoin address. It will create more problems than it will solve, an inexperienced user may lose all their funds due to new standards and the hassle of distinguishing between mnemonic phrases and bitcoin addresses.

You are right to some degree. The area where we believe it adds the most value is comparing the address just before doing the digital signature. This is especially important when you are operating a hardware wallet. This is a first hand experience from a hardware wallet manufacturer ourselves where the users complain of comparing the addresses between the desktop app and the hardware wallet. And I do not blame them because comparing characters is in fact a tedious process. And what we know from BIP39 is out of all of the advantages it offers, the verification of the correct private key while entering it cannot be understated. And mind you, verification is always going to involve a human doing it, whether you are using QR or just copy pasting an address.

Coming to the point in confusion between the Mnemonic phrases and these address mnemonics, I would say this is not a new problem. If you consider a WIF address and private keys, no normal user will be able to tell a difference between the WIF address and the WIF private key just by looking at it. And so even if we want to make this easier, we can easily append specific words like BitcoinAddress to the prefix to eliminate it in the first place.

[BrewMaster]

if you want interoperability and want the wallet developers be able to implement this method easily you have to stick to the same specifics as BIP39 which means 2 things.
1. instead of using 1024 words and selecting 10 bits each time you should use the same 2048 words in the word lists used by BIP39 and select 11 bits.
2. instead of padding with meaningless zeros why not use a checksum again similar to BIP39? a P2PKH address would require 5 bits of checksum.

also the proposal misses the address types. we already have multiple, the HASH160 used in an address can be 3 different address types: P2PKH, P2SH, P2WPKH.

[NotATether]

if you want interoperability and want the wallet developers be able to implement this method easily you have to stick to the same specifics as BIP39 which means 2 things.

And the most important of them is don't make the same mistake that BIP39 did by leaving out space for version bits. This address scheme absolutely needs version bits if you want to amend that proposal later or else amendment will be impossible since there will be no way to tell apart new-format addresses from old-format ones.


But I think a better, more human-readable way than using BIP39 words would be to use domain names but build a different variant of DNS where wallets can self-assign themselves domains if consensus agrees that domain is not taken.

Maybe for the top level domain name, the BIP number can be used, so you end up with an address like:

Code:

bitcoin:bitcointalk-signmessage.notatether.bip999

Or the version with bitcoin:// instead, IMO those two should be made equivalent. Right now, all OSes make a web browser handle http:// and https:// protocols, and they open some Bitcoin wallet to handle the bitcoin:// protocol, so reusing the bitcoin: prefix fits nicely into standards we already have.

One big advantage to making our own decentralized DNS resolution is that all full nodes will be routing these bitcoin domain names and not a handful of centralized name servers that are especially vulnerable to DDoS attacks. Full nodes can route addresses intended for some wallet using something like BGP until it reaches the intended node, or an SPV that hands it to a wallet.

[gmaxwell]

It has no error protection, swap two words and millions of dollars vanish into a black hole.  Maybe that kind recklessness is acceptable in ethereum but it doesn't fly in Bitcoin.

Bitcoin addresses are also not carrying 160 bits of data, they carry a 5-bit version and up to 40 bytes of payload, although 160 and 256 bits are commonly used now.  160 bits implies only 80-bits of collision security which is not really adequate when multiple parties are involved.

BIP39 really wasn't intended to be decoded, in BIP39 though an encoding mapping is specified to generate uniform mnemonics the inverse isn't used.  It's done this way so the word list is not normative-- different parties can use different wordlists.  Only part of the world speaks english and an english word list is pretty difficult for some to use.  Schemes that depend on decoding can't be compatible with different wordlists.

In informal testing I found that word encoded addresses were much slower and more error prone (e.g. people enter sounds-alike words or just misspell them) to enter than alphanumeric (so long as changes in case are not involved, mixed case alphanum is extremely slow)-- so I'm dubious about there being an actual benefit.

[gauravggg21]

It's definitely more readable, but it's still too long. One solution is using longer words list, but it significantly increase total words on the list (by 2^N) while it only slightly decrease length of the "address mnemonic" (by 160 bit/N)

P.S. Since it contains many technical details, i think you could get more constructive feedback if the thread moved to Development & Technical Discussion.

We tried posting it there but it got removed both the times.

[gauravggg21]

if you want interoperability and want the wallet developers be able to implement this method easily you have to stick to the same specifics as BIP39 which means 2 things.
1. instead of using 1024 words and selecting 10 bits each time you should use the same 2048 words in the word lists used by BIP39 and select 11 bits.
2. instead of padding with meaningless zeros why not use a checksum again similar to BIP39? a P2PKH address would require 5 bits of checksum.

also the proposal misses the address types. we already have multiple, the HASH160 used in an address can be 3 different address types: P2PKH, P2SH, P2WPKH.

1. Agreed with this. Didn't take into account the operability issue before. Will make the necessary changes here.

2. Will have to check how much the checksum makes sense in this context.

I don't think there will be any issues with the address type since the conversion of addresses will be done on the final form

[gauravggg21]

if you want interoperability and want the wallet developers be able to implement this method easily you have to stick to the same specifics as BIP39 which means 2 things.

And the most important of them is don't make the same mistake that BIP39 did by leaving out space for version bits. This address scheme absolutely needs version bits if you want to amend that proposal later or else amendment will be impossible since there will be no way to tell apart new-format addresses from old-format ones.


But I think a better, more human-readable way than using BIP39 words would be to use domain names but build a different variant of DNS where wallets can self-assign themselves domains if consensus agrees that domain is not taken.

Maybe for the top level domain name, the BIP number can be used, so you end up with an address like:

Code:

bitcoin:bitcointalk-signmessage.notatether.bip999

Or the version with bitcoin:// instead, IMO those two should be made equivalent. Right now, all OSes make a web browser handle http:// and https:// protocols, and they open some Bitcoin wallet to handle the bitcoin:// protocol, so reusing the bitcoin: prefix fits nicely into standards we already have.

One big advantage to making our own decentralized DNS resolution is that all full nodes will be routing these bitcoin domain names and not a handful of centralized name servers that are especially vulnerable to DDoS attacks. Full nodes can route addresses intended for some wallet using something like BGP until it reaches the intended node, or an SPV that hands it to a wallet.

There are projects like easypaysy.org trying to achieve something similar as a Layer 2 protocol on top of Bitcoin. However, as mentioned in the doc, it lacks privacy and a chain agnostic support. Where we think our standard will add value is when the user is trying to compare addresses in between the hardware wallet and the Desktop app. Which I feel even a decentralized DNS won't be able to solve since ultimately the signature will be done on the intended public address only which the user needs to verify manually.

[BrewMaster]

2. Will have to check how much the checksum makes sense in this context.

I don't think there will be any issues with the address type since the conversion of addresses will be done on the final form

whenever user has to enter something or write something down, checksum makes a lot of sense because it provides a very fast way of verifying if the input is correct and doesn't have mistakes in it. since padding is already used then the space for it is also already allocated.

as for address type you want to have scaleability and since there is no way to guess the type by just knowing the data length (all 20 bytes) it has to be explicitly specified either by the user manually or be encoded into the string.
the current encoding methods already have this. for example if it is base58 and the data is 21 bytes and starts with 0 it is P2PKH but if it 21 bytes but starts with 5 then it is P2SH.

[buwaytress]

Greg's point about native language is probably underrated in most discussions of having more "human-friendly" features. It's only my second language and so the perceived benefits of having mnemonics to represent addresses might only cross the mind of English speakers (so the ease of memorising seed phrases, for example, almost disappears for most non-English speaking users, also my very unscientific observation).

Some native Chinese speakers I know actually find current formats surprisingly friendly (as numbers are more meaningful to them in Mandarin, and you can see this in how the majority of china-based urls use numbers instead of alphabets). Some people prefer looking for number strings as vanity addresses, for example.