An easy way to remember a bitcoin address

[hhanh00]

Right, I changed that to match your value but there is no need for it. Use tx output = 1 then. The point is that w gets incremented after y was chosen based on w=1.

See my BIP above. After increasing w, you should go back to step 3. In your example, you only go back to step 4

Well, I have a hard time seeing what you are implementing. I thought you meant to go to step 4 because if I have to go to step 3 the case isn't that useful.

If in step 3, y = y2 because you have enough bits left then you use them all. Next in step 4, there won't be any left. So unless utxo index = 0, you will have to increase w and go back to the beginning. What's the idea behind this case then?

This is different than what I think you meant in English.

In English:

If there is enough space, I'll use y1 bit to encode TxIndex. Otherwise, I'll use y2, given that it's enough to encode my interested tx. Otherwise, we need more words
If there is enough space after y is fixed, I'll use z1 bit to encode OutputIndex. Otherwise, I'll use z2, given that it's enough to encode my interested output. Otherwise, we need more words

[1714940390]

1714940390

[1714940390]

1714940390

[1714940390]

1714940390

[1714940390]

1714940390

[1714940390]

1714940390

[jl2012]

Right, I changed that to match your value but there is no need for it. Use tx output = 1 then. The point is that w gets incremented after y was chosen based on w=1.

See my BIP above. After increasing w, you should go back to step 3. In your example, you only go back to step 4

Well, I have a hard time seeing what you are implementing. I thought you meant to go to step 4 because if I have to go to step 3 the case isn't that useful.

If in step 3, y = y2 because you have enough bits left then you use them all. Next in step 4, there won't be any left. So unless utxo index = 0, you will have to increase w and go back to the beginning. What's the idea behind this case then?

This is different than what I think you meant in English.

In English:

If there is enough space, I'll use y1 bit to encode TxIndex. Otherwise, I'll use y2, given that it's enough to encode my interested tx. Otherwise, we need more words
If there is enough space after y is fixed, I'll use z1 bit to encode OutputIndex. Otherwise, I'll use z2, given that it's enough to encode my interested output. Otherwise, we need more words

By the bold sentence, I mean to re-evaluate the y with more words. It may not be clear enough.

Anyway, I try to redo your example:

Using the same values for `x=3`, `c=4` and the blockchain:
I want to encode a tx at block 5, index 3, output index = 1
Therefore, `y<sub>min</sub>=2` and `z<sub>min</sub>=1`
Now I go through the encoding steps.
- `w = ceil(3+2+1+4+1)/11 = 1`
- There are 40 tx, so `y1=6`
- `y2=11-1-3-4 = 3`
- `y=min(3,6)=3`
- `y<sub>min</sub>>y`? no. don't increase `w` but use 3 bits. txindex is encoded as `011`.

Next phase. Let's say there are 2 outputs in that tx.
- `z1=1`
- `z2=11-1-3-3-4 = 0`
- `z=min(1,0) = 0`
- `z<sub>min</sub>>z` ? yes. increase w. `w=2` and retry


- `y2=22-1-3-4 = 14`
- `y=min(14,6)=6`
- `y<sub>min</sub>>y`? no. don't increase `w` but use 6 bits. txindex is encoded as `000011`.


- `z2=22-1-3-6-4 = 8`
- `z=min(1,8)=1`
- `z<sub>min</sub>>z` ? no. use `z=1`. utxo index is encoded as `1`.
- checksum takes `22-1-3-6-1 = 11` bits

Result is
`1010000111x-xxxxxxxxxx0`

----------------
decode:

x=3, so it's block 101, i.e. block 5
Because it is block 5, we know y1=6; because it has 2 words, we know y2=14. Therefore, we know y=6. Therefore, txindex is 000011=3
Because it is index 3, we know z1=1; because it has 2 words, we know z2=8. Therefore, we know z=1. Therefore, outputindex is 1=1
The rest is 11 bit checksum + 1 bit version

[hhanh00]

Yeah, you end up using y1 and z1. The only time it's not the case is when txindex is small enough and utxo index = 0. If that's the intent, it's better to call it out explicitly and formulate a direct method (without loops). It'd be easier to prove that it's uniquely decodable. I think it's not worth the trouble and I'd discard that special case.

[FromLon]

Why not try same ways that used to generate private key with brain wallet?

[jl2012]

Yeah, you end up using y1 and z1. The only time it's not the case is when txindex is small enough and utxo index = 0. If that's the intent, it's better to call it out explicitly and formulate a direct method (without loops). It'd be easier to prove that it's uniquely decodable. I think it's not worth the trouble and I'd discard that special case.

I think there are few possible situations.

Using y1 and z1: having enough space to fully encode txindex and outputindex (i don't call it UTXO index because I don't care whether it is spent or not.)

