An easy way to remember a bitcoin address

[Nicolas Dorier]

I'm understanding now how you want to encode y and z !
Good job, this is awesome !

Modifying my code...

[jl2012]

I'm understanding now how you want to encode y and z !
Good job, this is awesome !

Modifying my code...

I don't have a rigorous proof but I believe this is not only a one-to-one function, but also the most efficient way to encode.

Assuming a minimum checksum size of 19, in every block before 1,048,575, there must be at least 4 4-word addresses: the first output of the first 8 txs in the block

After block 1,048,575, only the first output of the coinbase tx is 4-word.

[jl2012]

How the current implementation addresses the following criticism?

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.

The current implementation does not restrict the type of output. It applies to any scriptPubKey. So people may, for example, 'register' stealth address with OP_RETURN. This implementation could also replace txid in daily use. It is even better than txid because it directs to a specific output in a tx.

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.

With adequate checksum bits, the odds of successful lookalike attacks is extremely slim. Even a miner could not try to mine a "vanity address" because they have to discard successful block hash for such vanity address mining (blockhash is part of the checksum)

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.).

A reorg will make the checksum invalid. The address is safe to use even with only 1 confirmation. As mentioned, it is not possible to mine a vanity address

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.

It is SPV verifiable. In practice, an SPV client will ask a centralized service to resolve, and to provide the compact proof

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.

People could do it when they are doing real transaction, so the marginal cost and harm is lowered

[Nicolas Dorier]

I'll implement that during next week + provide a public service that other people can play with it.
I'll also copy your BIP + what we talked about on github.

[jl2012]

I'll implement that during next week + provide a public service that other people can play with it.
I'll also copy your BIP + what we talked about on github.

I'm thinking if we should allow encoding of tx inputs with this scheme. Not sure if it is really useful. It could be done with 2 ways:

1. Put all inputs behind outputs. If there are 6 outputs and 3 inputs, index 0-5 will be the outputs and 6-8 will be the inputs. This won't affect the length of output addresses but input addresses may need more words.

2. Use 1 bit to denote input/output. This may increase the length of output addresses

[Nicolas Dorier]

I think we should make another BIP if we want to extend on inputs.

Let's not forget that this BIP is for people to remember a payment destination.
I don't see any usecase where someone would want to rememember an input.

Even if it is the case, we should make a new BIP because we don't have the same security requirement for referencing TxIn, so we would be able to remove most of the checksum.

[tss]

great you remembered your address.  what about your private key?  isn't that a bit more important?

[Nicolas Dorier]

great you remembered your address.  what about your private key?  isn't that a bit more important?

That's just not the point of this BIP. BIP39 already deals with that, and you can't compress the private key as an address.

[specgamer]

Wow this is useful, but too hard for me to remember.
Good to know tho,

[hhanh00]

Since you make the 'reference' transaction, you can make one that has a low number of txo. Let's say your txo index has to be < 4. 2 bits are enough to encode that offset. You want 20 bits of checksum so txo index and checksum fit in 22 bits or 2 words.

The block height is encoded with a continuation bit and either 20 or 31 bits for a total of either 21 bits if height < 2^20 (~1 million) or 32 bits if above but lower than (2^31). Add the version bit and it comes exactly to either 2 or 3 words.

TxIndex is simply encoded as words.

Recap:
# first part
- version bit: always 0
- length indicator
    - if 0: use 2 words
    - if 1: use 3 words
- block height

# 2nd part - always 2 words
- txo index: 2 bits
- checksum: 20 bits

# remaining words
- tx index

For any reference tx below index 2048 before height 2^20, it is guaranteed to be 5 words. The format is pretty constant and doesn't rely on txcount or the number of txo in the reference tx. Moreover, generation and parsing is straight forward.

[jl2012]

Since you make the 'reference' transaction, you can make one that has a low number of txo. Let's say your txo index has to be < 4. 2 bits are enough to encode that offset. You want 20 bits of checksum so txo index and checksum fit in 22 bits or 2 words.

