There is no way to control the rise in value and second a rise of 5% per year with no speculation would mean the underlying economy is growing at 5% over the rate of monetary inflation per year.  For something as small as Bitcoin that would be a death sentance.  It would take decades for the userbase to grow even into the millions.

If you want slow steady rises in value wait a decade or two.  Bitcoin will either be gone or it will be magnitudes larger and the rate of growth will have been reduced significantly.

Or advocate to keep Bitcoin fungible.  Don't support compnies which seek to harm the fungibility.  Don't support the investors other projects.  Edcuate other users on the dangers.   Make sure your favorite merchants know if they implement it they will lose your business.  Support improvements like Luke's miner patch, coinjoin, and other projects which will make it tougher for the "validators" to accomplish their goals.

Yup. That is the important part.  Luke's patch can't FORCE anyone to use unique addresses however it can provide an incentive and if/when more of the hashpower implements it the incentive grows.  Without any incentive we likely will be in the exact same situation a year from now.  The current "lazy" static address use scenario is the easiest to implement.  Privacy minded miners can push for this patch which provides an incentive to make the Bitcoin network more what they want it to be.   Voting for change with hashpower.

The coinbase tx itself?  No (it would be in the block you solve, nothing can change that).
Spending the outputs of the coinbase tx?  Yes.

p2pool could implement BIP32 or in the interim given that p2pool nodes also run bitcoind could just implement a direct getnewaddress() RPC call after any successful block to ensure future blocks use a unique address.

Remember price =/= valuation.   Not speaking on the merits of the model but if the model is using non-price inputs and speculation drives price up (in short term) faster than the underlying economic activity the model isn't modeling that.  However as you see price eventually corrects to value. 

Well so far only one major pool (plus maybe a few solo miners) is using it.  That is the nice thing about decentralized network.  Some parts can try out new code (outside of core protocol) at different times.   Right now 15% of hashpower is using this.   Maybe by the time BIP32 is more ubiquitous 80% of the hashpower will be using it.

To the OP ... go ahead.  Have fun trying to explain to users how "your Bitcoin" isn't the same "Bitcoin" as everyone else when they say "Bitcoin".

Lasting forks are the worst possible scenario for Bitcoin.  They should be avoided at all possible cost. 

This.  Privacy doesn't end at a single persons addresses.  It involves everyone one you interact with and everyone they interact with.  One can be perfectly anonymous and if the people they interact with are not well that can provide an indirect method of identifying transactions.

Really as a tech savy person you can't think of a better workaround?  How about generate and import 1,000 private keys.  Then when you need to change the address simply use the python tool to find the next one in the sequence.


Well they won't until there is a reason to do so and the patch gives them a reason.  In the interim if a site allows posting 50 addresses why would you need to manually change them.  It would be a trivial amount of coding for a site to use the next one automatically and notify you when the queue is low or out.  Still BIP32 is a better longer term solution.  However if sites don't implement them you can still use funds with a small disincentive.  That would encourage people to use sites which do promote single use addresses.


Then encourage blockchain.info to change their default behavior.  The issue of reuse has been known since a YEAR PRIOR to the genesis block.  It is unlikely without an incentive anything will change.  Lastly remember this doesn't prohibit reuse, it doesn't make coins sent to a used address lost, it doesn't even mean higher mandatory fees.  It is merely delaying secondary spends from the same address.


Chicken or the egg.  Without the incentive will the infrastructure ever exist.  Blockchain.info could easily (within minutes) change their code.  Will they?  Probably not.  Not until users complain.  Will users complain unless their is an incentive?  Once again probably not.  It isn't like Bitcoin just launched.  There has been years to do things right and the lazy, easy approach has been used in most cases.

And assuming 11M active funded addresses there is a 99.99999999999999999% (should be 18 9s ) chance the address is unfunded.

Of course for it to be any use one would need to store both the private keys AND public key and generate the public key from a private key using ECDSA operations so we are talking a rather slow operation and roughly double the storage requirements of storing just pubkeys. 

Even if it is trivial to store 2^80 the cost for this "attack" would be magnitudes more than a 51% attack and would do magnitudes less.  We can only hope in the future attackers are willing to skip the obvious cheaper attack and waste magnitudes more resources on a trivial pointless "attack".

A single collision isn't going to even cause a blip in the long term utility of Bitcoin.  It would take thousands of such collisions to make people question if the address system is flawed.  Even a single collision would cost far more than simply 51% attacking the network and refusing all transactions.  Hundreds or thousands of collisions would be a cost on an order not seen.

