Yes, it's a bad idea to re-use address, but it is an absolutely stupid idea to discard a private key.
I would not call it stupid. I would call it very dedicated. He is dedicated to forcing people to stop reusing addresses, at least when dealing with him. If everyone did this there would be no address reuse. Sure some BTC might get lost along the way but pain is a very effective teacher. People would learn through the pain of losing BTC when they reused an address that reusing addresses is bad and wrong and they would stop doing it. 
Topic: MinAddress : Now remember your addresses easily - page 3. (Read 6796 times)
Why does the address 18uTXyQubfaYrkbQDdaXhzd2ALEY5YN77B not work?
It working now, due to large number of transactions in the block, it was hitting the max file size, I have updated it so that it works properly, sorry for inconvenience.
Regards
it is an absolutely stupid idea to discard a private key.
That is an opinion, not a fact.
My opinion differs from yours on that matter.
It's a safe option as far as the security issues are concerned.
Isn't re-using the same address not regarded as questionable?
i.e not the recommended best practice?
i.e not the recommended best practice?
Well it's not recommended as the best practice but I don't see anything dangerous in doing so. I think it's just a precautionary measure. I'm sure DannyHamilton will now tell me otherwise, though hehe.
You mean because of this ?
Do not re-use an address I've given you in the past. I use a new address for every transaction and I discard the private keys once I send/spend the bitcoins that I received at an address. Therefore it is very important that you get a new address from me and do not re-use an address to send bitcoins to me in the future if we ever engage in another transaction.
Yes, it's a bad idea to re-use address, but it is an absolutely stupid idea to discard a private key.
Hmmmmmm. No. Without the block number it will be firstbits or it won't work. For example without the block number find "1bu". Where is it?
Well , we can start with the first block and check if 1bu uniquely identifies an address in that block, if yes we take full address and move to next step, if no we move to the next block and so on till we find a full address or reach the latest block. Once we get full address we compare if the block where we found the full address is the first block where the address occurs in the blockchain, if true we have our final full address otherwise we goto first step.
Only thing is that the cost of calculation is very high unless some kind of database is used to speedup the process.
UPDATE: The encoding process will also required to be changed and instead of finding the min characters to make address unique in a block we will be required to find the min characters to make it unique among all receive addresses having 1st block upto the 1st block of the address in question. So similar to firstbits but smaller.
Thinking this through:
Let's say that the firstbits of a specific Bitcoin address is "1burtw", actual address is 1BurtW.... You propose that without specifying the block number you might be able to shorten it and still find the original address. OK, by the definition of firstbits there will exist within blocks before the very first occurance of the 1BurtW... Bitcoin address other addresses that start with 1burt because if there are no other addresses starting with 1burt then 1burt would be the firstbits by definition.
All of these other addresses will match 1burt
The question is: is there any case where we can use 1burt to find the proper 1burtw address? Well if there is a single unique occurance of 1burt
In fact the only time your algorithm can be used to shorten 1burtw to 1burt is if every single block which contains a 1burt
Since
To summarize: you will almost always be able to find a block that contains a single 1burt
Why smaller?
Isn't that what Firstbits is?
Isn't that what Firstbits is?
Agreed - I am a little confused now also what the real difference is (apart from perhaps trying to add an extra "check").
But this whole "create a (near) match in the next block in the hopes that they make a mistake in the block number" is a bit of a stretch, don't you agree?
I completely agree.
The encoding process will also required to be changed and instead of finding the min characters to make address unique in a block we will be required to find the min characters to make it unique among all receive addresses having 1st block upto the 1st block of the address in question. So similar to firstbits but smaller.
Why smaller?
Isn't that what Firstbits is?
I like my MinAddress, surprisingly easy to remember: 46044-1jfy
(back in one jiffy)
(back in one jiffy)
Hmmmmmm. No. Without the block number it will be firstbits or it won't work. For example without the block number find "1bu". Where is it?
Isn't this basically just "firstbits" (which seems to have disappeared a while back)?
It's very similar to firstbits but a little different. FWIW, firstbits is going to reappear shortly, I happen to be rewriting the software at the moment.
"firstbits" is harder to use, because in order to expand a firstbits address you need to search from the genesis block onwards until you find it.
With MinAddress the block number is in the address so there's much less searching required.
This is not true.With MinAddress the block number is in the address so there's much less searching required.
One to One Correspondence between MinAddress and Full Address implemented to prevent mistakes in MinAddress
In order to implement the one to one correspondence the decoder must verify the block in the MinAddress is the very first block to contain the Bitcoin address - just like firstbits. See:I think the one to one correspondence between MinAddress and Full Address can be used to make the MinAddress mistake proof. MinAddress can have 3 levels of checks:
>Block must exist
>Address must be uniquely present in block
>Block should be the first block where the address was used.
The three level of dependencies will ensure that if MinAddress is misspell it will lead to an error rather than some other address. Though this is not 100% full proof but it will make the chance of random change leading to a valid MinAddress very very low.
>Block must exist
>Address must be uniquely present in block
>Block should be the first block where the address was used.
The three level of dependencies will ensure that if MinAddress is misspell it will lead to an error rather than some other address. Though this is not 100% full proof but it will make the chance of random change leading to a valid MinAddress very very low.
I think I am not able to explain what I mean 
Let's see if we can clarify it a bit (I might not have correctly understood the algo).
If we have:
1ciyam:2adfd then that is currently an okay MinAddress (assuming such an address exists in that block)
but if we have:
1ciyam:2adfe then "couldn't this also be a correct MinAddress" (if a new 1ciyam address had appeared in the next block)?
Assuming that this assumption is correct then:
1ciyam:2adfeTeju would be invalid as the Teju would *not match with the new 1ciyam address*.
(whereas 1ciyam:2adfdTeju would be valid as Teju does match the checksum of the 1ciyam address in the previous block)
Now just as 1ciyam:2adfeTeju would be invalid similarly 1ciyam3htJ:2adfe would be invalid, both have extra 4 characters which needs to be compared. It does not matter if the extra characters are taken from beginning or end of address as only comparison is made, no checksum validation is made.(whereas 1ciyam:2adfdTeju would be valid as Teju does match the checksum of the 1ciyam address in the previous block)
Checksum validation can be used only if we want to check the validity of Full Address itself which is not required here as it is taken from blockchain. We only need to check mapping of minaddress to full address is correct or not and it depends on number of characters matched.
Nice project! Is there any other way to make it short? Re-using the address is not good, so any other way???
~~MZ~~
~~MZ~~
Let's be clear -
Re-using the address to receive multiple times is
Partial spending from an address is slightly less secure and can hurt anonymity and privacy. This is because you'll be leaving coins at an address where the full public key is known. "When you spend, spend the whole balance and don't use that address any longer" is the message here. [I like that message]
(Note, some feel keeping a few coins at an address used for every day spending and spending multiple times is fine because it is still quite secure but reduces privacy.)
Fixed up a bit.
Please read my rant up above in this very thread for more details:
https://bitcointalksearch.org/topic/m.8758673
Nice project! Is there any other way to make it short? Re-using the address is not good, so any other way???
~~MZ~~
~~MZ~~
Let's be clear -
Re-using the address to receive multiple times is completely ok.
Partial spending from an address is slightly less secure and can hurt anonymity. This is because you'll be leaving coins at an address where the full public key is known. "When you spend, spend the whole balance and don't use that address any longer" is the message here.
(Note, some feel keeping a few coins at an address used for every day spending and spending multiple times is fine because it is still quite secure.)
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
Nice project! Is there any other way to make it short? Re-using the address is not good, so any other way???
~~MZ~~
~~MZ~~
That will hold if we include checksum of MinAddress itself rather than checksum of Full Address, otherwise we are just adding extra characters which needs to be compared, so adding the extra characters from the beginning is same as adding extra characters form the end.
But as the last x characters of a BTC address *are* a checksum (for the rest of the address) then why not use that rather than create another checksum?
Because that checksum is for the Full-Address which is not required to be checked, a full address generated from MinAddress will always be correct as it is taken from blockchain. We need to check if the MinAddress is correct for which we will need the checksum of MinAddress.
I think I am not able to explain what I mean
Summary: The checksum property of the end characters of the Full address is only relevant for full address, from point of view of MinAddress, checksum characters of full address are equivalent to any other character of full address so there is no specific advantage of adding checksum characters to MinAddress.
The benefit of adding checksum characters is same as adding more characters from the beginning of address as the position of characters do not matter.
Isn't this basically just "firstbits" (which seems to have disappeared a while back)?
"firstbits" is harder to use, because in order to expand a firstbits address you need to search from the genesis block onwards until you find it.
With MinAddress the block number is in the address so there's much less searching required.
Minaddres.info takes the data from http://blockexplorer.com/ and blockexplorer is giving the below error [ http://blockexplorer.com/address/1QHzyM4yFDVdxQyijsFLVjzDJahZNfKQQb ] for this address because of which it is not working.
Code:
ERROR: Address ledger is extremely large. Contact me if you really need the data.
Since my message was removed from BurtW's thread (it really belonged here anyhow):
So, MinAddress does not work for addresses that have sent&received a large number of transactions?
That doesn't seem very user-friendly. MinAddress encourages people to re-use addresses (since you don't even have a MinAddress until after you've received at least one transaction at the address), but then breaks if they use the address too much.
You might want to look into building your own database of MinAddresses rather than relying on an API from BlockExplorer.com
Jump to: