There is a difference in forking the current chain and creating an alt-chain.
In the first case you create confusion and it will only work if everybody migrates to the new fork letting the old one die.
Alt-chains are different in that they have their own blockchain from the beginning and they usually have its own brand.

"You might be thinking of alt/scam coins, which can and do coexist"
Well, That's not they way I would personally say it, but ok.

Your post and interlagos are simply pointing out some of the technicals and obstacles that must be considered to make a fork possible and coexist - overcoming these are just a small part of what I was implying when I said "make Bitcoin fork friendly". Some things would need to be changed just like things need to be changed to utilize multi-signatures.

BTW, A fork is very similar to an "alt/scam" chain with one key difference: The coin holder before the fork will automatically own the same amount of coins in both chains.

Like I said before, a fork will happen. Don't know when - might be a decade, but it will happen.
Let's embrace and make it Fork friendly.

The intention of my post here in the BIP 16 BIP 17 thread was to throw out some ideas and hopefully persuade a few bitcoin programmers to take up this crusade. No one interested? OK, moving on.

.......... Back to BIP 16 BIP 17.
I don't have a problem supporting either one. Please make it happen. If there's a bug or problem down the road.. well, I'm confident it will be dealt with properly.

As much as I hate to say it (I'm promoting a fork), Bitcoin is not fork friendly, for the exact reason Gavin said: when you fork, all the coins in existence can be spent twice, one in each leg of the fork, and everyone on the minor leg of the fork is poised to become a victim.  That's a major problem, you simply can't have that.

The only reason I propose that my fork plan has a chance is because I've rigged it so the leg that's destined to be the old (minor) leg has a way to detect spends on the new leg, an idea that I don't think has ever been seriously considered by the developers before.  Were I Gavin, I would want days at a minimum to wait for inspiration on how such a scheme is could fail or be attacked before even considering acknowledging the idea had merit.

This is not so simplistic a matter. There is a major cost to forking (wasted effort on the inferior fork, potential increase in user uncertainty).

Nevertheless, if the benefit associated with picking the best answer instead of the second best answer is sufficiently large, and if there is sufficient uncertainty about which proposal is the best answer, then it will be optimal to fork. Otherwise, it is not optimal.

Here it seems clear that there is major uncertainty about what the best choice is. It is not clear that there are major benefits from making the best choice.

 

It's become painfully obvious to me that at least 99% of btc users are not qualified to offer a valuable opinion on BIP16/17. I do however have one piece of advice, it goes something like this:

I work in an industry with high stakes (lives) and fundamentally constant risk management, and there's one simple rule.

Suppose I have to make a decision between option A and B.

A is generally safer but more costly.

B is generally riskier but more efficient.

It's not feasible to always choose A because we'd go bankrupt. We can't always choose B because literally, people would die. We have to weigh the pros and cons and decide. We use knowledge and experience to make that decision. Most of the time the choice is obvious, either A is required because the overall risk factors are high, or B is preferred because all the risks are known, accounted for and considered well within the system's ability to cope.

Sometimes it's not so clear cut. When in doubt, we always choose A.

What does this mean to Gavin, Luke et all? Basically, since there's such a divide between the 2 of you, the safest option should prevail. The integrity and safety of bitcoin must NEVER be compromised. Bitcoin is the world's first and only free (as in liberty) money, for the sake of our futures please do not blow it.

thanks for the clarification Luke, it helped me.

You guys are best qualified to evaluate both the size of the risks (i.e. potential extent of the damage) and the probability of them happening. If you can come up with such an evaluation and can get Gavin examine it and give his own eval (if he disagrees with yours) it might be a way forward to solve the dispute. When in doubt, safety first.

Best of luck man!

...but if the right decision is made would die less of them.

Gavin seems to be ignoring BIP 17 and forcing everyone to support BIP 16 as much as he can, but he is basically alone in actually opposing BIP 17 (not counting people who oppose both).

You should contact the mining pools and convince them of the superiority of your proposal, just the way Gavin did last week. That way all pools will have a chance to evaluate both based on merit.

If you can make a nice business-style Power Point presentation, or maybe a good youtube vid about all the pro's and con's of both proposals (but keep it professional!), maybe you can get them to support your side..?

You could, perhaps, also prepare a pre-compiled client for instant deployment, or maybe a simple step-by-step instruction of how to enable BIP 17 if you run a pool...
.