It invalidates the assurances because it changes in an unintuitive way the basic Bitcoin protocols. This is more about perception rather than reality. The current design has been shown to be strong. Even if you provide a sound argument for why OP_EVAL does not introduce any other holes, everyone who has already convinced them of Bitcoins correctness now has to go back and convince themselves again. Look how long and complicated the first post is! If this is implemented,
everyone working with the system needs to go and read/understand it.
This is a huge cost that must be justified with huge benefits, but there are none.
Let me go through the proposed advantages one by one (I did this on IRC already):
Addresses for arbitraritly complex transactions are fixed forever. No more new address types need be introduced.
As far as I know, most complex script types are used for contracts, which have multi-step protocols anyway. The whole concept of an "address" wasn't emphasized much in the original Bitcoin release, send-to-IP was seen by Satoshi as the most likely way to make payments, because it allowed for negotiation (obtaining a new key automatically).
I don't think addresses for arbitrarily complex transactions will ever be useful. Show me 3 complete, well specified use cases for this where a static address is the best solution (over files or protocols) and I might change my mind. Even for one-to-one payments a protocol is normally a better solution because you want a new key for each payment.
Addresses need only be same length as the current ones, forever.
See above. Most likely addresses will eventually go away and not be seen by end users except in unusual circumstances. If you think like a product designer, addresses should not be as prominent as they are today - they're opaque binary strings meaningful only to machines, and presenting them in base58 doesn't change that. It's bad UI to have them so visible.
Transactions sending to multisignature addresses in this scheme are the same length as normal. This addresses theymos' concern that senders shouldn't be burdened with extra fees from longer scriptPubKeys.
Senders should never be burdened with fees, period, because it's not the sender who cares about double spends. That this is how the protocol works today is a technical detail, not how you'd actually design things from the users perspective.
The simplest solution to this problem is not to completely change the scripting system. It's for senders to send a transaction directly to the recipient, who can then attach another one including a fee of their own choosing and transmit both. A change to the priority calculation rules to recursively calculate fees of dependents would mean that miners include several free transactions in order to claim the fee on the last one.
In this way, a group that trusts each other (like a family) can potentially trade coins without any fees at all, even post-inflation, because none of them need the networks help to avoid double spends. It means some changes to how Bitcoin users do things (sending payments as files rather than being given an address) but nothing particularly revolutionary. It'd solve a bunch of UX problems at the same time, like automatically labelling transactions.
If you don't want two transactions where today there'd be only one, have inputs be signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY so the recipient can add their own input before broadcasting it. But implementing transaction pruning means two transactions instead of one doesn't boil down to any more disk space over the long run because the first transaction will get pruned away.
I think there are some premature assumptions about how two-factor coins will work here. It'd help if somebody wrote a full design doc containing not just the changes to IsStandard() but how everything else is supposed to work too. Gavin mentioned a third party service provider/website that holds one of two keys, and sends you an SMS to confirm payment. Once you start to think about this in detail, it becomes clear that it to protect you against a compromised host the SMS must contain a human-readable description of the recipient and not an address, otherwise the virus can simply pick an address of its own choosing and replace the one you intend to pay with that one. It couldn't change the amount you want to pay as presumably that'd be included in the SMS, but if it waits around until you decide to make a big payment it could probably steal a lot.
So fixing the identity problem should really come
before fancy scripting language changes. But I don't see much talk about doing that, even though it's a much simpler task.
