I also want know how to remember a bitcoin address ? ? Any great was ? If so, Please teach me how?Thx !
Like this : https://github.com/NicolasDorier/BIP-MnemoReference/blob/master/bip-mnemo.mediawiki 
Topic: An easy way to remember a bitcoin address (Read 15145 times)
I also want know how to remember a bitcoin address ? ? Any great was ? If so, Please teach me how?Thx !
Quote
I think that there will not be easy ways to remember Bitcoin address.
There is.Quote
and honestly you don't need to remember it and shouldn't remember it
Why, then, everybody remember his own phone number ? Nobody gave me a response. I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
I think that there will not be easy ways to remember Bitcoin address and honestly you don't need to remember it and shouldn't remember it.
Just save it
I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
I don't know more about this but I think no ways is easy to remember it
Bitcoin address must be used as copycat as per bitcoin wiki. It means there is no need of remembering it. For checking whether using the correct (my address of some's address) I usually remember last 3 characters.
I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)
However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.
Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index
Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)
I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)
I don't know more about this but I think no ways is easy to remember it
Quote
Since I don't trust my memory most of the times , I would have to reuse the address lots of times to make this any helpful
I bet you memorize your phone number ? why ?Quote
Memorization incentive/ Personalization: You are forgetting that I have no motivation to memorize a random mnemonic
Well, people remember the 10 digits of their phone number, so 4 words seems not a big deal.Also how do you transfer would you transfer address over the phone ? how do you transfer it when you don't have your btc wallet with you ?
Quote
So this is only useful if I massively reuse my address, say for next 6 months , say I keep giving same address to anyone I speak to . This definitely is not encouraged as everyone pointed out already.
This has been responded, such address can point on a OP_RETURN that have a payment address (BIP70) or a stealth address, which would fix address reuse problems.
Took time to read through most of the comments. This looks quite promising theoretically , specially how you have avoided user typing wrong Mnemonic code
One thing , I was thinking is about the practical application of this:
So this is only useful if I massively reuse my address, say for next 6 months , say I keep giving same address to anyone I speak to . This definitely is not encouraged as everyone pointed out already.
Are there any other applications of this ?
One thing , I was thinking is about the practical application of this:
- Crowdfunding address: I was hoping it could be used here, but unfortunately I think crowdfunding funding websites would rather prefer vanity addresses than this. Say I have a website called bitcoinkite , I would prefer something like KiteybXcBLb1EdJHzULptUws4haRwamuS rather than "arm voyage width veteran palm tattoo" which would be totally unrelated to my product
- Personal exchange of address: This is when I send someone my address and tell him to transfer money to it. So in this case I would probably copy paste the address and send it to that person. In this case I would use mnemonic only if:Quotecost of remembering the Mnemonic < Number of times I reuse this address * cost of copy/pasting the addressSince I don't trust my memory most of the times , I would have to reuse the address lots of times to make this any helpful
- Memorization incentive/ Personalization: You are forgetting that I have no motivation to memorize a random mnemonic . This is the reason people choose passwords that are more personal. So if the Mnemonic is my favourite song , then I will remember it. Already people are having hard time remembering the ten different password. It doesn't give me any incentive memorization a totally unrelated Mnemonic. I would rather copy paste my bitcoin address, since I would anyway use not use it more than 5-6 times. Note, that we cannot use a phone number analogy here. Inspite of random digits people will force to remember phone number, since they know that they are stuck with it for next year or so.
So this is only useful if I massively reuse my address, say for next 6 months , say I keep giving same address to anyone I speak to . This definitely is not encouraged as everyone pointed out already.
Are there any other applications of this ?
I don't understand why we cannot use namecoin for this, instead of polluting bitcoin blockchain with unecessary bytes and adding OP_RETURN.
Also if suppose you want to change the name with which you refer the address with , you can do that as well on namecoin . And it will take care of name conflicts as well.
If you are concerned about centralization , you can query a few namecoin nodes or run your own node.
Is there a major reason for not using namecoin ?
Also if suppose you want to change the name with which you refer the address with , you can do that as well on namecoin . And it will take care of name conflicts as well.
If you are concerned about centralization , you can query a few namecoin nodes or run your own node.
Is there a major reason for not using namecoin ?
As CIYAM said, implementing a wallet only for bitcoin is complicated enough, having two blockchain is overkill for what I want to do with the BIP.
I also don't want the hassle to host nodes for several blockchain on mobile devices, this is development overkill.
What I am proposing does not require any alt chain, and would works fine with current SPV wallets. (no much dev)
I would very much doubt that the developers of any major Bitcoin wallets are going to include support for Namecoin anytime in the near future to accomplish what this topic is about so proposing its use here doesn't seem to make much sense.
I don't understand why we cannot use namecoin for this, instead of polluting bitcoin blockchain with unecessary bytes and adding OP_RETURN.
Also if suppose you want to change the name with which you refer the address with , you can do that as well on namecoin . And it will take care of name conflicts as well.
If you are concerned about centralization , you can query a few namecoin nodes or run your own node.
Is there a major reason for not using namecoin ?
Also if suppose you want to change the name with which you refer the address with , you can do that as well on namecoin . And it will take care of name conflicts as well.
If you are concerned about centralization , you can query a few namecoin nodes or run your own node.
Is there a major reason for not using namecoin ?
I think someone should start a service where someone can store their bitcoin address online
and get a personalized short link that they can open anywhere and get the address they stored there
and get a personalized short link that they can open anywhere and get the address they stored there
copied your bip here : https://github.com/NicolasDorier/BIP-MnemoReference/blob/master/bip-mnemo.mediawiki
I can give you git access if you need to.
I'm implementing it on NBitcoin, it seems to work.
I'm testing more deeply, and try to generate some test vectors.
I rephrased your spec to be more easy to understand and implement.
I also based my implementation on the spec notation, so it is easy to implement on other language by copying my code.
Tell me what you think about it.
I can give you git access if you need to.
I'm implementing it on NBitcoin, it seems to work.
I'm testing more deeply, and try to generate some test vectors.
I rephrased your spec to be more easy to understand and implement.
I also based my implementation on the spec notation, so it is easy to implement on other language by copying my code.
Tell me what you think about it.
1. Do we want the ability to encode all outputs in the blockchain, or just some of it (say, only the first 4 outputs in all txs)? hhanh00's scheme is easier to implement as it only encodes the first 4 outputs in a tx. My scheme is more complex and the length of all components are variable.
I guess the "target audience" is what matters (for me 4 outputs would be fine as I would be using it for "cold storage" which would have generally only 1 output anyway).
My scheme allows users to choose. If you want the shortest possible address, always put your interested scriptPubKey as the first output. If you have some special reasons (e.g. when using smart property which the order of outputs is material), you can use my scheme to refer to any outputs on the blockchain.
2. hhanh00's address is shorter than mine in some case, while the opposite in some other case.
I think 5 "words" is fine (whichever approach).
Basically, 5 words is guaranteed in most cases for both proposal if the 1MB block space is not increased.
3. How many bits of checksum is needed? I proposed 20bits so the error tolerance is about 1 in a million. Should we use more? Could we squeeze a few bits for other purpose? (Satoshi used 32 bits in standard bitcoin address.)
As many as possible without adding an extra word.
You are begging the question: in my scheme, the only way to ensure no extra word is to use 0-bit checksum.
So go back to the question, how many bits of checksum is needed?
5. Do we want miner to have the ability to mine a vanity address? My scheme disallows it in response to gmaxwell's comments (see first page). The other scheme allows miners to mine vanity address.
I am not quite sure of the implications of this - but it would be better to probably not allow it.
The implication is a miner may try to fill up a block with garbage in order to grab a vanity address. It also offers extra incentive to orphan other people's block.
There are many dimensions:
Thanks for the summary:
1. Do we want the ability to encode all outputs in the blockchain, or just some of it (say, only the first 4 outputs in all txs)? hhanh00's scheme is easier to implement as it only encodes the first 4 outputs in a tx. My scheme is more complex and the length of all components are variable.
I guess the "target audience" is what matters (for me 4 outputs would be fine as I would be using it for "cold storage" which would have generally only 1 output anyway).
2. hhanh00's address is shorter than mine in some case, while the opposite in some other case.
I think 5 "words" is fine (whichever approach).
3. How many bits of checksum is needed? I proposed 20bits so the error tolerance is about 1 in a million. Should we use more? Could we squeeze a few bits for other purpose? (Satoshi used 32 bits in standard bitcoin address.)
As many as possible without adding an extra word.
4. Do we need a version bit (like in standard bitcoin address)? It will occupy 1 bit (which could be otherwise used for other purpose. In order to keep the address short, every bit is very valuable) but it makes potential future upgrade easier. Otherwise, future upgrade will need to use 2048 completely different words, or people have to denote the version of the address externally (e.g. using a URL like header)
A version bit seems reasonable to me.
5. Do we want miner to have the ability to mine a vanity address? My scheme disallows it in response to gmaxwell's comments (see first page). The other scheme allows miners to mine vanity address.
I am not quite sure of the implications of this - but it would be better to probably not allow it.
6. Do we want the addresses look like random (i.e. outputs/txs close to each other will have statistically unrelated addresses) or not?
If the point is to help someone remember the address then random is better so they don't get confused IMO.
People are always free to propose different ideas. I just want more people to comment and criticize.
To be honest it is now confusing exactly what is on offer (it got rather technical and I didn't have enough time to delve into it).
Perhaps a simple summary of the two options could be provided?
There are many dimensions:
1. Do we want the ability to encode all outputs in the blockchain, or just some of it (say, only the first 4 outputs in all txs)? hhanh00's scheme is easier to implement as it only encodes the first 4 outputs in a tx. My scheme is more complex and the length of all components are variable.
2. hhanh00's address is shorter than mine in some case, while the opposite in some other case.
3. How many bits of checksum is needed? I proposed 20bits so the error tolerance is about 1 in a million. Should we use more? Could we squeeze a few bits for other purpose? (Satoshi used 32 bits in standard bitcoin address.)
4. Do we need a version bit (like in standard bitcoin address)? It will occupy 1 bit (which could be otherwise used for other purpose. In order to keep the address short, every bit is very valuable) but it makes potential future upgrade easier. Otherwise, future upgrade will need to use 2048 completely different words, or people have to denote the version of the address externally (e.g. using a URL like header)
5. Do we want miner to have the ability to mine a vanity address? My scheme disallows it in response to gmaxwell's comments (see first page). The other scheme allows miners to mine vanity address.
6. Do we want the addresses look like random (i.e. outputs/txs close to each other will have statistically unrelated addresses) or not?
People are always free to propose different ideas. I just want more people to comment and criticize.
To be honest it is now confusing exactly what is on offer (it got rather technical and I didn't have enough time to delve into it).
Perhaps a simple summary of the two options could be provided?
I thought you guys were headed towards a consensus - but now we have two ideas?
People are always free to propose different ideas. I just want more people to comment and criticize.
Quote
bitcoin:load-road-road-load-road
litecoin:road-load-load-road-load
and in the future, after a significant hardfork, we have
bitcoin2:load-road-road-load-road, which will be interpreted differently
Not sure if this is a good way to go
litecoin:road-load-load-road-load
and in the future, after a significant hardfork, we have
bitcoin2:load-road-road-load-road, which will be interpreted differently
Not sure if this is a good way to go
I don't think it is useful at this point to format the mnemonic into an url.
If there is an url, the user is mostly clicking on that or put it into QR code, and in both case would not need a mnemonic.
It is not about URL. If there will be any update with this scheme, without a version bit, future users has to tell people whether this is a version 1 or version 2 address. Otherwise, birthday collision is very likely: an address (with or without checksum) being perfectly legal in different schemes
I thought you guys were headed towards a consensus - but now we have two ideas?
Jump to: