I'm not sure how you can say such a thing with a straight face.

In any case, one of the beautiful things about bitcoin is that the only thing stopping you from imposing your will on the people is the will of the people.  Get miners on board with BIP17 and that will be our future.

There is still a risk of a chain split even with a backward compatible change such as BIP16 or BIP17.  To avoid that from happening, Gavin is trying to get miners to commit to supporting one of the BIPs up front and then coordinate the timing for them to actually switch over.  But lets say he gets the commitment, sets a date for the switch over, but for one reason or another, only 30% of the miners start enforcing the new rules.  Let's also assume we have a miner that's not restricting itself to transactions that are considered "standard" (*ahem* Luke-jr*).  In this scenario, you could see a transaction that is considered valid under the old rules (may not be standard, but could be perfectly valid), but which is invalid under the new rules (see one of the methods of spending a BIP16 or BIP17 transaction under the old rules without authorization).  You now have a chain split because the old chain still has 70% of the hash power and the new chain won't be able to outrun the old chain.

Now, to be clear, I don't expect this to happen with the BIP16/17 transition as I expect the miners will all do what they're expected to do and pretty much all transition to the new rules.  But it does rely on people acting in a coordinated fashion.

So, here's how I think it could work in the future that would work even if miner coordination is botched.  Clients should be designed to support 2 script engines and their associated block chains.  The script engine could be factored out as a shared lib or some plugin that could be installed or swapped out independent of the client itself.  Normally, people would just have one script engine installed and the client would just manage a single block chain.  But when a script change is being implemented.  A new script engine could be distributed.  People would install this second script engine.  When two engines are installed, the client would keep track of two block chains and would validate all transactions against both block chains and refuse to accept or propagate transactions that don't successfully validate against both engines.  If the script changes are backward compatible, there is a good chance there won't be a block split even though there are two script engines, so the client is just managing the single block chain as usual (but still validating all transactions and blocks against both engines).  Miners can then decide on a schedule to start performing validation using the new script engine and attempt to make the transition in a coordinated fashion.  But the good news for everyone else is that if the miners screw up, they only hurt themselves and not everyone else.  Some of the miners might be creating blocks with worthless coinbase transactions, but that's their fault for not getting their act together.  Miners will have a very strong incentive to all be mining on one chain or the other…so any division of mining power between two block chains should be very temporary (it should only take a few days at most for the super majority of miners to get on the chain that appears like it will be the survivor).  Once it becomes clear that one of the engines/chains is going to survive (this might be indicated by blocks appearing at very long intervals or the difficulty plummeting), people can drop the dead chain.

I think this (or something close to it) would enable smooth transitions in the future, even if the changes would lead to a chain split.  The only requirement would be that the proposed new chain still support old style transactions (perhaps the new engine could reject long since deprecated transaction styles in order to phase out the use of them, but transaction styles still in widespread use would need to be supported).  In fact, a chain split might actually be preferable in this case because you would know definitively which set of rules are being enforced by the majority of miners (with the proposals for BIP16/17, assuming a split doesn't occur, you don't have a reliable way to know for certain if the majority of miners are actually enforcing the new BIP16/17 rules).

You could distribute a new script engine months ahead of a proposed date for miners to switch over.  That would give ordinary users a fair amount of time to install the new engine and prepare for the change (especially if the change will cause a chain split).

----
* I actually think it's good that we have a pool that accepts all valid transactions…I would be more nervous if no one accepted strange transactions and no one was thinking about the implications…if someone can do something that might compromise bitcoin, someone should do it (as a white-hat kind of exercise).

If he's half as good as you are at reviving dead threads, it just might work. 

In the future, what you'd want to help manage a necessary chain split are nodes that will only accept transactions deemed valid in multiple chains.  Certainly, once a new set of validation rules are largely agreed upon, miners will switch over quickly (because if they stay on a dying chain they would be mining blocks with worthless coin base transactions).  A chain split may actually be easier to manage in the future than we can imagine today.  As thin client wallets proliferate and rely on a trusted point of presence on the bitcoin network, the full nodes that provide access to the bitcoin network can help ensure that only valid coins are ever accepted into wallets (possibly validating against multiple chains for short periods of time during a transition).  The reason you would want to validate against both the old and the new chain for a short period of time is that you want to make sure the transition actually occurs and you reach the critical mass to make the transition "stick."  If you only accept coins that are valid on both chains for that transition period, you can rest assured that no matter whether the transition is successful or not, all of the coins in your wallet will be spendable.

Right, but that's not really a gold standard, that's basically what we have today.  Although, if he's promoting an international, gold backed currency for use in trade, then he probably does have a traditional gold standard in mind for that (basically, you have a token of some kind that is exchangeable for a certain amount of gold).  As I said before, the temptation to counterfeit is too strong…it would only be a matter of time before that too would break down like all other gold standards before it.

I would not argue against a gold standard to Jim.  Besides, I don't think he's in favor of a gold standard per-se.  Gold standards don't really work…they inevitably break down because the temptation to counterfeit is too strong.  But gold is a very good barometer for the health of a currency and a government should pay attention to the exchange rate of its currency with gold.  I think Jim argues that the US needs to defend the value of the dollar by targeting a rate of exchange with gold for a period of time in order to restore confidence in the value of the dollar.  It's possible they are already doing that, but simply not overtly stating it (in other words, the FED might have a target of say $5000/oz that they are seeking in order to sufficiently devalue the dollar and yet do it in a managed way over an extended period of time).  

It seems to me that a significant devaluation of the dollar is the least bad outcome for resolving the over extended debt situation that we have...if it can be managed without degenerating into a hyper-inflation.  The alternative is lots of insolvencies and chaos.  It's the nature of fiat currencies that they don't deal well with debt contraction.  But people need an effective vehicle to move out of various kinds of debt backed instruments for that to work well.  Unfortunately it isn't that easy for people to transition into gold (and I'm talking physical, not a paper substitute, which is just another form of debt), so it doesn't function as smoothly as you would like for the purpose of people shifting out of debt backed instruments like the dollar.  That's where bitcoin can come in.  There have been some prominent articles about using gold in various ways to facilitate this shift and avoid complete chaos and breakdown (one recent article proposed the government introduce gold backed bonds).  Bitcoin would be a far better instrument for this purpose if only it were more widely known and used.

I would suggest you read this article before talking to him: http://www.libertariannews.org/2011/06/21/against-the-gold-standard/

It is by far the best article I've seen written that explains the problems with a gold standard and why bitcoin (and its free floating exchange rates) are the perfect digital complement to gold.  I'd recommend you find some abbreviated way of expressing the view of this article to Jim Rickards.

The thing that bothered me most about BIP16 is that the execution of the script in scriptSig is triggered by recognition of a special pattern of opcodes in the scirptPubKey.  BIP17 seemed cleaner in that it adds a new opcode that essentially says "compute the hash of the code following the most recent OP_CODESEPARATOR and verify it."  Execution of this code happens because it's simply in the normal flow of opcodes.  From the perspective of what these BIPs enable, both of them are workable.  But Gavin's concern should give us all concern.  He's earned enough credibility that you shouldn't really disagree with his position unless you take the time to really study the current script engine as well as the history of how it evolved to where it is today.  And my superficial understanding is that BIP16 is less of a departure from the historic conventions in terms of how scripts get executed and what types of opcodes have been traditionally used in the scriptSig. 

BIP16 might be overly conservative, but at the same time its hard to argue against being overly conservative when the objections to BIP16 are largely just a matter of aesthetics.

In thinking about p2sh and about the whole topic of the recipient of a transaction being the one who has the incentive to see that a transaction makes it into the blockchain, I've arrive at this potential solution.  Note, for bit-pay (as well as other processors), having the recipient set the transaction fee could be quite beneficial.  We occasionally get very low priority transactions that, while being perfectly valid, take forever to get into the block chain.  It would be nice if we had a mechanism where we could ensure it will get the appropriate priority with miners.

What if instead of transactions being included directly in the block chain, they were instead put into a container that could hold multiple transactions.  A sender could deliver a transaction to the recipient who could then add another transaction that pays a fee.  Loose transaction could move about the network as always, but until they get put into a container, they are ignored by miners (at least for the purposes of inclusion in a block).  There might be other uses for transaction containers.

