Topic: MinAddress : Now remember your addresses easily - page 7. (Read 6796 times)

The only way this could potentially be implemented is if you were to trust this company with your private keys. There are too many instances when this turned out to be a bad idea and people lost a lot of money.

It also forces you to reuse your address which is something that you generally should not do. Even if you do reuse addresses you sometimes may eventually use a new address for a specific transaction.

Yes this is a nice approach but it has 2 issues which I can think of :
> The MinAddress will not remain fixed and will keep on changing as new transactions happen to the address. This may be issue for some users but should be minor issue as previous MinAddress will still keep working.
> Currently I am taking blockchain information from external websites such as blockexplorer.com and this will drastically increase the number of blocks information I need to download for each address conversion, making the website very slow or not working for addresses with large number of input transactions, so this method can be implemented once I have a full bitcoin node running on my server.

I think it is kind of harsh to actually delete the private keys once the transaction is done.  I am one of the biggest opponents of address reuse you will find here on this forum but even I keep all my previous private keys just in case someone accidently sends BTC to one of my old addresses.  There is no privacy or security issue with keeping all your old private keys just in case - just never reuse those addresses for new transactions.  I just archive them.

This is why I think deterministic wallets are the greatest Bitcoin invention to date.  The Trezor or any deterministic wallet:

1) Uses a different receive address every time (but all old addresses are still valid and useable even if by mistake)
2) Uses a different change address every time
3) Can reconstruct every single receive and change address every used and calculate every address that will ever be used from one seed.

No need to muck about backing up, creating or deleting private keys.  They are all derived from the one seed.

You try to remember your address?  Wow, that is something I have never even dreamt of attempting.  On the other hand since Bitcoin addresses are (for all practical purposes) impossible to memorize that make them safer.  If you were to memorize 12e4f-1mine you might transpose or in some other way mess it up when you recite or write it down - possibly leading to disastrous results.

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.

I am not completely aware of firstbits algo but the main advantages of this approach will be:

> As more and more addresses are going to be used, firstbits algo will degrade more rapidly than this approach since firstbits compares current address to all the addresses before it. In this approach only the first part of the MinAddress will increase, which since is the hex code of the block index [linear increase] will increase slowly.

> The - seperator between the block number and address identifier can be changed to # to denote next version of the address which will use a base of 36 to reduce the size of the address further by 1/2 characters without changing any properties of MinAddress [this will be useful in future when the block count becomes very large]. Currently I went with the standard hex code as it is well known and can be easily converted to decimal through numerous online tools. The thinking was to keep the conversion as simple as possible so that users can trust it and easily use it.Also this reduces the MinAddress dependency on minaddress.info as any online hex to decimal converter can be used.

> The chance of getting incorrect address due to typo is very low as the two parts of MinAddress depend on each other and most likely if some character is changed in the MinAddress it will lead to invalid address unless you are very unlucky that the first part of new incorrect MinAddress represents a valid hex code of block index and the second part uniquely identifies an address in that block.

Regards

I actually did not expect something like this to be honest with you however, it does seem like an idea and a good one at that as long as it's proved to be quite safe. I for one am always forgetting my address so this would be ideal for me.

Once a minaddress is created and published it can be used from then on.  Sure other minaddresses that map to the same address can be found at a later time but the original can still be used.  You don't have to change it just because you can.  Even though I am totally against address reuse due to privacy and fungibility concerns, people that wish to could publish a minaddress and the published minaddress will be good forever.

This is exactly why you should not specify the encoding process - only specify the decoding process.

If I want max encoding speed then I can start at the most recent block and search backwards for the first (most recent) block to contain the address of interest.  If I want max compression I can search all blocks from 0 to the most recent.  I can do either, it is up to me as the encoder.  I can even write an encoder that gives the end user the option:  speed (but may not be the best result) or minimum length (but may take a while to encode).  Your method of using the first block to contain the address is slower than using the most recent block that contains the address but it give you one thing:  unique one-to-one mapping.

