Bitcoin Forum

Hi,

MinAddress is condensed form of your address with the following features:
Next generation address which is easy to remember and type
Case insensitive
Permanent and secure
Easy to verify

MinAddress uses the following concept making it permanent, secure and easy to verify:

Full address to Min-Address Conversion:
#Take the full address and find the block in which the first transaction to address occurs.The block number is the converted to hex-code and forms the first part of Min-Address.
#Get all the receiving addresses in the block and do a case insensitive comparison to find the minimum number of initial characters which uniquely identify the address, this forms the second part of the Min-Address.

Min-Address to Full address Conversion:
#Take the First part of the Min-Address and convert it to decimal, this is the block number.
#Get all the receiving addresses in the block and do a case insensitive comparison to find full address which uniquely matches the second part of the Min-Address.

After every conversion you will get a verify link which can be used to verify your Min-Address/Full Address.

Example: Bitcoin Full Address: 17ykeSBpC8MrJr4GrizNUYz6DEnwQ598fQ
             Min-Address: 3fa5b-17yk
             Verify Link: http://blockexplorer.com/block/00000000000000099f086871f03d03f6639b89799cb6d452a9f34c5764f83dcb

Currently, we support:
Bitcoin addresses, Litecoin addresses and Dogecoin addresses.

Hope this is helpful.

Please donate to this project so that we can continue the support and development.
Bitcoin : 1PPJ5x74KEo9euEiSJKxyBUfHMRQrXKL1f
Litecoin : LNz69V1Ls4cwML4YpCanoM4PAHREQbFfV7
Dogecoin : DJvvwFHgFX9qypeEYWsuscdWodtanLCN6X

For more information please visit www.minaddress.info

Regards

IMPORTANT

It seems that many people confuse this with some kind of centralized system where I can later change the Min-Address. To clarify the information is completely based on blockchain and in no way the Min-Address can be modified. Also even if MinAddress.info is down, the user can easily convert the Min-Address to Full-Address. Suppose you have a min address 3fa5b-17yk which you want to convert to full address. Just use any online tool to convert the first part "3fa5b" to decimal from hex which will be 260699. Now go to block 260699 in any bitcoin blockchain like blockexplorer.com and search for "17yk" .You will get your complete address 17ykeSBpC8MrJr4GrizNUYz6DEnwQ598fQ.

Minaddress.info just automates the conversion process[which can be done manually as shown above] and has no control over the final Min-address.

MinAddress Update [14-9-14]:

• Support for formats 17lv:46e02 as well as 46e02-17lv
• Added blockchain.info as backup data source along with blockexplorer.com to provide better service
• Added AddressMap which can be used for quick visual verification of addresses
• One to One Correspondence between MinAddress and Full Address implemented to prevent mistakes in MinAddress

I think something like this would be a great and useful idea, but it would be difficult for me to trust fully without it being proven safe 100% by others. Not saying yours isn't but I'd need to look into it more and have vouches from respected people.

It requires you to re-use the address. Other than that is appears to be "safe".

Isn't re-using the same address not regarded as questionable?
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.

Isn't this basically just "firstbits" (which seems to have disappeared a while back)?

Oh - I had thought that firstbits was just an *algo* that was based upon the blockchain also (happy to be corrected if you can show me a link). In any case firstbits doesn't work now so nice to see the idea appear again (now let's see if you can talk blockchain.info into using it).

reimplemented oddress  ;D
https://bitcointalk.org/index.php?topic=455303.0

They did use to use firstbits (not sure if they stopped because firstbits stopped or if they just decided that they didn't like the idea).

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).

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

:-)

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).

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!

Seems like a somewhat useful feature.

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.

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.

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

He was referencing several posts of mine.

Here is an example:



I include that paragraph (or one like it) whenever I provide anyone with a bitcoin address to send bitcoins to me.

Good point.  Carry on and good luck.

I actually like this idea, but the shortened address is still not very easy to remember. If I have to copy it down or send it to someone via email, I could just use the full address.

The whole point of a long address was increased security. Would you really be willing to exchange it for convenience?

There is no security difference between a full Bitcoin address and the proposed MinAddress.  MinAddress is just a way to look up the full Bitcoin address in the blockchain so, same amount of security as the Bitcoin address itself.

There is just a small loss of error checking of the address itself but if you are careful then that is minor.

You would likely have a lot of people scamming by creating addresses that are similar to popular addresses to send money to. It would also make it easy for people to fall for this scam because they would be more likely to look up an address with this service rather then look it up and verify it independently

Unfortunately, if you got someone "shortening" or "rerouting" your addresses, then it should have a similar effect to what the bit.ly URL shortening services has on your link, that is, their piece of the $$$

Please correct me if I'm misunderstood, is this a security flaw?

This would be very difficult to do.

You would need to predict ahead of time which addresses would become popular before they become popular. You would need to see the address as soon as it is used in a transaction and before that transaction is confirmed. Then you would need to create a vanity address that is similar to that address before the transaction confirms.  You would then need to send a transaction to your newly created vanity address and your transaction confirmed in the exact same block as the transaction with the address that you are trying to spoof.

Even if you manage to do all that, the user of the MinAddress could create a new transaction, get it confirmed in a new block, and use the new block as the first part of his MinAddress.  This means that you'd need to monitor every address that you ever want to try to copy and make sure that every time any of those addresses receives a transaction, you get a transaction to your spoof address confirmed in the same block.
 