The block height is encoded with a continuation bit and either 20 or 31 bits for a total of either 21 bits if height < 2^20 (~1 million) or 32 bits if above but lower than (2^31). Add the version bit and it comes exactly to either 2 or 3 words.

TxIndex is simply encoded as words.

Recap:
# first part
- version bit: always 0
- length indicator
    - if 0: use 2 words
    - if 1: use 3 words
- block height

# 2nd part - always 2 words
- txo index: 2 bits
- checksum: 20 bits

# remaining words
- tx index

For any reference tx below index 2048 before height 2^20, it is guaranteed to be 5 words. The format is pretty constant and doesn't rely on txcount or the number of txo in the reference tx. Moreover, generation and parsing is straight forward.

Without the ability to encode all outputs in the blockchain, the use of such mnemonic address is highly restricted. For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output

[hhanh00]

Without the ability to encode all outputs in the blockchain, the use of such mnemonic address is highly restricted. For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output

If your BIP wants to cover every tx output, I agree with you.
However, it was under my impression that the original proposal was about remembering an address that you previously set up.

An implementation in F#

Code:

let wordMask = (1L <<< 11) - 1L
let rec splitIntoWords i result = 
    match i with
    | 0L -> List.rev result
    | _ -> splitIntoWords (i >>> 11) ((i &&& wordMask) :: result)

let encodeTx (blockHeight: int64) (txIndex: int64) (txoIndex: int64) =
    assert(blockHeight < (1L <<< 31))
    let blockHeightLSW = blockHeight &&& ((1L <<< 9) - 1L)
    let blockHeightWords = splitIntoWords (blockHeight >>> 9) []
    let blockHeightEncoded = 
        ((if blockHeight >= (1L <<< 20) then 1L else 0L) <<< 9 ||| blockHeightLSW) :: blockHeightWords

    assert(txoIndex < 4L)
    let txoIndexEncoded = [txoIndex <<< 9; 0L]

    let txIndexEncoded = splitIntoWords txIndex []

    List.concat [blockHeightEncoded; txoIndexEncoded; txIndexEncoded]

[Nicolas Dorier]

However, it was under my impression that the original proposal was about remembering an address that you previously set up.

The goal is to express the bitcoin address of someone in 4 words, given that it is on the blockchain.
The BIP morphed into a general way of referencing any output. Which is compatible with the initial goal, and do not require a special "publishing step" for things already in the blockchain.

hhanh00, I like the fact that your proposal needs less words and is easier to implement though.

For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output

If people want to use mnemonic address to reference a txid, then I would say that the limitation of the txo count does not matter.
If the user knows that it is a transactionId, he will just ignore the 2 bits of txoindex.

Do you see another use case which might limit the usage ?
It is true that mostly what is published in the blockchain today use less that 4 txo, would we severly limit use cases by using a fixed 2 bit for txo index ?

[jl2012]

However, it was under my impression that the original proposal was about remembering an address that you previously set up.

The goal is to express the bitcoin address of someone in 4 words, given that it is on the blockchain.
The BIP morphed into a general way of referencing any output. Which is compatible with the initial goal, and do not require a special "publishing step" for things already in the blockchain.

hhanh00, I like the fact that your proposal needs less words and is easier to implement though.

For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output

If people want to use mnemonic address to reference a txid, then I would say that the limitation of the txo count does not matter.
If the user knows that it is a transactionId, he will just ignore the 2 bits of txoindex.

Do you see another use case which might limit the usage ?
It is true that mostly what is published in the blockchain today use less that 4 txo, would we severly limit use cases by using a fixed 2 bit for txo index ?

With checksum=20bits and blocks with =< 2048 txs, my proposal already guarantees a 5-word address for the first 4 outputs of any tx, same as hhanh00's. If your code gives you a 6-word address, there must be something wrong.

I can't see any reason not to allow people to encode the 5th output. With techniques like coinjoin, future transactions may have many outputs. Bitcoin is in its infancy and we won't know how people will use the blockchain in the future.
 

[Nicolas Dorier]