Using y1 and z2: having enough space to fully encode txindex, but not enough for outputindex. Here z2 could be anything from 0 to infinity

Using y2 and z=0: having not enough space to fully encode txindex, and outputindex is 0

So yes, if y=y2 is used, z must be 0.

[Nikinger]

My (practical) approaches:

#1
Advantage: Works on every internet capable computer without any prior arrangements if you trust traditional block explorers like blockchain.info, otherwise additional trusted software setup is required. Very easy to memorize.
Disadvantage: You're likely going to fund criminals some satoshis.

Creating:
1. Just generate a bunch of random bitcoin addresses (a₁, a₂, ... a_n)
2. Send 0.00005460 to each a₁ ... a_n
3. Choose a brain wallet "b" with your full name (not an issue, bitcoiner who reuse don't care about privacy anyways) or something very easy to memorize. If address "b" has already transactions, use another phrase and repeat 3
4. Send a₁ ... a_n to b (brain wallet), don't care whether your satoshi are being flushed by the bots because you just do it once

Receiving bitcoins:
1. Enter your brain wallet phrase and navigate to "b". The inputs of the first transaction seen on blockchain are holding your secure generated a₁ ... a_n bitcoin addresses
2. Choose one from a₁ ... a_n
3. Receive

Sending bitcoins:
1. Open your client which contains the securely generated private keys of a₁ ... a_n
2. Send


#2

Using namecoin


Feel free to improve it if you think it's useful.

[Nicolas Dorier]

I implemented at : https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin/MnemonicReference.cs#L91
Basically there are 2 importants methods :

• Create, which create the mnemonic from the (Chain, Transaction, MerkleBlock, txOutIndex).
• Parse, which parse and verify the mnemonic from (Chain, Transaction,MerkleBlock,sentence).

Other Create/Parse methods are just additional overload that end up to the 2 main one.

The spec as is written is complicated to understand. I will reformulate that, however there is no incoherence when one parse and verify. (as you can see in my code, there is no "y0,y1,y2, zX")
I will send you some test vectors.

Works on every internet capable computer without any prior arrangements if you trust traditional block explorers like blockchain.info, otherwise additional trusted software setup is required. Very easy to memorize.

The goal of this BIP is to have untrusted block explorer resolving the "brain address" with a compact crypto proof, so it does not fit.

[hhanh00]

Yeah, you end up using y1 and z1. The only time it's not the case is when txindex is small enough and utxo index = 0. If that's the intent, it's better to call it out explicitly and formulate a direct method (without loops). It'd be easier to prove that it's uniquely decodable. I think it's not worth the trouble and I'd discard that special case.

I think there are few possible situations.

Using y1 and z1: having enough space to fully encode txindex and outputindex (i don't call it UTXO index because I don't care whether it is spent or not.)

Using y1 and z2: having enough space to fully encode txindex, but not enough for outputindex. Here z2 could be anything from 0 to infinity

Using y2 and z=0: having not enough space to fully encode txindex, and outputindex is 0

So yes, if y=y2 is used, z must be 0.

That makes sense. The 2nd case implies that outputindex is small enough - so we are not talking about a large range actually. With 3 different paths, you need to prove that there is no overlap. Basically, proving the unicity of the encoded value.

Edit: What I mean is this: http://en.wikipedia.org/wiki/Variable-length_code - Uniquely decodable codes

[HELP.org]

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

Other than the possibility of the random number generator not working correctly address reuse does not automatically "harm" anything.  It fully depends on the use case of the individual.  Many users realize a benefit of address reuse because of usability and transparency.  There is a general bias among the developers over what they perceive as "harm" concerning privacy issues.  Nobody should be "penalized" because they have a system that depends on address re-use if there are no other security issues surrounding that.  The developers should also not try to influence the code based on their personal biases over the wishes of many users.

[Nicolas Dorier]

Genesis mainnet : "near scrap six gauge"

Min checksum size : 20,
Actual checksum size : 22

Checksum component :
  block id : 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
  txIndex : 00000000
  txOutIndex : 00000000
  scriptPubKey : 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4ce f38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Calculated checksum : f254d8424d94a4a4ab37f199504207442d15d20e1481f844e50b3be0f809e6e4


rawAddress before checksum :
00000000 00000000 00000 (21 bits)

after checksum :
00000000 00000000 00000|111 00100111 00110000 010 (43 bits)

encryption key:
10010011 10011000 0010

final address : (encrypted|encryptionkey|version)

10010011 10011000 00101111 00|100111 00110000 010|0 (44 bits)

Via BIP39 : "near scrap six gauge"

[jl2012]

Yeah, you end up using y1 and z1. The only time it's not the case is when txindex is small enough and utxo index = 0. If that's the intent, it's better to call it out explicitly and formulate a direct method (without loops). It'd be easier to prove that it's uniquely decodable. I think it's not worth the trouble and I'd discard that special case.

I think there are few possible situations.

Using y1 and z1: having enough space to fully encode txindex and outputindex (i don't call it UTXO index because I don't care whether it is spent or not.)

Using y1 and z2: having enough space to fully encode txindex, but not enough for outputindex. Here z2 could be anything from 0 to infinity

Using y2 and z=0: having not enough space to fully encode txindex, and outputindex is 0

So yes, if y=y2 is used, z must be 0.

That makes sense. The 2nd case implies that outputindex is small enough - so we are not talking about a large range actually. With 3 different paths, you need to prove that there is no overlap. Basically, proving the unicity of the encoded value.

Edit: What I mean is this: http://en.wikipedia.org/wiki/Variable-length_code - Uniquely decodable codes

I'm not sure how to prove but it looks quite obvious.

y is a function of y1 and y2
y1 is a function of blockHeight
y2 is a function of w, x, c
Since blockHeight, w, x, c are all known value, there is only one possible value for y

Again, z is a function of z1 and z2
z1 is a function of blockHeight and txIndex
z2 is a function of w, x, y, c
If these values are all known, there is only one possible value for z
(Obviously, you can't determine z before y is determined)

Maybe someone can try to find a counter-example

[jl2012]

Genesis mainnet : "near scrap six gauge"

Min checksum size : 20,
Actual checksum size : 22

Checksum component :
  block id : 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
  txIndex : 00000000
  txOutIndex : 00000000
  scriptPubKey : 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4ce f38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Calculated checksum : f254d8424d94a4a4ab37f199504207442d15d20e1481f844e50b3be0f809e6e4


rawAddress before checksum :
00000000 00000000 00000 (21 bits)

after checksum :
00000000 00000000 00000|111 00100111 00110000 010 (43 bits)

encryption key:
10010011 10011000 0010

final address : (encrypted|encryptionkey|version)

10010011 10011000 00101111 00|100111 00110000 010|0 (44 bits)

Via BIP39 : "near scrap six gauge"

Assuming minimum checksum of 19 bit, the first output of the generation reward could be encoded by 4 words until this scheme overflow at block 8,388,607. An extra bonus for miner

[Nicolas Dorier]

Other example : I took txOutIndex = 1 of 4a85f6cc29aca334c1a78c5db74b492b741e67958aee59ff827c4c0862f4fbc1 (that's me !)

txOutIndex = 1,
txIndex = 597,
blockheight = 327535,

Min checksum size : 20,
Actual checksum size : 20 (geez at 1 bit I would stepped up 1 words)


Checksum component :
 blockId : d99211bfbc1efcdbf6787b54c2ce614adcf54049d1ce90170000000000000000
 txIndex : 55020000
 txOutIndex : 01000000
 scriptPubKey : 76a914356facdac5f5bcae995d13e667bb5864fd1e7d5988ac

Checksum : 34daf60a9d3bb907f8f9a36321ec36c9bfdaa1c8c178c73aa30d60c5b67e411c

RawAddress before checksum :  (10 bits for txIndex -967 tx-, 3 for txout -4 txout-)
01111011 01111111 10010|101 0101001|1 00 (34 bits)

After checksum :
01111011 01111111 10010|101 0101001|1 00|000111 00010000 010111 (54 bits)

Encryption key:
00011100 01000001 0111 (20 bits)

Final address :
01100111 00111110 11100100 10010111 00|000111 00010000 010111|0 (55 bits)

BIP39 : "grunt warm chair athlete alarm"

I think we should remove a few bit from checksum we are almost stepping up 6 words which start to be hard to remember.

[jl2012]

Other example : I took txOutIndex = 1 of 4a85f6cc29aca334c1a78c5db74b492b741e67958aee59ff827c4c0862f4fbc1 (that's me !)

txOutIndex = 1,
txIndex = 597,
blockheight = 327535,

Min checksum size : 20,
Actual checksum size : 20 (geez at 1 bit I would stepped up 1 words)


Checksum component :
 blockId : d99211bfbc1efcdbf6787b54c2ce614adcf54049d1ce90170000000000000000
 txIndex : 55020000
 txOutIndex : 01000000
 scriptPubKey : 76a914356facdac5f5bcae995d13e667bb5864fd1e7d5988ac

Checksum : 34daf60a9d3bb907f8f9a36321ec36c9bfdaa1c8c178c73aa30d60c5b67e411c

RawAddress before checksum :  (10 bits for txIndex -967 tx-, 3 for txout -4 txout-)
01111011 01111111 10010|101 0101001|1 00 (34 bits)

After checksum :
01111011 01111111 10010|101 0101001|1 00|000111 00010000 010111 (54 bits)

Encryption key:
00011100 01000001 0111 (20 bits)

Final address :
01100111 00111110 11100100 10010111 00|000111 00010000 010111|0 (55 bits)

BIP39 : "grunt warm chair athlete alarm"

I think we should remove a few bit from checksum we are almost stepping up 6 words which start to be hard to remember.

To avoid 6 words users should always "register" their address with the first output.

For the checksum bit issue I think we need comments from more experts. Changing to 19-bit may be a good idea as that will secure at least one 4-word address for each block. Miners may earn some service charge by putting their client's output in these prestigious positions.

[Nicolas Dorier]

RawAddress before checksum :  (10 bits for txIndex -967 tx-, 3 for txout -4 txout-)
01111011 01111111 10010|101 0101001|1 00 (34 bits)

I'm encoding it wrong...  4 should be "11" not "100", so I can squeeze out a bit.

To avoid 6 words users should always "register" their address with the first output.

For the checksum bit issue I think we need comments from more experts. Changing to 19-bit may be a good idea as that will secure at least one 4-word address for each block. Miners may earn some service charge by putting their client's output in these prestigious positions.

The size of the brain address depends on the number of transaction in the block and of the number of output in the block. It does not depends on the position.

Assuming minimum checksum of 19 bit, the first output of the generation reward could be encoded by 4 words until this scheme overflow at block 8,388,607. An extra bonus for miner

How so ? 19 + 21 + 1 = 41, if the miner wants such small addess he needs txIndex written on 3 bits, or 8 address in his blocks.

[jl2012]

RawAddress before checksum :  (10 bits for txIndex -967 tx-, 3 for txout -4 txout-)
01111011 01111111 10010|101 0101001|1 00 (34 bits)

I'm encoding it wrong...  4 should be "11" not "100", so I can squeeze out a bit.

To avoid 6 words users should always "register" their address with the first output.

For the checksum bit issue I think we need comments from more experts. Changing to 19-bit may be a good idea as that will secure at least one 4-word address for each block. Miners may earn some service charge by putting their client's output in these prestigious positions.

The size of the brain address depends on the number of transaction in the block and of the number of output in the block. It does not depends on the position.

Assuming minimum checksum of 19 bit, the first output of the generation reward could be encoded by 4 words until this scheme overflow at block 8,388,607. An extra bonus for miner

How so ? 19 + 21 + 1 = 41, if the miner wants such small addess he needs txIndex written on 3 bits, or 8 address in his blocks.

It does depend on the position. Try to encode the first output of this tx: https://blockchain.info/tx/bddc5f6c9fe232110d11235df76814ae3a0f9b7286bb991294310cae03384a4e

[Nicolas Dorier]

It does depend on the position. Try to encode the first output of this tx: https://blockchain.info/tx/bddc5f6c9fe232110d11235df76814ae3a0f9b7286bb991294310cae03384a4e

The raw address without checksum is
00110101 00001001 01010|000 00000000| 0000000
Calculated checksum is 26.

6 words. "arm voyage width veteran palm tattoo"

[hhanh00]

I'm not sure how to prove but it looks quite obvious.

y is a function of y1 and y2
y1 is a function of blockHeight
y2 is a function of w, x, c
Since blockHeight, w, x, c are all known value, there is only one possible value for y

Again, z is a function of z1 and z2
z1 is a function of blockHeight and txIndex
z2 is a function of w, x, y, c
If these values are all known, there is only one possible value for z
(Obviously, you can't determine z before y is determined)

Maybe someone can try to find a counter-example

I keep forgetting that it goes back to the beginning. Then there is no problem.

[Nicolas Dorier]

mh, while I was coding and you talked, I guess I did not see you found a way to encode txIndex and outputIndex better.
Trying to reread all of that. In my implementation I using ceil(log(txCount;2)

[jl2012]

It does depend on the position. Try to encode the first output of this tx: https://blockchain.info/tx/bddc5f6c9fe232110d11235df76814ae3a0f9b7286bb991294310cae03384a4e

The raw address without checksum is
00110101 00001001 01010|000 00000000| 0000000
Calculated checksum is 26.

6 words. "arm voyage width veteran palm tattoo"

There is something wrong with your code

It is txIndex 0 and outputIndex 0, so
y_min = ceiling(log(txIndex + 1, 2)) = 0
z_min = ceiling(log(outputIndex + 1, 2)) = 0

w = ceiling((x + ymin + zmin + c + 1)/11) = 4 (if c is 20)

y1 is a big number because there is a lot of txs, but y2 = 11w-1-x-c = 2, and it is not smaller than y_min, so y = 2;

z1 is a big number because there is a lot of outputs, but z2 = 11w-1-x-y-c = 0, and it is not smaller than z_min, so z=0;

so it could be done with 4 words, including 2 bit of txIndex, 0 bit of outputIndex, and 20 bits of checksum