Since the creation of the address is an open and publicly known protocol, it would be possible for many services to all create identical addresses.  Furthermore, it would be possible for wallet software to create MinAddresses if they become popular.  As such, you wouldn't be forced to rely on any particular service to be trustworthy.

Since the protocol for creating a MinAddress is open and publicly known, competition would prevent any particular service from significantly overcharging.  MinAddresses could even be built into wallets if they become popular.

Personally, I don't like the idea of re-using a bitcoin address, at all, ever.  Therefore, I find that the MinAddress would be useless to me, and would interfere with the fungibility of bitcoin if it becomes popular.  As such, I hope this idea fails.  However, if it does fail it won't be because of a service charging to much for it or because of security issues.


You're misunderstood.


No.

This is something I would agree with and for simple "tips" or "donations" it is always going to be easier to have an address link in your sig vs asking people to contact you (or use a website) in order to get a never used before address from you.

BTW - what would my 1ciyam firstbits address look like with this scheme?

I think 1ciyam-2adfd would probably "look nicer" myself. :)

that way I can change my "sig" to look like this:
1ciyam3htJit1feGa26p2wQ4aw6KFTejU-2adfd

Nicer but @ might get confused with email - perhaps $ instead? :)

(or if $ is going to be controversial then ! or : would be okay)

1ciyam3htJit1feGa26p2wQ4aw6KFTejU!2adfd
1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfd

Let me know when it is added and I'll even change the address in my sig to include it. :)

1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfd

I just don't see the benefit of this requirement.  Perhaps I'm overlooking something, but that seems overly restrictive.  I prefer BurtW's recommendation that the rules dictate how to get a Bitcoin address from a MinAddress, and not the other way around.


I don't see the analogy.  I'm not sure what you are trying to say here.


My statement has nothing to do with "large bitcoin transactions on a regular basis".  I stated my opinion.  Clearly you don't like my opinion, but I never expected you to like it.  If you did, you wouldn't have created this MinAddress in the first place.


You are mistaken. Address re-use significantly reduces both privacy and fungibility.


???

Who said anything about losing bitcoins.  The issue is lost privacy, and lost fungibility.  Not lost bitcoins.

That being said, there are people that have made false assumptions about "sending addresses" and attempted to re-use those to send bitcoins to someone that they previously received bitcoins from. This has resulted in lost bitcoins.

Furthermore, if anyone ever re-uses an address that they used in the past to send bitcoins to me, the bitcoins WILL be lost, since I delete the private keys after I spend the bitcoins that were received at an address.

For that matter, now that I think about it, I have seen people report that they accidentally re-used an address from an old wallet that they no longer had and wanted to know if there was a way to recover the bitcoins. I guess it happens after all.


Yes, but I don't know of a single one that lost bitcoins due to a typo. Every one of them that I know about lost bitcoins due to either:

• Using copy and paste and not realizing that they had the wrong address in their clipboard
• Being given the wrong bitcoin address by the receiver
• Misunderstanding which address they were supposed to use when presented with multiple addresses to choose from

MinAddresses will not solve any of these three issues.  It might make it a bit easier to tell someone an address vocally, and they may be able to write it down with pencil and paper a bit faster, but if they are given the wrong address, or choose the wrong address from multiple choices, or copy and paste an address that is sent to them, then they will be just as likely to have a problem with MinAddress as they would with traditional addresses.

@DannyHamilton

You seem to have missed the "tip address" argument to "address re-use" - if people had to go to a website in order to get a unique address to "send a tip" then very few people would ever actually get a tip (and I have had a few sent to my 1ciyam address over the years).