With checksum=20bits and blocks with =< 2048 txs, my proposal already guarantees a 5-word address for the first 4 outputs of any tx, same as hhanh00's. If your code gives you a 6-word address, there must be something wrong.

My code was wrong, I was using log(txcount;2) for encoding.

I can't see any reason not to allow people to encode the 5th output. With techniques like coinjoin, future transactions may have many outputs. Bitcoin is in its infancy and we won't know how people will use the blockchain in the future.

The only reason I see is the word size. Ease of implementing is not a big deal though, just a nice to have.
But I read too fast hhanh00 proposal. Only the "2 or 3 words" popped to my eyes. So yes, I still prefer yours, I agree that having a way to encode arbitrary output (not just 4 first) justify by far the added complexity.

[hhanh00]

With checksum=20bits and blocks with =< 2048 txs, my proposal already guarantees a 5-word address for the first 4 outputs of any tx, same as hhanh00's. If your code gives you a 6-word address, there must be something wrong.

I can't see any reason not to allow people to encode the 5th output. With techniques like coinjoin, future transactions may have many outputs. Bitcoin is in its infancy and we won't know how people will use the blockchain in the future.
 

In my case, the txIndex <= 2048 guarantees 5 words regardless of the number of tx in the block. Could be the same for yours but I haven't checked.

PS: You can try it out online at https://www.fpcomplete.com/user/hhanh00/adopted/txencoding

[Karartma1]

Actually I found a great way (but I don't suggest it. don't use it if you don't know what you're doing)
Here it is;
Private key's WIF wallet format starts with 5 and aditional 50 chars right?
So I've manually created this priv key: "5karartma1karatma2karartma3karartma4karartma5karart" (you got the logic) and this priv key refers to; 19Er7sHyYjXFankLwfv9Xxm5T3X4QxcbKY

Well, basically I'm saying; don't try to remember address, remember it's priv key

[dabura667]

Actually I found a great way (but I don't suggest it. don't use it if you don't know what you're doing)
Here it is;
Private key's WIF wallet format starts with 5 and aditional 50 chars right?
So I've manually created this priv key: "5karartma1karatma2karartma3karartma4karartma5karart" (you got the logic) and this priv key refers to; 19Er7sHyYjXFankLwfv9Xxm5T3X4QxcbKY

Well, basically I'm saying; don't try to remember address, remember it's priv key

5karartma1karatma2karartma3karartma4karartma5karart

This is an invalid WIF private key.

[CIYAM]

(you did notice the guy has an ad sig post and so is just posting to get his count up?)

This topic is about Bitcoin addresses not private keys.

[Karartma1]

Actually I found a great way (but I don't suggest it. don't use it if you don't know what you're doing)
Here it is;
Private key's WIF wallet format starts with 5 and aditional 50 chars right?
So I've manually created this priv key: "5karartma1karatma2karartma3karartma4karartma5karart" (you got the logic) and this priv key refers to; 19Er7sHyYjXFankLwfv9Xxm5T3X4QxcbKY

Well, basically I'm saying; don't try to remember address, remember it's priv key

5karartma1karatma2karartma3karartma4karartma5karart

This is an invalid WIF private key.

According to blockchain.info wallet, it's not. I imported it and wallet accepted it. But I didn't try to send btc yet.
edit: I've sent some btc to it; https://blockchain.info/tx/eb982663b019abc759b7b1853efda29786159ddc98013ed6058104f94d7e6563
if you like you can import it and clear the balance

(you did notice the guy has an ad sig post and so is just posting to get his count up?)

This topic is about Bitcoin addresses not private keys.

If you're thinking that, I'm "sig spammign" you should use the "Report to moderator" link under the message

Bitcoin addresses are generated according to private keys. You're tied up to private key to create a memorizable key.
Let's say you may try to create 1CIYAM1234567.... which is easy to remember. But you need lots of computer power to get kinda address.
Basically we may say you can't create such an address. (All bytes should be chosen by you).

If you can't create an address you like, Then why don't you just remember the priv key? "which you can clearly remember".