Topic: An easy way to remember a bitcoin address - page 8. (Read 15145 times)

This is the problem of the wallet implementation. Whether they are using my spec or not, they need to manage that correctly (needed for checking a Partial Merkel Tree), this is orthogonal to my spec.
Do you refer to the fact that one "brain address" might point to an invalid TxOut after a reorg ?
One way to mitigate that is to ask for 101 confirmations. (coinbase maturity)
However, the fact that some services will not want waiting so much time, even if my spec ask for it, might be troublesome. I don't have a better solution though.

Why would they do that ? there is nothing to win by doing that.

I will not use your encoding technique.
The reason is that there is no reason to choose the number of words in a "brain address". As opposed to a private key, the fewer the better.
The best way to encode a "Brain Address" is to use the VarInt encoding that all bitcoin wallet already implement. (or the less supported CompactVarInt internal to bitcoin core)

Also, encoding the TxIndex is inferior to encoding the PathToLeaf, for 2 reasons : it takes more space, and more than a simple Partial Merkle Tree would be required as proof. (whose proof checks are already implemented in all SPV wallets)
Code reuse would be maximized, code error minimized, so adoption by wallet providers should be better.

Moreover, each words represents 11 bits of information.
If we need 23 bit for encoding an address, then we have 10 bit that serve for nothing. I propose to fit the checksum inside.
The size of the checksum in bit would be something like Max(5, UnusedBitCount).

This should represent all current payment destination on 3 or 4 words. And it will goes up very very slowly.

You have not fixed the following problems:

1. blockchain reorg

2. Miners may try to fill up a block with garbage for a vanity address

To fix the reorg problem you have to include blockhash and/or tx-hash somewhere in your formula. This is tricky because that would lengthen the address

To fix the vanity address problem miner shouldn't be able to determine the address before a block is found. Again, this is avoided if the blockhash is part of the formula

------------------------
I'd like to propose the following method for referring any ScriptPubKey on the blockchain. I don't care how people interpret the information in the ScriptPubKey:

Version: 1 bit (always 0)
Height: 20 bits (up to block 1048576, enough for 13 years)
txIndex: 19 bits (up to 524288 tx/block, won't happen until the blocksize is >110MB)
TxOut index: 8 bits (up to 256 outputs/tx)
Checksum: 29 bits (slightly weaker than 32 bits in a standard bitcoin address)
Total: 77 bits, requiring 7 words to encode

All components are zero-padded. Anything beyond block 1048576 / txIndex 524288 / TxOut index 256 are invalid.

Checksum is the first 29 bits of SHA256(Blockhash-ScriptPubKey)

The 48-bits (Version-Height-txIndex-TxOut index) is split into 6 fragments of 8-bits
The 29-bits Checksum is split into 5 fragments of 5-bits and 1 fragment of 4-bits
Fragments are concatenated alternatively, so miners are not able to mine a vanity address without giving up a successful block hash.

To resolve the address, an SPV node has to obtain the ScriptPubKey with Height-txIndex-TxOut index, and verify the Checksum with Blockhash-ScriptPubKey

Reducing to 6 words is possible but it reduces the checksum security and future compatibility
Version: 1 bit (always 0)
Height: 20 bits (reducing to 19 bits will make it overflows in less than 4 years)
txIndex: 16 bits (up to 65536 tx/block, won't happen until the blocksize is >13MB)
TxOut index: 5 bits (up to 32 outputs/tx)
Checksum: 24 bits (Not sure if this is enough)
Total: 66 bits

Or 5 words:
Version: 1 bit (always 0)
Height: 20 bits
txIndex: 13 bits (up to 8192 tx/block, won't happen until the blocksize is >1.5MB)
TxOut index: 4 bits (up to 16 outputs/tx)
Checksum: 17 bits (This could be risky)
Total: 55 bits

8 words would be good enough for foreseeable future. It's still much better than encoding an 160-bits address with 15 words:
Version: 1 bit (always 0)
Height: 22 bits (enough for >70 years)
txIndex: 25 bits (enough for 6.8GB block)
TxOut index: 11 bits (up to 2048 outputs/tx)
Checksum: 29 bits
Total: 88 bits

(Slightly OT) FYI BIP39 wordlists aren't guaranteed to use unique words wrt each other; in particular the two Chinese word lists share over 50% of their words so you'd probably need to choose one over the other (or neither).

I agree that there is still a trust relationship between the BIP70 provider and the user.
However there is no trust relationship between a "Brain address" provider and its user. (contrary to firstbits)
What we can't do with my scheme is having both : No address reuse + No trust relationship with BIP70 provider, you have to pick one of those.

It can be solved theorically by publishing a Stealth Address in the OP_RETURN instead of a bitcoin payment url.
But I don't think Stealth Addresses are wild spread enough for now, and is a pain because of OP_RETURN limits.


You have indeed the same result, the difference is that a PathToLeaf is an information that can be checked in a Partial Merkle Tree (SPV), while TxIndex is not.

The difference is in the size of the proof. In the first case, the "brain address provider" would need to send you either the whole block as the specified Height to prove he is not lying, or the ordered list of all Transaction Ids in the block. (this latter proof is compact enough but can't be fetched directly on the bitcoin network)
In the second case, the "brain address provider" just need to give you the Transaction + Block Header + Partial Merkle Tree to it. (such information can be retrieved directly by connecting to the bitcoin network, on low capacity/bandwidth devices)

I would use BIP39 dictionary. https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md
Currently supported are English,Japanese,Spanish,Chinese (Simplified),Chinese (Traditional) and more will be provided by the community in the future.

You can rely on an untrusted "brain address provider" thanks to the simplicity of the proof, people don't need the full blockchain.

Maybe, the best way to know is to try, and I will.
My point is that you don't memorize wire transfer account number because you can't, not because you don't have the need.
This is why people still remember their phone number, it can fit in their brain. A BIP70 most likely do not and is prone to lookalike attacks.
I believe that if people have a way to easily memorize a payment destination, they will use it.

I have a subtle exercise for you, advocating about remembering/sharing a payment url :
What is the difference between "http://payment.com/u/tata" and "http://payment.com/u/tata" ? (you can try comparing these two addresses in your favorite programming language, they are not the same)

It says in OP it will follow BIP39 wordlists, there are other languages: https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md

How is PathToLeaf different that the txIndex? It looks to me that if you write the txIndex in binary, you have the same result.


It fixes the address reuse if and only if the user is willing to set up a payment server. But later you say that most people wouldn't go through the trouble of doing so.


It works with a carefully crafted dictionary. What would you use? Would you be able to provide one for different languages? The checksum detects errors but doesn't correct them. Your friend would not be able to pay you.


But it prevents pruning. Eventually, people will not have your tx if it's buried deep down and they will rely on an online service.

In any case, I'm not sure there is a need for this. If it's a large amount, I would prefer to give a QR code or a payment URL (if I'm a business). For a small amount, I would tell my friend that I will email him the address later or I'd set up a gmail account [email protected] with an autoreply that gives a payment address.

Nobody has discussed that this proposal is anglocentric. I speak Spanish, and it's as hard for me to learn “car yellow what” than “1hshbx”.

I thought we agreed that it didn't meet both "Easy to set up/maintain" and "No address re-use" at the same time, given that BIP70 isn't easy to run on your own (or it fails "Decentralized" if you use a 3rd-party processor which implements BIP70)?

Do you memorize you mobile phone number ? I do, and my friends do.


Thanks laurent, the second part will release beginning of march.
I don't want to rely on namecoin and another blockchain since the bitcoin network can already do that easily.
BIP70 is fine, but as I said, you can't ask Joe to register a domain name and hosting its server.
If Joe use a third party service for that, then, most of the time the url can't be memorized (hard to remember ids).
If it can be memorized, the longer the address, the higher the chances to send money to someone else by mistake.

That's a lot of if, that in any case my scheme would solve.

My scheme would have a checksum embedded and can fit any payment destination (BIP70 or fixed address) in 4 easy to remember, and hard to mix up words.

Hi Nicolas,
Really interesting idea but I fear you still have to cope with blockchain pruning if you plan to store this data in the bitcoin blockchain.
Why not rely on a bip70 uri stored in namecoin blockchain ?
Out of topic: congrats for your book. amazing work !

I don't think that's a fair analogy.

(I think) OP's desire was to make it easy to create or reference a receive address in informal situations without carrying anything with you (e.g. splitting a bill with a friend). Traditional transaction mechanisms do that just fine today (cash: don't need to remember anything; checks: just need to remember your own name; centralized e-money (e.g. PayPal), just need to remember your email address/account ID).

I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include:

• Easy to remember
• Easy to set up/maintain
• Decentralized
• No address re-use

If you can't achieve all of the above, than you need to prioritize. I'd nix either the first or the second, and that's what we already have today (base58check or BIP70). I think nixing either of the other two would be a worse idea, but that's subjective.

hey , would you please tell me why we should avoid reusing adresses ? cause i dont see a reason to do that. please aware me : >

Would you memorize your bank account number? I won't.

Why should I memorize by bitcoin address?

That's kind of the point though. If Joe can't run his own payment server (and wants to avoid address re-use), then he's stuck with a centralized solution anyways. And if he's stuck being centralized, there doesn't seem to be much reason to use the blockchain to look up some account ID if the centralized provider he's chosen can do it instead.


If the payment processor implements an easy URL scheme with a short checksum, than that's great. It doesn't require encoding anything on the blockchain, though.

Maybe there's more merit to the static-address solution you've described. I'm skeptical that it offers much improvement over firstbits, but I could be wrong.

Except you can't expect average Joe to manage his own domain name, and host his own payment server.
Average Joe can create an account on a third party payment server though.
But such server : either provide an url that can't be remembered and easily spelled. (http://payment.com/u/dzopUDZiziK)
Either use the user's name (http://payment.com/u/toto), but in such case, you can easily get misspell the user name or domain, resulting to money sent to someone else.

My scheme do works whatever how a payment url is created.

It sounds like your scheme (in the BIP70 case) is simply a URL shortener, except that in some cases it will end up being more of a URL lengthener.... remembering a few random English words seems harder to me than simply remembering a domain name that one creates for that purpose.


At least one online wallet does this, for example if you'd like to send me a tip, visit here: https://greenaddress.it/pay/GAMiQ3yzZFD6djdqpYo4YGdRHrMot/ (they have only my xpub, assuming of course that you trust their client software isn't malware).

As I said, I fixed the address reuse problem, so it should not be a concern.

The reason why I want to do that is kinda the same reason why most people memorize their own mobile phone number.
You can't have forgotten it at home when someone ask for it.

Why would you want to remember a Bitcoin address at all? That's a mistake.

1. We got software to do that for us.
2. You should avoid reusing addresses as much as possible.

Let me quote myself from another thread:

I found a way to fix all the problems you pointed out.

Having a SPV proof
I will encode a location in the blockchain in the following way :
[Height]-[PathToLeaf]-[TxOut index] (I'll call such information a "blockchain address")

[PathToLeaf] will be a bit array describing how to go from the merkle root down to the leaf representing the transaction. (1 for go right, 0 for go left)
This has the nice effect to be shorter than the [Tx Index] I thought about, but also to fit in a classical Partial Merkel Tree. (Log(N;2) bit on the transaction count of the block)

Fixing Address Reuse
If the blockchain address references a TxOut that is not OP_RETURN, then it it referencing the ScriptPubKey. (do not fix address reuse)
If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time)

Preventing user error caused by similar words
We can append a checksum at the end of the the "blockchain address" before encoding it in a "brain address" such as:
Brain Address = ([height]-[PathToLeaf]-[TxOut index]) + Hash([height]-[PathToLeaf]-[TxOut index])[0]
Now if the user mistake between two words, there will be no risk of sending funds to the wrong place.

Result: All blockchain reference and address could be represented in 3 or 4 easy to remember words, only with the blockchain.

This fix all shortcoming of firstbits :

• it remove any need of trust relationship with a "brain address" web service.
• payment destinations are memorizable
• A SPV client only need a partial merkle tree for checking the result
• No fixed address

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.