I realize that this would be a radical change for bitcoin and not likely to happen anytime soon, but I'm curious if anyone has thought of alternative ways of doing this (ideally that preserve the simplicity of the sender just paying to an address without requiring the recipient to communicate anything else up front)?

It's a good video…should be required viewing for anyone working on an open source project.  As for those that are advocating a position of not rushing things, I think the opportunity to move forward is now while it's on the forefront of a lot of people's minds.  If you delay or defer work on this, we'll just rehash all the same issues again in 3 months time and get nowhere.  I think it's time to move forward with the process as Gavin outlined it (it's not rushing anything).

Why?  A pool owner has everything to gain by preserving the value of bitcoin.  If the network isn't running smoothly the value of bitcoin drops and pool operators are out of business.  Also, if pool operators attempted a change that benefits them over everyone else (setting aside the practicality of actually doing such), you can be sure it would undermine the value of bitcoin.  Mind you, I'm not saying that it's not a good idea to disperse the hashing power that a pool controls…I would certainly like to see more control (especially over block creation) returned to the individual miners.

Excellent point.  Much of the debate happening on the forums probably leaves a lot of people with the impression that a majority of miners could simply change the rules of bitcoin.  They could change the rules they enforce, but they would no longer be creating bitcoin blocks and their block rewards would no longer be usable anywhere that bitcoin is accepted.  It's important to remember that the proposed changes actually reduce the set of transactions that would be considered valid.

At best, the committee would just be making a recommendation…the miners don't actually have to follow the recommendation.  Still, I think it's not a bad idea.  The miners could vote in proportion to their mining power to elect a committee to study and then make a recommendation.  The recommendation would also be made by a vote.  I suggested using the Condorcet method in another thread.  It could be used for both the election of the committee and the vote on the recommendation.  In another open source project I've participated in, we used it to elect an oversight board.  We used this tool for the administration of the vote: http://www.cs.cornell.edu/andru/civs.html   …it might be overkill for this issue, but something to keep in mind.

And the nice thing about this is that if the committee comes to a decision the miners disagree with, the miners aren't bound to actually follow the decision of the committee.  

I posted some stuff about using the Condorcet method in replies to the article.

The article claims that the following was said in an un-cited forum somewhere: "want to know if we are going to war with Iran, watch the block chain"

That seems to be the only evidence they have that the CIA is paying people with bitcoin.  This is what you call an "echo chamber."

Right…and with p2sh, the impetus is really on the receiver of coins to ensure whatever script they come up with is free from any defects that might allow unauthorized people to spend their coins.  Which is how it should be.  Someone could create a script that allowed anyone to spend the coins, but that's an issue for the script author, not bitcoin itself.  If anything, scripts should be allowed to access even more data related to a transaction or the block chain.  For instance, your script might check whether the input transaction has at least N confirmations.  Or it might want to check that a certain percentage of the input amount goes to certain output addresses (you can imagine this might be useful for a payment processor like bit-pay that doesn't want to ever have control over the full amount of a transaction, but instead just redirect a percentage of the value of the transaction).

And that would lead to people checking with their favorite merchants and exchanges regarding whether they consider a given transaction valid.  If everyone did that, there would be no need for a block chain.  Everyone could just keep their own transaction histories and check with others to see if they think a transaction is valid.  But then you've created a situation where the power to determine what is considered a valid transaction consolidates around a handful of entities.

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

We have merchants all over the world.  We offer payout in either bitcoin or USD (we even have a couple merchants that we payout in EUR, but this is not yet officially offered or fully automated).  It's only if you want USD payout that you need to have a US bank account.

Bit-Pay.com has a shopping cart.  It also integrates as a payment gateway with several of the more popular shopping carts (opencart, zencart, magento, whmcs).

Why not go a step beyond and make a clean start for the script engine in litecoin?  Make all litecoin transactions be a p2sh style transaction.  And clean up the cruft in the bitcoin script engine.  Make it will tested, etc.