The attack is successful it is very easy to prove.  Find a PubKey A & B such that RIPEMD-160(SHA2(SHA2(PubKeyA)) == RIPEMD-160(SHA2(SHA2(PubKeyB)).  Publish A & B or simply send coins to the address they share and spend from that address using both PubKeys.  Showing a collision is very black and white so I think maybe you mean something else?


There is also the benefit vs cost.  Even if/when storing that amount of data is possible we are talking about a cost which is magnitudes higher than simply 51% attacking the network.  So this "attack" has magnitudes higher cost for magnitudes less impact.  It will never happen.  Even if someone had that kind of resources and wanted to destroy Bitcoins there are simply easier simpler ways to do so.


Maybe you mean "will occur" because after a collision has occurred it is trivial to prove that it has occurred?

Even if we assume that the hardware COULD be used for this purpose basically you are saying:

Someone could spend 800%* of the cost to 51% the Bitcoin network to potentially produce an unused pair of pubkeys which hash to the same pubkeyhash rather than:
a) collect ~50% of annual Bitcoin mining revenue.
b) attack the network with a sustained 51% attack.

Yeah I think we are safe.  So once again do you realize how large 2^80th is.  Do you realize the asinine cost it would require to produce a collision?  Do you realize the far easier attacks that can be done with that amount of cost, and energy?  Do you realize the utter stupidity of using this as an attack?

* In reality it is probably closer to 8,000% as generating PubKeys is far more computationally expensive than generating SHA-2 hashes.

Well not it isn't.

https://en.wikipedia.org/wiki/Comparative_advantage

It is simply the price.    If potatoes are $2 per pound it doesn't mean you can't buy 1/4 pound of potatoes.
If Bitcoins are $400 ea it doesn't mean you can't buy 0.1 BTC.

Like I said I don't know a single site which requires you to buy only in increments of one whole Bitcoin.

He owns a lot and therefore wants it to happen.  Nothing more.

That is a flawed understanding of the fee rules.   High priority txs have no required fee, none.  As in 0 satsohis.  This applies regardless if a block is 1MB in size.  

The min mandatory fees FOR LOW PRIORITY TXS are designed as a denial of service prevention mechanism.  They are only enforced at the client level.   Even if miners follow those they have absolutely no effect on high priority txs.  

Lastly the rules aren't enforced at the protocol level.  Miners an build any valid block they want by using custom bitcoind.  This is hardly beyond the capabilities of a major pool (all are using custom nodes already).  It is possible to have a block contain NOTHING but no fee txs (as in ~2,400 of them) and the block is still valid.

You base this on what magic?

Do you understand how large even 2^80 is?

If a billion people produces a thousand addresses per second for the next 1000 years the odds of a collision are 1 in 260,000.

Of course even that understates the chance because regardless of how many new addresses are used only a finite number of addresses can be funded.  The absolute max number of funded addresses is 2.1 quadrillion and that would be all addresses contain a single satoshi each.  The actual number of addresses is likely to be much much much lower but that provides an absolute upper bound.

It is far more likely (as in thousands of quadrillions to one) that any match would be unused addresses.   The used active addresses space is ~11M addresses.  2^80 is 109,902,347,237,693,561x larger.

So after an utterly asinine amount of time, energy, and cost if/when a pair of pubkeys which produce the samepubkeyhash were found it is 99.99999999999999999% likely the two pubkeys would be ones created by the attacker and be empty.

Well that is the point the "attacker" (and yes this would be most expensive and stupidest possible attack on Bitcoin) could find a pair of pubkeys which hash to the same pubkeyhash, then send coins to that address, and then spend those coins with both pubkeys. 

Generally speaking this is something that shouldn't be possible and it may be a small loss of confidence as it would be publicly visible to anyone on the blockchain.  It would be good for a FUD campaign "see Bitcoin is broken" and that is the OP contention.   However the MASSSIVE expenditure required to perform this "attack" combined with the limited effect makes it dubious.   A single instance would quickly be dismissed as incredibly unlikely random chance.  To replicate the attack and make it appear that Bitcoin was compromised would require finding hundreds or thousands of pairs of pubkeys which share a pubkeyhash so the entire attack cost would have to be increased by a factor of 100x or 1000x.  At this point you are taking more computing power and energy than what is required to 99.9% attack the Bitcoin network.

So no there is no utility in this "attack" but it is technically incorrect to say coins couldn't be spent.  They would be the attackers own coins but they could be spent by either (or more like both) pubkeys which hash to the same pubkeyhash.