Another variation of the "tip address" is the "billboard sign" one (yes you could also put a QR code there but if the person doesn't have a camera then with this they can still "jot down the address" to find the full address later).

Not bad. Will try it..

1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfd

Hmm... you could put part or all of the normal address checksum in the MinAddress like the above.

The issues I've highlighted are issues for small transactions like tips/donations etc.


Yes.


Yes, we are in agreement that the issues have nothing to do with loss of security.


I prefer to discourage re-use of bitcoins.  If I post my private keys, then the threat of the permanent loss of bitcoins from the economy is reduced.


This does not result in a valid address.  Unlike your MinAddress, bitcoins have a checksum built in to the address.  It is extremely difficult to make a typo and end up with a valid address.


A random change in a Bitcoin Address has a much lower chance of resulting in a valid address than a random change in a MinAddress.  The problem is, for example, when someone gives out an address and then later realizes that they took the address from the "sent transactions" section of their wallet instead of the "receive" section.

Seriously? Do you think that someone needs to go to someone's website or contact them in order to just give a tip?

I can understand if you are offering a "service" that it would make sense but if you are just tipping someone for a great post then I do not see the harm at all.

You are misunderstanding the privacy/fungibility issue especially with respect to static donation addresses or published static addresses of any kind.  It is not the privacy of the entity posting the static address that is the issue - by posting a static address easily tied to your identity you obviously don't care about your own personal financial privacy.  The issue at hand is the privacy of everyone who ever gives a donation to the easily identified transaction node you have created.  Now realize that since your easily identified node can be used to possibly compromise the identities of every other node that ever sends you a donation then by extrapolation every easily identifiable static transaction node reduces the overall privacy of the entire Bitcoin ecosystem.

Now, while this system wide loss of privacy is an issue in and of itself, it is the long term threat to the very fungibility of Bitcoin posed by this system wide reduction in privacy that most concerns me an others here.
  
Proper education should lead to the total demise of static addresses because properly educated people will never send BTC to any static addresses, thus making the publishing of static addresses of any kind obsolete.  In other words everyone who cares about the long term fungibility and therefore viability of this grand experiment should demand a new address for every transaction, every time.

All donation addresses should be, as you said, implemented by a widget that displays a new address every time it is hit.  All periodic payments (including and especially mining payouts) should be handled by deterministic payment address generation.  All Bitcoin users should demand a new address for every transaction.  In order to compensate for the sloppy privacy policies of others please use coinjoin or other coin mixing transactions when you must send to any static address.

[Edit:  Thinking about this donation address issue some more I think a possible solution would be to generate an xpriv/xpub key pair, create a widget based on the xpub key that displays the first Bitcoin address for the first public key in the sequence until that address receives a donation, then start displaying the Bitcoin address of the next public key in the xpub sequence, etc.  This way a new Bitcoin address is published until it gets used and once it gets used it gets retired.  The entity receiving the donations can then generate the entire private key sequence from the corresponding xpriv key when they want to spend the coins.  In the worst case a very small number of transactions would get sent to one address before the widget changes the donation address on the next page visit.]

End of PSA/rant, now back to our regularly scheduled thread...

Exactly. Address reuse = privacy leak!

Your "edit" idea perhaps makes sense for the "web site widget" but won't work on a "billboard" (unless it is a digital "smart billboard" I guess).

Personally I would create a small wallet for such "tips" or use "coin control" to get rid of some small amount (perhaps another tip I got myself) but of course I get your point that for most people this would be "inconvenient" or "too difficult".

I think that both your and Danny's point with this is really that "publishing an address" is a bad idea full stop (as even if that address "changes with each tip/donation" someone can just monitor the website to keep a track of all such addresses that were given out taking you back to square #1).

In favour of the "short address" idea I have had at least one or two experiences in "buying BTC for cash" when "I did not have my computer handy" - in that case having either a "known public address" (or being able to find one easily with a "short name") was actually "the only way I was going to be able do the deal".

Vanity address, firstbits address and minaddress all in one.  Very sharp looking!

Thanks - note that it is somewhat a "marketing issue" also (so I was trying to make it look nice while still working with good old copy and paste - including touch screens).

BTW:  a simple change in algorithm would make these addresses almost as good as full addresses with respect to typographical error checking.  Just include part of the checksum area of the full address. In other words instead of just looking at the front of the address for the unique string look at both ends when calculating the unique matching pattern to publish.  Because this proposed minaddress now includes part of the checksum area the probability of a typo mapping to a valid address is even less.  So for 1ciyam3htJit1feGa26p2wQ4aw6KFTejU we might get something like 2adfd-1c-U as the unique minaddress.

Think you must have missed this:


Already thunk it!

But glad to see you agree with my suggestion. :)

Isnt this the same as vanity addresses or im missing something?

It is how "to find" said vanity address that this addresses (not creating it).

I did not miss it, you did not specify a syntax.  The syntax in your reverse order case would need to be something like:

1c:ju:2adfd  (head:tail:block) or in the original syntax 2adfd-1c-ju (block-head-tail)

I don't think it could work like that (otherwise you'd break copy and paste per my sig example) - I think that the symbol (being a : or something else) itself would imply that the 4 characters *before* the : are the last 4 from the address.

so: 1ciyamTeju:2adfd

(but is now starting to not be so "minimal")

Also I guess you could *repeat* the checksum characters like this:

1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfdTejU

This is a major problem. However I would think that this would appeal to people who are not as concerned about privacy (for example a hotdog vendor accepting bitcoin for sales, or a charity).

I don't think this would appeal to the "average" user of bitcoin. 

If vendors aren't concerned about privacy, they can always use fiat.

I've always used a URL shortener such as Google's:

The address 17ykeSBpC8MrJr4GrizNUYz6DEnwQ598fQ

is captured by  http://goo.gl/ywROqN (http://goo.gl/ywROqN)  (this looks up that address on Blockchain)

So I need only memorize ywROqN

(Small spelling errors will be caught by Google and it's also very private unless you choose to publish it)

I think the issue that was been raised was that of a "typo".

If one types 1ciyam:2adfe rather than 1ciyam:2adfd then presumably you could end up with an incorrect address.

If all or part of the checksum was included then 1ciyam:2adfdeJu would be "invalid" (unless it was actually the same address).

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?

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)

EDIT: Or maybe there simply can't be two 1ciyam's in which case there is no such issue (part of the problem is that I am assuming 1ciyam rather than 1ci as I want to keep the "vanity address" prefix but maybe this is also *irrelevant*).

In a way the checksum characters are "more important" than the rest of the characters since they contain the checksum of all the other characters.  But if you are not comparing the entire checksum area then there could be a false positive there also so, it would be nice to use them but if you don't want to then that is fine also.

Here are the two basic formats:

[hex block number]-[min head match][optionally more match]
[min head match][optionally more match]:[hex block number]

You could extend these formats for the paranoid if you wanted to:

[hex block number]-[min head match][optionally more match][-optional tail match]
[min head match][optionally more match]:[hex block number][:optional tail match]

Thanks @BurtW - although I am sure this whole idea *grates* on you (as I guess it does with many others) I think it is valuable to at least work out the best practice if one is going to "publish an address" (especially on a "billboard" or the like).

Aha - *but* it may be possible using vanitygen to come up with another address starting with 1ciyam3htJ in the next block (depending upon what GPU power you have with regards to vanitygen). To do the same with the "checksum", however, would be *much, much harder* (as you'd have to try many more addresses to get such a match).

To create a match for the entire checksum is almost equivalent to creating the entire address so - almost impossible.

To create a match for the very last character of the checksum = about the same as one more character in the original match, just a bit harder.

To create a match for the last two characters of the checksum harder than just matching two extra characters in the original match although I am finding it hard to calculate exactly how much harder.

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?

Maybe so - but we are talking about people "typing in from what they read" (so mistakes are bound to happen).

The fact that if you create any bad "brainwallet" it will have its funds exhausted within minutes suggests that people are happy to run such bots in the hope of finding BTC (e.g. the "horse staple battery" address).

This is a bit different because it is impossible to predict which addresses will become popular whereas password prediction is pretty easy.

As an example if your address suddenly became very popular with dozens of BTC donations per day then someone might want to try to get the near misses BUT they can't get the near misses in the lower digits because they cannot put anything into the blockchain retroactively between your block and today.

They could, of course, try for the misses in the appropriate and possible upper digits of the block number.  

Multiple digit changes may not be worth the effort.  

The block number typos are the only ones they can even try to do since they cannot go back to your original block to try for typos in the match portion.

Let me offer a completely different disadvantage of this scheme:

This invention makes bitcoins overall less appealing to big group of people while offering pretty much nothing in return.

We currently have a lot of tech wizards using bitcoin who like being in some kind of elite group because they have spent thousands of hours studying all the nooks and crannies of bitcoin and it makes them feel good about themselves and they like every additional obscure detail that they could add to bitcoin.

However there is a massive group of people who have not tried bitcoin yet and they are going to be turned down because of all the complexity involved and we have to scale down the amount of details they need to understand if we want to make them like bitcoin.

The only practical result if people start using using addresses like "1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfdTejU" is to make everything look more complicated and so making the bitcoin system less appealing to majority of people.

Maybe you missed it in there among all this discussion of the technical details and possibilities but the proposal does greatly shorten the address from:


to:


I really like the proposal as a way to shorten used addresses.  It is a really slick idea and does make the Bitcoin addresses much easier to read, say, and remember.

I am opposed to address reuse, not this proposal per se.

CIYAM wants a single address form that shows that someone can use all of the following to find his address:

all three forms combined and posted together:

1ciyam3htJit1feGa26p2wQ4aw6KFTejU:2adfd

Here is another one all decked out:

1BurtWEejbnKeBRsvcydJvsNztB1bXV5iQ:244fd (NOTE: I no longer use or support vanity addresses)

Kind of cool that you can see who is "older", could become a "badge of honor" type thing.

If I am ever in a bind and need to remember an emergency Bitcoin address I have already memorized  "244fd-1bu [iQ]", I go to http://www.minaddress.info, type in 244fd-1bu, check that the resulting address ends in "iQ" and wala, my old vanity address.

Why does the address  18uTXyQubfaYrkbQDdaXhzd2ALEY5YN77B not work?

Due to cheating I had to restart my game based on the MinAddress site.

0.1 BTC to the winner.

https://bitcointalk.org/index.php?topic=779081.0

Would this also be the issue for: 1QHzyM4yFDVdxQyijsFLVjzDJahZNfKQQb

As this address does nit work?

Thx

https://blockchain.info/address/1QHzyM4yFDVdxQyijsFLVjzDJahZNfKQQb?offset=6700&filter=0 (talk about address reuse!  I expect the massive number of transactions to this one single address, 6726, is probably what is causing the issue)

https://blockchain.info/tx/ea4f4e7a572348ea732229a5f7e618ed10d8dd8e298c434a0ec0332d91ddd227 (looks pretty standard to me)

https://blockchain.info/block-index/306124  (only 30 transactions)

https://blockchain.info/block-height/243752  (I see nothing strange)

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

"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.

Nice project! Is there any other way to make it short? Re-using the address is not good, so any other way???

  ~~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.)

Fixed up a bit.

Please read my rant up above in this very thread for more details:

https://bitcointalk.org/index.php?topic=774741.msg8758673#msg8758673

This is not true.

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:

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.

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?

I like my MinAddress, surprisingly easy to remember: 46044-1jfy
(back in one jiffy) ;D

Why smaller?

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").

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<x> where <x> is not the letter W or w.

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<x> where <x> is not W or w then we cannot use 1burt because your algorithm will find the previous unique 1burt address.

In fact the only time your algorithm can be used to shorten 1burtw to 1burt is if every single block which contains a 1burt<x> pattern in the blockchain before the first occurrence of 1burtw has two different 1burt<x> patterns.

Since <x> in our case here is all of the following characters:  123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz I think the probability that every 1burt<x> occurrence will occur in a block with two different 1burt<x> patterns to be not worth the extra computational effort above the standard firstbits computational effort.

To summarize:  you will almost always be able to find a block that contains a single 1burt<x> pattern so the algorithm will almost always result in the firstbits.

Yes, it's a bad idea to re-use address, but it is an absolutely stupid idea to discard a private key.

It's a safe option as far as the security issues are concerned.

That is an opinion, not a fact.

My opinion differs from yours on that matter.

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.

Discarding the private key of an address you've used seems to me like shooting yourself in the foot (and receiving the real-life consequences of that action) in order to adhere to an abstract principle that not everyone agrees with or thinks about.  I guess I'm saying that I can see this adding up to a lot of disputes and accusations.  Imagine you send btc for a debt to someone who discards their old addresses in this way.  You say "I sent you that money, same address I paid you at last week".  Then the other person says "no, my policy is to discard addresses, I no longer have access to that address because I've discarded the private key".  At this point, you might (rightly, imho) doubt whether that person is being honest---what if they still have the key but are lying to you in order to trick you into paying them more than once.  Obviously the fact that the bitcoins you sent are still in the address you sent them to would be evidence that the person hasn't yet tricked you, but is not evidence that they won't trick you as soon as you send again to a new address at your expense.  I guess my point boils down to this: someone may say that they discard old private keys, but how can they prove this?  (I don't think they can.)

And differs from Satoshi's, too:


source: https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136

Sorry, could you explain me what does the word "never" mean in this context?
I am not native English speaker and I am very afraid of misunderstanding.
Does it mean 1000 years? Or 100 years? Should I leave my wallet to my childs and ask them to keep my private keys? How will I check that they obey my orders after my death?

I see it more as documenting a set of rules (call it a "Constitution" if you like) and committing myself to that set of rules along with any real life consequences of that committment.


I make it very clear to anyone that ever sends me bitcoins that the address they are sending to is only good for the one transaction and that NO FUTURE PAYMENTS to that same address will be honored or recognized.  If they choose to ignore this information and re-send to an address they have sent to in the past, I can not stop them, but it will be very clear that they have made a mistake and have sent to an address for which there is no known private key.  Such a payment will not (and cannot) be honored and the loss will be theirs.


Lack of access to a private key cannot be proven.  However, if you've been told NOT to send to a particular address, and you send to that address anyhow, it is your choice and your loss.  As you put it, if you send to an address that I have given you in the past after I have informed you not to do so, then you are "shooting yourself in the foot (and receiving the real-life consequences of that action)".


It is your opinion that "it is an absolutely stupid idea".

Satoshi suggested that keeping an old copy "just in case" was something to consider. It appears, at least at the time of that post, to have been his opinion that "You should never delete a wallet", though he doesn't seem to have made a value judgement on the intelligence of someone (like you did) that chooses to delete the wallet.

Where the abstract principle you are talking about is address reuse.  I don't consider this an "abstract" issue.

Address reuse is the single largest internal threat to the long term viability of Bitcoin.  It is the single largest threat that we can do something about within the Bitcoin community.  Address reuse should be discouraged by any and all means possible.  Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways.  Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity.

Ideally all addresses would be used only once and contain only two transactions:  a single funding transaction followed by an eventual single spending transaction.  All change should go to a fresh address every time.  

I wish the protocol enforced these rules.  If it were possible to make this change it is the only change to the protocol I personally would support at this time.

As far as I can tell, you are putting a lot of risk on your ability to make this 'very clear to anyone who ever" sends you bitcoins.  I have to admit, if I understood this before sending you money, I'd say "well that's fine and no problem, he'll send me an address when he wants payment".  But if I didn't understand it beforehand, I think it would be hard for you to convince me that the loss was mine.  I would question whether anyone in their right mind would actually purposefully throw away the private key of an address they had already received payment at.  Your claims of constitution and principles would look very specious to me at that point.


Seems like in this scenario, who ends up with the consequences would be hashed out in a public dispute.  Perhaps the payer decides you are trying to scam and doesn't send again, perhaps you then label that person untrustworthy.  This example scenario is to vague and general to actually try to predict a specific outcome, but I think it's easy to see that it would be a mess.  By the way, has this happened to you?



I believe the abstraction lies in the fact that, as you say, the protocol doesn't enforce this.  The community doesn't (as a whole) do this---note the fact that we all have a "btc address" field in our bitcointalk profile info.


This seems like hyperbole.  Can you really link my reuse of a vanity address to a concrete threat on the longterm viability of Bitcoin and the Bitcoin community?

You can read one of my many rants on this subject, which is very dear to my heart as you may have noticed, just check out my signature.

Post #58 in this very thread:

https://bitcointalk.org/index.php?topic=774741.msg8758673#msg8758673

Someone sent bitcoins to an address that is no longer under my control?

No.

Since you seem interested in hypothetical scenarios, lets consider this one:

• You re-use addresses all the time.
• People who send bitcoins to you are aware that you re-use addresses and don't think twice about sending bitcoins to an address they've used in the past
• You become victim to a hacker or malware and the addresses you've used in the past are no longer secure.
• You tell everyone that you can think of that they should not re-use any address that you've given them in the past
• Someone doesn't get your message, and sends bitcoins to one of your old addresses
• The bitcoins are moved out of the address by a thief before you can access them

Who is "responsible" for the loss?

You? Because you created an expectation in others that they could re-use your addresses?

The sender? Because they failed to confirm the address with you, and failed to receive the notice you had sent out?

Do they still owe you payment or not?

You might say that the address was hacked, and that they shouldn't have sent there, but how do they know if it was hacked?  How do they know that they missed your message?  Perhaps you moved the bitcoins out of the address, and then made up a story about the address being hacked?

This is a mess.

On the other hand, if you established early and often that addresses should never be re-used, then it becomes clear where the responsibility lies.  If they send to an address that you give them, it is your responsibility.  If they send to an address that you do not give them, then it is their responsibility.


Note that there isn't any btc address field when you look at my profile.


No, it really doesn't.

DannyHamilton,

I very much enjoyed your hypothetical scenario.  I think you did a great job showing how misunderstanding, poor-communication, and/or false-expectation can lead to a mess in the general case and that an address no-longer controlled by the first user can cause problems whether or not the first user discarded it willingly or lost it to an attack.

I think your example also highlights a little more of why you feel so strongly about this.  You see address reuse as a theft waiting to happen.  I guess what I don't yet understand is how you can store your coins at all with such a philosophy.  Isn't any balance you have at the moment waiting to be stolen in the same way that my past used addresses are?

On the other hand, what you said here:


seems just plain snippy.  If you did have an address in that field on your profile that would be an act of amazing hypocracy given your "Constitution".  I referenced the btc address field of our profiles as evidence that your philosophy isn't necessarily shared by all (or even the majority).


This remark is similarly terse and not really helpful.  Care to elaborate?

 this is helpful for sure, thx for you nice work!

Hi again BurtW.  Thanks for the link to your "rant" on this topic.  I admit I had to look up the meaning of "fungibility".  I think I understand your argument that loss of privacy for one party is related to a loss of privacy for another party who transacts with the first.  However, I don't yet see how this is generalized to the whole network.  You say "by extrapolation", but I'm not convinced (yet).  In principle, couldn't you have a situation in which some users are "tainted" in this way by recursively interacting with someone who is "tainted" but others who are not?  Couldn't the careful among us (you'd obviously be in this group) avoid transacting with anyone who was tainted?

The second part of your argument was that loss of privacy leads to loss of fungibility.  Can you show that connection more concretely?  Maybe you already have in another thread somewhere else.

Cheers!

Pretty nice idea. Sure, there's the re-using issue, but many people don't re-use anyways (webwallets anyone).
Furthermore, there are many applications of fixed-addresses (businesses and charities for example).

Not sure though if this userbase it enough to make min-addresses a success. I would suspect that
it's an either-or issue - I don't want to check for every address into which format I need to convert
it, and how. If it's of course picked up automatically by all major clients, different topic.

The re-usage issue can maybe also countered with a client "registering" every address in the blockchain
before usage by sending a small amount to it. Hello blockchain bloat (but that seems to be the
latest trend in cryptoland anyways, unfortunately  :-\)

Perhaps, but if I give you an address and tell you to send bitcoins there, then whatever happens to those bitcoins is my responsibility and my loss.  On the other hand, if you use a bitcoin address that you "assume" is still okay to use, then the responsibility and loss are much messier to figure out (unless of course I've always made it clear that you should never "assume" that an old address is okay to use, in which case it becomes much less messy).


Didn't mean for it to sound snippy.  You used the phrase "we all have", and I was just pointing out that we don't all have it.  The option is there because the site administrator hasn't forced the issue on others, but the fact that the website allows something doesn't necessarily mean that it is recommended (or even a good idea).  Note that the website also allows users to buy and sell user accounts.


I haven't seen a reliable unbiased poll that determines what the "majority" think about the matter or if they even understand it.  I will agree though it is rather obvious that many choose to re-use addresses and some wallets even encourage it.


hyperbole - exaggerated statements or claims not meant to be taken literally.

BurtW's statement:


This is not exaggerated and is meant to be taken literally.

 

@DannyHamilton and @BurtW I think your "black and white" view of things here doesn't reflect *the real world*.

If a newbie was given an address by Danny for Escrow and wrote it down and then thought he'd lost it so asked for another one but then accidentally ended up pasting in the first address seemingly Danny is now going to "burn his funds on principle".

IMO that is just silly and won't help the adoption of Bitcoin at all (and would likely end Danny's Escrow service).

Sorry guys - but the world isn't black and white and you don't get to make the rules "just because you think a perfect world should work your way".

In the real world people make mistakes and we all do our best to ensure that no-one is getting hurt needlessly (and I know this from the actual experience of nearly losing 100 BTC through a stupid mistake which luckily a pool decided to refund mostly back to me).

is there any chance(although it is really low) that there is a coincidence of two addreses with this method?

I once had a vanity address that I used for everything, thought I was so cool.  I will dig up the thread and even the specific posts by Greg Maxwell and Death & Taxes that convinced me that this privacy/fungibility issue is as important as I say.

In a nutshell the crux of the entire Bitcoin experiment is can we create and maintain a trustless decentralized currency?  Decentralization meaning no central authority of any type.   Dollars are fungible, diamonds are not.  If someone pays you in dollars you can just accept them because a dollar is a dollar is a dollar.  However if someone pays you in diamonds you do not know how much they are worth without appealing to a grading authority.  Do you see where this is going?  I suggest we have commandeered this thread long enough and we should move to another thread on the topic of how address reuse will enable and lead to the eventual destruction of the fungible, decentralized and trustless aspects of Bitcoin.

I will post a link to the thread later today when I find it again.

I disagree.  There is nothing but stubbornness and lack of education that is forcing *the real word* to re-use addresses.


And if they accidentally paste some other address that isn't mine from their clipboard?  Either way they are pasting an invalid address. I haven't "burned his funds".  He did when he chose (intentionally or accidentally) to paste the wrong bitcoin address from his clipboard.


IMO it is not silly, and deletion of used private keys is an important part of the security and privacy that my escrow service provides. My escrow is provided as a free service to the community.  If people aren't comfortable with my practices, they are welcome to go elsewhere.


I agree, but you don't get to choose how I handle my private keys either "just because you think I should keep them".


Yes, people make mistakes.  Some of those mistakes can be expensive (sending to an incorrect address).  Sometimes we get lucky and are able to recover from our mistakes without significant loss (paying an excessively high transaction fee).

I don't think so.  I think the method is sound and will produce a one to one correspondence between MinAddress and full Bitcoin addresses.

I don't value the opinions of those that don't understand the protocol or its implications.

I do value the opinions of those that have put in the time and effort to learn how and why this all works. This includes CIYAM even though I happen to disagree with him on this particular matter.

Greg Maxwell and Death&Taxes are two others whose opinions I value on such matters.

It would be interesting to put together a list of people who have a reputation for understanding these details and then list out which of them are against the concept of address re-use and which are in favor of it.

And I likewise do value your opinion but I just find the extreme position a bit "hard to swallow" (in particular when we are hoping for more adoption of Bitcoin).

Certainly I do understand the issues of privacy (and potentially security) but I don't quite see how "fungibility" gets into this. Just because an address has been used doesn't make the funds "less spendable" (unless you guys are wanting to make it so - in which case you are the ones destroying fungibility IMO).

If I recall correctly, when this first became a heated topic about a year ago or so, there was talk about blacklisting and whitelisting addresses.  If addresses are re-used, then it is becomes possible to choose addresses and state that they are "blacklisted" (or whitelisted) for any reason that a group of people might want to blacklist them.

If addresses are not re-used, then it is impossible to know what addresses will exist in the future, and therefore impossible to create a blacklist (or whitelist).

The ability to create a blacklist (or whitelist) destroys fungibility since coins that are received at, stored at, and sent from a blacklisted (or whitelisted) address are seen as somehow different than those that are not associated with an address on the list.

From there, additional conversations popped up discussing various other concerns about address re-use, but that was the concept that first turned many people away from thinking that address re-use was a good thing.

Oh - okay - yes I remember that horrible stuff.

In any case - in general I would always use new address for each tx but I have found that for some things (such as not at home and don't have my own computer but need to receive funds for a face to face trade for example) a firstbits can be handy (I really have used this in the past back when blockchain.info supported firstbits).

Certainly I would not want people to ever use stupid black/white/orange lists.

In terms of "scaring off newbies" I think that one should educate them "one step at a time" and not expect them to be able to do "best practice" from the get-go.

If the protocol were changed as BurtW has suggested so that address re-use is not possible, then newbies will stop making the mistake of thinking of an address as an "account number" or "wallet" or "personal identifier", and will start thinking of it more like an invoice number (as they should).

Imagine someone saying "but I want to re-use invoice numbers. It's so much easier not to have to remember to use a new invoice number every time I pay a new invoice".  And someone else saying, "the world isn't as black and white as you might want it to be.  People should be able to re-use invoice numbers for multiple payments on multiple purchases".

Now tell me which one sounds silly?

True - but that is not how Bitcoin works (and not how *everyone was taught it works*) so that argument doesn't really work for me sorry.

People have formed some bad habits and have taught those bad habits to others.

I'm in support of BurtW's opinion that this is the one of two forking changes to the protocol that I'd be most in support of.

Then it will be how it works.

Good luck with that but I somehow don't see it happening any time soon but in the meantime it is of course a good idea to educate people about "smarter and safer" ways to do Bitcoin transactions.

Also I think that ideas along the lines of "stealth addresses" might hold more promise for the dealing with the issues of traceability.

Here is the thread:

https://bitcointalk.org/index.php?topic=334316.0;all

Luke made a modest proposal:  in order to gently move everyone away from address reuse lets make it a bit more costly (in time not BTC).  In other words you can reuse addresses but your transaction confirmations will take a bit longer.  As far as the opinions of the "general Bitcoin public" on this issue check out the poll in this thread.

My first response in this thread:


One of my later responses shows my change of heart and will give you some good posts to read:


And yes, this entire Luke Jr thread is a gold mine for seeing my change of heart, good posts on the issue, and good links to other threads on the same subject.

One final note on blockchain.info:  On the one hand they are by far the single worst source of address reuse in the Bitcoin system given that their wallet encourages address reuse and they have so many customers. On the other hand they were the first to implement the coinjoin protocol proposed by gmaxwell and offer this service very cheaply (0.0005 BTC per mixing round) to their customers.  I applaud their efforts to help rectify the privacy dilution they helped to create.

And an ad:  bitmixer.io is the best mixing service I have found so far.  They can handle mixing amounts up to 2K BTC.  I tried to invest but they are not taking investors at this time.

Again the "fungibility" issue doesn't really come into it unless we start talking about *choose your favourite colour* lists.

I hadn't noticed Luke's proposal before and maybe it isn't a bad idea - but you don't think something like "stealth" is actually a *better solution* all around?

Yes, I think that stealth addresses are a huge part of the solution and should fix the whole static address for charities, billboards, and even tipping addresses in your signature here on bitcointalk.org issues.  We need full and widespread adoption of stealth addresses as soon as is safely possible.

BTW Peter is one of my favorite people in the whole world.  Not only for his work on stealth addresses but because of this post:

https://bitcointalk.org/index.php?topic=563925.0

where he (hopefully) singled handedly wiped out all past, current and future shit/crap/junk/scam/pump-and-dump alt coins that do not implement his (or a similar) method of initial alt coin distribution.  His proposal will hopefully clean up the cesspool of alt coins once and for all.  I am not holding my breath but I am cautiously optimistic.

This has become one of my favorite theads.  So nice and peaceful.  I am sorry that we have gone somewhat off the main topic of the MinAddress proposal and web site but on the bright side we are keeping this MinAddress thread active and well bumped.

Agreed - I do like his idea a lot.

Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before.

Thanks so much for the informative discussion.  I now have a general understanding of the argument which connects address reuse to fungibility.   The steps are that (1) address reuse weakens privacy, (2) weakened privacy can lead to a fractured network because miners and users may decide not to interact with certain addresses.  I'm (still) not convinced, but I appreciate the discussion.  I'm going to check out the threads that BurtW linked us to.

Commenting here on the argument as I understand it, it seems there are some weaknesses on (1) and (2).  On (1), can't I reuse an address many many times in an anonymous fashion?  That is, it may be that address reuse might aid a private detective in figuring out the personal details of a particular user, but it also might be that it doesn't help at all or that the private detective fails to identify the user despite their address resuse.  Say a particulare mining node connected through TOR keeps sending mined bitcoins to an address 1bitcoinanon...  What do we know about 1bitcoinanon....beyond the fact that presumably this is the same person reusing an address?  In fact, it could be a group of people sharing an address (maybe they sent the address and private key to each other via ssl email).  Can't you imagine all sorts of such scenarios?

On (2), I want to present the opposite sort of rebutal than I did for (1).  That is, can't users start to whitelist/blacklist each other without knowing personal details?

To summarize, I understand the argument as this linear chain:

address resuse helps people discover each others details-->people who know each others details can dispute personaly-->personal disputes can lead to a fractured/less fungible bitcoin network

But for me:

 + I question whether address resuse necessarily leads to discovery of details and
 + I suggest that people may dispute without knowing personal details.

Cheers!

A protocol CAN be created to enforce no re-use. It just requires some extra work by the sender and receiver. I haven’t thought it through but it would be based on creating a new public key from another one similar to the way that HD wallets (BIP32) allow the SAFE derivation of child public keys from parent public keys.

Let’s see:
1.   The sender looks up the address he wants to send to. If it is unspent, he sends to it.
2.   If it is spent (and remember we only spend ONCE. The full amount...)
        he can derive the public key from the spending transaction, call it Y.
3.   He creates a new shared secret (Diffie Hellman) between his key and Y.
4.   He uses the shared secret and Y to generate a new public key, Y’, for the recipient and calculates an address from it.
5.   He sends to that new address.

The recipient can check every transaction to see whether it is his:
1.   He knows the sender’s public key (it was a spending transaction for the sender).
2.   He calculates the shared secret. This allows him to recreate BOTH his new public key and his new private key.
3.   He can spend the coins at a later time.

In all of this, what’s important is that ONLY the sender and receiver know the shared secret. Also the shared secret is unique to each transaction by the assumption of only one spend, hence only one use of the transmitter’s public key.

This is all a lot of work and probably could be made more efficient.

Finally, if you don’t want people sending more than once to your address, publish a RECEIVING public key that remains constant long term. It is never sent-to but is used in generating all the shared secrets the senders will need.

I am not sure what you mean by "enforce". If you mean "transactions with address re-use are invalid", I have already explained why it won't work.

What you describe is essentially "stealth address". It facilitates no re-use but not enforces it.

As long as we are pondering useless stuff..

It occurs to me that this could be more compact.

Let's take a random recently-seen address:


This is your min-address format:
4f4d6-1pi9

Instead of block number + firstbits of a block, we can get all the information from the structure of transactions in the blockchain, and then encode it smartly.

We can find the first occurrence of a payment to an address, and then refer to it by block_number->transaction_number->txout_number

We can call this micro-address. It can be the base58 encode of a bitstream-type encoding of the above data:

Most-significant-bit placeholder
1st bit set to 1

block number:

bit 0 - len of block count:
0 - 23 bits
1 - 31 bits

bit 1-24 or bit 1-32:
23 bit length: (blocks 0-7fffff) (blocks 0-524287)
31 bit length: add 00800000 (0-7fffffff + 00800000) (blocks 524288-8912895)

transaction number in block:

bit 0-2: length: number of words + 2 - 3 bits

000: 5 bit length (0-31)
001: 9 bit length (0-511)
010: 13 bit length (0-8191)
...
111: 25 bit length (0-33554431)

vout number:
bit 0-1: length: number of words + 2 - 2 bits

00: 6 bit length (0-63)
01: 10 bit length (0-1023)
10: 14 bit length (0-16383)
11: 18 bit length (0-262143)


for my example address:

block 234822, 0x39546h : 000000000000000006880233f89f572f006fd5dad0d1729d6d81622e8921e15f
transaction #18, 0x11h : fe17ff4c6df314cc708b2bab011a6327b61ffce81b4f7948ca8c6e7d3ee46105
vout #3, 0x02h:  address 1Pi9uP6YMqbvbrQ1b7m6qzAS5ejN7mSwWR

encoding base58(bitstream):
MSB 1:        1
block# bits:  0 00000111001010101000110
trans# bits:  000 10001
vout# bits:   00 00000010

>>> hex(0b1000000111001010101000110000100010000000010)
'0x40e55184402L'

>>> bitcoin.changebase('1000000111001010101000110000100010000000010',2,58)
'329UugoB'


So I get an eight-character micro-address of 329UugoB.

The length here doesn't vary based on how many bitcoin address characters it takes to be unique within a block. It only gets longer after  block 524287 or if there was a huge block and the transaction also had many outs. I'm sure even more optimized encoding could be thought up to minimize the average address lookup bits required.