(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.
Topic: An easy way to remember a bitcoin address - page 3. (Read 15145 times)
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
(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.
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
(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
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.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.
PS: You can try it out online at https://www.fpcomplete.com/user/hhanh00/adopted/txencoding
Quote
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.Quote
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.
Quote
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.
Quote
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.
Quote
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.
Quote
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 ?
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]
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.
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
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.
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.
Wow this is useful, but too hard for me to remember.
Good to know tho,
Good to know tho,
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.
great you remembered your address. what about your private key? isn't that a bit more important?
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.
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.
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'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
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'll also copy your BIP + what we talked about on github.
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.
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)
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
It is SPV verifiable. In practice, an SPV client will ask a centralized service to resolve, and to provide the compact proof
People could do it when they are doing real transaction, so the marginal cost and harm is lowered
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
I'm understanding now how you want to encode y and z !
Good job, this is awesome !
Modifying my code...
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.
I'm understanding now how you want to encode y and z !
Good job, this is awesome !
Modifying my code...
Good job, this is awesome !
Modifying my code...
Quote
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
ymin = ceiling(log(txIndex + 1, 2)) = 0
zmin = 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 ymin, 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 zmin, 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
Jump to: