Technically I would have a hard time even calling it "his money" or "his coins" since he has loaned them out to the exchange to do with them whatever they please.

What he owns is a bunch of (hopefully not empty) promises, not Bitcoins.

I think they are probably selling enough at this price.  If so why would they drop the price?  Of course I don't know their current actual sales volume so I could be wrong.

For sure you will have to wait for a drop in sales volume before there will be a drop in price.

Also, for everything it does for me I think it is well worth the money and would have even paid more.  So there is that.

Finally, I hope they keep the price as high at they possibly can in order to create a great company with a great R&D department so they can put out even more great products.

This.  The government is screwed if they really "need" to know this information.

Still wondering why you think they need it or even if they really think they need it.

This could not be farther from the truth.  This (and Firstbits) can easily be (are) implemented with out any reference at all to anyone's private keys.

This is true.  Address reuse is very bad for the long term viability of the entire Bitcoin experiment.

This is your fundamental assumption, that they need to know this.

Why do they need to know this?  Please explain.

The Trezor is $119.  It is very easy to use and the instructions tell you step by step how to set it up.  You can put your BTC in it and they will be safe.

If you do not want to shell out the $119 for the Trezor you can go with less security but more conveniences by using your phone.  Download Wallet32, write down the seed words and keep them safe, remember your PIN number (password) and you can use that.

There are other wallets for your phone however most of them must be backed up periodically.  Wallet32 never needs to be backed up.

Whatever you do, since you are a noob, get a deterministic wallet to avoid the hassle of backing up you private keys.

If your BTC are at an exchange then you do not even own or posses your BTC.

I want that to sink in.  All of your BTC have been loaned out!  What you currently "own" is a promise that someone you have never met, probably in a country far away from you, will give you the BTC you have loaned to them when/if you ever actually want it.

You are way more trusting with your hard earned money than I.  I no longer loan my money to anyone - not even a, or especially not even a bank.

There is even a solution for this using the Trezor or another deterministic wallet:  one password accesses a "reasonable" amount of BTC, they torture you and you give them that first password, they take the BTC and leave you, hopefully alive.  But unknown to them you have secured an even larger amount in the same wallet using password #2 !

I use a deterministic wallet on my phone.  I use Wallet32 but there are other deterministic wallets.  I wrote down the 24 seed words on a piece of paper and keep the paper in a very safe secure secret place.

Now, I have a password on my phone to access my wallet.  The wallet has cash in it.  But, better than a normal cash in wallet scenario if I lose my phone then all I have to do is buy another phone, install the Wallet32 application, enter the 24 words from my backup and every Bitcoin address I have every used, every change address I have ever used, every transaction I have ever done is recovered "from the cloud" and "put back" into my new phone.

So a deterministic Bitcoin wallet on your phone is better than carrying cash in your wallet!

Also, you never have to back it up.  All you have to do is keep a list of 24 words safe, secure and secret.

I think that is easy enough for just about anyone that is smart enough to own a smart phone.

Truer words are hard to find.

Same goes for the password to your encrypted wallet.dat file.

It is way less complicated to write down 24 random words on a piece of paper one time and keep it safe and secure than it is to constantly back up your wallet.dat file, remember to do it (every 50 or so spend transaction, every 100 for sure or you will be sorry), remember the encryption password for the wallet.dat file, etc.

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.

No.   Or, even more to the point, why?  The fact that there is absolutely no way to get the private keys from the Trezor is the entire point of the Trezor.

You back up (and keep secret) the seed words one time when you first initialize the Trezor.  There is then no need to backup the private keys as all private keys ever used by or will be used by the Trezor can be derived from the seed words.

Cool, eh?

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.

I wouldn't trust the "cloud" with pictures of my cat.  Why would I trust the "cloud" with my cash.