However, I am not sure that you need to have a unique  Bitcoin address to min address mapping.  Do you have a use case in mind that requires that everyone (all entities) that encodes a Bitcoin address must come up with the same encoding result?

Not sure why you limit yourself to the first block.  Seems like this would work on any block that has the address of interest.  In fact, just like any compression algorithm you should allow the compressor to spend more time during compression and possibly get more compression while decompression is still the same.  In fact for video compression algorithms like MPEG only the decompression algorithm is defined and the compression algorithm is left totally undefined and up to the implemetor.  In this case your entire idea can be defined as:


That way, if I want to, I can design a compressor that searches all the blocks and finds the one that gives me the shortest address.

Example I might find:  12fed-1myadd, 13eac-1myad  and 14e56-1m will all decode to the same address and pick the shortest one

It does look better than firstbits in the ways you describe, worse in readability, but that is the tradeoff.

It is basically a type of compressed version of the address for those addresses that are in the blockchain, has some amount of error checking unless you are unlucky, etc.

The reason Firstbits fell out of favor and is no longer used is because it is very dangerous.

For example if I give you the address 1BurtWEejbnKeBRsvcydJvsNztB1bXV5iQ it may be long and a pain in the ass to type in but if you make any mistakes it will not be accepted as valid because it has a built in checksum.

If I give you 1BurtW and you type 1Burt or 1BurtS by mistake you will end up sending the BTC to the wrong address.

I think the same thing applies to this proposal although the chances that a mistake leads to not finding a valid incorrect address will be slightly improved.

BTW I don't think blockchain.info will implement this algorithm since they already have removed the Firstbits algorithm due to safety concerns.

I do not understand/see the advantages of this proposal over the Firstbits algorithm.

Firstbits for my vanity address is 1BurtW (or 1burtw Firstbits is not case sensitive)

MinAddress for my vanity address would be something like XXXXX-1Bu

This whole concern about security is a bogus.  Both Firstbits and MinAddress are identical in this regard in that neither has an issue because both algorithms are based on finding the first transaction that sent BTC to the address, not from the address.

There are no security issues with sending BTC to an address - only spending from the same address multiple times.

However, Vanity addresses, Firstbits and MinAddress are all equally bad ideas because they encourage address reuse which reduces privacy for the entire Bitcoin system and could lead to the destruction of the fungible property of Bitcoin.

That's interesting! I once had a similar idea, but never got around to actually implement it. Also, I don't know if anyone has ever tried to implement that idea before, so my idea may very well be existing somewhere, and the fact that I don't know about it, renders it failed.

Seems like a somewhat useful feature.

Huh, that looks very interesting! There could of course be attack-vectors we don't see right now, but it seems like a great idea! The addresses aren't exactly easy to remember, but much shorter. I wonder whether there are caveats they haven't considered!

Thanks for the info, I was not aware, will contact them.

True - it would never be advised as "good practice" to re-use an address but for small amounts (which you are not worried about being traced) the convenience is attractive (especially in a situation where you don't have access to your wallet but need to receive a payment).

It is not as secure when you reuse addresses and it is not as anonymous.

Prior to spending from an address, iirc, you know the RIPEMD hash of the SHA256 hash.  Once you have sent from (spent the outputs) from the address, more information is revealed and you know the ECDSA public key. 

See

https://en.bitcoin.it/wiki/Address_reuse

:-)

I think you are right regarding firstbits, my assumption was based on this post https://bitcointalksearch.org/topic/bounty-fully-functional-open-source-code-for-firstbits-website-767512 which suggested use of database.

Getting blockchain.info into using this seems a LONG LONG AWAY

Please do - as much as the issues of address re-use are very real when you are *away from your computer* and need to receive BTC from someone it does makes things much easier if you can type in something like "1ciyam" into blockchain.info to find an address that can be used (and yes 1ciyam is my "firstbits" from way back).