OP_EVAL proposal

[gmaxwell]

Delaying fees will not really make a real economic difference.   It's just a transaction cost and in an efficient market the price will adjust so that the outcome to all parties is the same.

One thing I don't like about this but can't solve is that it changes the incentive structure for non-standard transactions.

Today if you try to issue a transaction that no one will forward or mine it just doesn't work and then you say "oh well" and spend your coin another way.

In the brave new OP_EVAL future, you spend coin to a script hash and then only later learn that mining the transaction spending it is difficult.  Instead of saying "oh well" you're out the funds until you can convince someone to mine the transaction... and you only discover this after your funds are tied up.

Presumably we'll be smart with the software and not allow the UI to issue transactions that won't work but I'm still concerned that this may increase the number of large burdensome transactions in the blockchain.   On the other hand, because only the input script will be large there may be some increased helpful pruning potential.

It might help a little if we made public key recovery (which we now have code for as part of Sipa's signing support) something that OP_EVAL scripts could use, at least scripts spending "must provide four signatures" wouldn't be quite so large.

[ByteCoin]

I must credit sipa as first raising this issue as far as I know.

If we did the obvious thing and used [a current OP_NOPx] for OP_EVAL, then, surprisingly, OP_EVAL would not necessarily cause a block chain split.

There's a bit of a problem with rolling out OP_EVAL using this idea and I believe it may create a more dangerous block chain split than casascius' alternative proposal whereby OP_CHECKSIG gets renamed and re-imagined as a slightly hacked OP_EVAL.

It's true that old clients will be accepting of blocks creating and spending OP_EVAL transactions. This is the advantage you mention.

However, old clients will also be accepting of blocks which contain transactions which incorrectly attempt to spend OP_EVAL transactions with a null scriptSig. As you mentioned in the IRC, the old clients see these OP_EVAL transactions as ones which anyone can redeem.

Miners would be best placed to watch out for transactions in which a null scriptSig can satisfy the scriptPubKey and then include transactions spending them in their blocks. This checking could be implemented now in anticipation of OP_EVAL being introduced in the fashion you propose and the exploit could be fully automated and require no time-consuming user intervention. This means that the bitcoin developers would have little time to react before the fraudulent transactions become confirmed. Clients (and miners) using the new version would reject these blocks but they would at least initially be a minority. People may opt not to upgrade to the new client as it would be easy to portray the new client's behaviour in negative terms. The effect of the above exploit would be to have a block chain split in which the latest clients who are supposedly doing the right thing may end up on the losing side. It would be bad for the public perception of bitcoin if an upgrade voluntarily precipitated a completely optional disaster along these lines.

I think it's more practical for people running old clients to bear the risk of failing to keep their software current. The policy towards incompatible changes will have to decide how much risk is acceptable and how long a time users are guaranteed to be safe running a particular version.

Bitcoin is lacking an effective and reliable mechanism for safely performing block chain splits. The worst-case scenario is one in which mining pools say they have updated their software and patch their clients to look like they are updated but then their software is actually designed maliciously to exploit the incompatibility of the new clients. If a client deployment strategy can cope with this situation then it can probably cope with anything.

Before introducing an incompatible client, I think it's wise to ensure that the existing clients have robust detection of block chain splits.
In particular, if a client sees a succession of what it thinks is invalid blocks with a high difficulty, then instead of banning the peer for misbehaviour, the client should disallow transactions (until overridden) and advise the user that an upgrade may be required.

Another way to limit the financial damage from an exploited rollout would be initially only to allow new incompatible transactions of infinitesimal value; where both the transaction and any change are both suitably small. This limit would increase in some fashion over time unless perhaps a "shutdown" transaction were broadcast which would disable the new behaviour. This shutdown switch could be removed in a subsequent version when no exploits appear and sufficient confidence has been reached. Also, there would have to be an initial prohibition against spending new style transactions into old style transactions.

Also, instead of enabling a feature after a certain block number, it could be introduced after seeing a block containing a particular magic transaction. This protects against the situatuion in which the miners (or the rest of the network) fail to upgrade as quickly as expected.

ByteCoin

[casascius]

That makes me think of one other random idea:  if a client notices the production of new blocks has taken a drastic drop (e.g. it's dropped by more than 90% and been more than 48 hours), it ought to say, "OK, something might be wrong right now.  Check for any significant Bitcoin news and to make sure this is the latest version before continuing to make transactions."

[Gavin Andresen]

Wow, so many great ideas!

RE: There is already code to warn the user if they are on a minority chain more than 6 blocks long-- see GetWarnings():

WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade.

It just warns, it doesn't stop you from generating/sending transactions. Perhaps if the longer fork is more than 120 blocks ahead it should.

ByteCoin: we can prevent the scenario you describe (generate a block with a NOP1/EVAL transaction whose validity is different in old and new clients) by:
1. Requiring that EVAL transactions be valid if the EVAL is interpreted as a no-op.  New clients can replace EVALs with no-ops and re-evaluate them to make sure that is true.
2. Waiting until a majority of hashing power has upgraded before turning on EVAL.

gmaxwell:  I really like the idea of implementing key recovery to save space in the block chain. It can also be done in a backwards-compatible way if only CHECKSIGs "hidden inside" of EVALs support it (CHECKSIG would be aware of whether it was being executed inside of an OP_EVAL, and if it was it could use a compressed version of the public key instead of the full public key).

All the ideas about figuring out what percentage of miners have upgraded:  seems like that deserves its own discussion thread.

[Pieter Wuille]

As scripts inside OP_EVAL can have different semantics from the original, we can use it to short-circuit introduce a new version of the script language.

I've written a draft for a new version here: https://gist.github.com/1262449

Rationale for the changes:

• Using the altstack for signatures avoids the need for bookkeeping on the stack in scripts that do complex checking (the altstack contains the data from scriptSig, the normal stack is used for evaluation)
• Using ECDSA pubkey recovery, we avoid encoding public keys in the block chain
• Low-level signature checking can be used to implement signed message checks in script, or more custom signature schemes
• A shorthand operation for the most common case (send to address) makes normal scripts shorter

[ByteCoin]

If such comprehensive changes are being considered then I suggest that the default option should be that the signatures for a transaction should not influence the transaction hash. This would allow transactions spending unsigned transactions to be signed, which is a crucial step in some contracts. Also, the signature data could be pruned from the block chain for transactions occurring at sufficient depth or before a checkpoint. This would effect considerable space savings as the signature data is probably the only data that doesn't compress.

Another improvement would be the introduction of the Bernstein signature scheme with a similar security parameter to the existing ECDSA but a much faster verification. Transactions using the cheaper signatures could get a discount on the fees or be allowed more sigOps. To be clear, the scheme I'm thinking of is "A secure public-key signature system with extremely fast verification" from about 2000.

With regards to key recovery, a 2 bit hint can be used to accellerate the process. Alternatively, a single hint value could be assumed and it would be the responsibility of the signer to redo the signing operation until the assumed hint value is correct.

ByteCoin

[Gavin Andresen]

If such comprehensive changes are being considered then I suggest that the default option should be that the signatures for a transaction should not influence the transaction hash.

... but isn't it the signatures that give each transaction its unique identity?  I may be wrong, but without the signature hashes I think you can get two different transactions (two transactions that are exactly the same as far as scriptPubKeys, but spend different outputs) that hash to the same value, which would cause all sorts of problems, including replay attacks re-using old signatures.

Another improvement would be the introduction of the Bernstein signature scheme with a similar security parameter to the existing ECDSA but a much faster verification. Transactions using the cheaper signatures could get a discount on the fees or be allowed more sigOps.

Interesting... too radical a change for right now, in my opinion.  (I think Pieter's proposal is too radical a change for right now, too... I'm on the fence about whether OP_EVAL is too radical a change, but I think the advantages outweigh the risks).

With regards to key recovery, a 2 bit hint can be used to accellerate the process. Alternatively, a single hint value could be assumed and it would be the responsibility of the signer to redo the signing operation until the assumed hint value is correct.

Pieter's proposal is <signature+2bits>

[Gavin Andresen]

In an effort to keep discussion on track, I split the discussion of Lamport versus Bernstein signature schemes into its own thread.

So: can anybody think of any potential attacks that would be enabled by having a standard form:

Code:

DUP HASH160 <scripthash> EQUALVERIFY OP_EVAL

... spent by providing:

Code:

<signatures> <serialized script>

The simplest <serialized script> would be <pubkey> CHECKSIG.


Things that occur to me or were brought up in the IRC discussion:

• Denial-of-service if <serialized script> is allowed to contain OP_EVAL.
  
  Proposal on the table is to completely disallow recursion, which eliminates that threat.  I'm tempted to allow limited recursion (max 2 levels deep maybe) because it would allow some really cool things to be done in the future....
  
• Stealing coins because old miners/clients will not verify the signature hidden inside <serialized script>.
  
  If 50+% of the hashing power on the network support OP_EVAL, then transactions that pass the <scripthash> check but fail the signature check inside the <serialized script> would be accepted as valid by old miners and clients, but would fail to confirm because they would be rejected by the majority of miners.
  
  That CANNOT be used to trick exchanges or people using old software, because the old software will not recognize the new script form, and will simply ignore the transaction-- you will not get "0/unconfirmed" OP_EVAL transactions displayed in old versions of Bitcoin. Wrong again!  See casacius' excellent response.
  
• Creating or modifying <serialized scripts>
  
  Maybe there's an attack waiting to happen because an attacker could trigger a buffer overflow bug by doing something like:
  <safe serialized script>  119 OP_ADD  OP_EVAL
  But if there is a buffer overflow bug in an implementation's transaction script interpreter, then an attacker can almost certainly just send a "tx" message containing a non-OP_EVAL script that triggers the bug. OP_EVAL certainly does mean one more thing for an implementation to get right, but it isn't actually very hard to implement if you're already able to validate "tx" messages.
  

Any other attacks anybody can think of? If implementations are strict in which transaction forms they'll accept as "valid AND mine (counts towards my wallet balance)", but liberal in what transaction forms they'll accept as "valid, but I can't spend it" then it seems to me the risks are small.

[casascius]

That CANNOT be used to trick exchanges or people using old software, because the old software will not recognize the new script form, and will simply ignore the transaction-- you will not get "0/unconfirmed" OP_EVAL transactions displayed in old versions of Bitcoin.

The threat isn't that someone could send an OP_EVAL transaction directly to an old version of Bitcoin... rather, they would send two transactions.  They would construct a transaction that fakespends the OP_EVAL transaction to a temporary address, and then a standard transaction from the temporary address to the victim's address.  The old versions of Bitcoin would display the second transaction afaik, though updated miners would reject them both.

[Mike Hearn]

My view: the current Bitcoin design has been carefully reviewed and found to be strong. People like Kaminsky have tried their best and not discovered any issues.

Major structural design changes like OP_EVAL invalidate all those assurances and put Bitcoin back at square one. I'm not seeing the benefit. Disk space is cheap, and pruning would reclaim far more than shrinking transactions by a small amount. Lightweight clients don't even care.

If there are going to be changes to the basic design of the system, it'd be better to actually fork the chain and make people choose between the old/new rulesets. Old users would find transactions no longer confirm and peers disconnect them. Weird hacks like reusing a NOP risk silently invalidating the security properties of earlier versions without those users realizing, something none of those people would have anticipated.

The Bitcoin design Satoshi left has a ton of mileage left in it. There are surely more important problems to solve than a slightly better scripting system. A working bitcoin: URI handler would be a good start.

[casascius]

Major structural design changes like OP_EVAL invalidate all those assurances and put Bitcoin back at square one. I'm not seeing the benefit. Disk space is cheap, and pruning would reclaim far more than shrinking transactions by a small amount. Lightweight clients don't even care.

Just wanted to make sure it was clear that the purpose of OP_EVAL is not to save disk space.  It's to enable transactions to normal Bitcoin addresses that require a multi-sig script to be respent, without burdening the sender of the coins with the logistical challenge of providing that script to the block chain.  The multi-sig script significantly enhances security, because it enables arrangements where no one party (other than the owner) and/or no one machine has all of the key material in one place necessary to spend coins when they are received.  And, as you're surely aware, the reports of rampant Bitcoin theft have been a dark cloud that repels people from bitcoin.  This is a serious solution to that.

If Satoshi didn't intend for anything like this to be added, he wouldn't have had a reason to implement a scripting engine in the first place.  Transactions would just have "inputs" and "outputs" and nothing more.

[Gavin Andresen]

If Satoshi didn't intend for anything like this to be added, he wouldn't have had a reason to implement a scripting engine in the first place.  Transactions would just have "inputs" and "outputs" and nothing more.

He wouldn't have included NOP1 through NOP10, either.

I file this under "Satoshi is a genius, part 9,432".  It gives a smooth upgrade path using the same blockchain if ECDSA or SHA256 start to get fragile.

Attacking old clients by sending them coins with "will-never-be-satisfied-but-they-can't-tell-that" inputs is a concern-- it is basically the Finney attack, but anybody will be able to try to pull it off and there is no time constraint.

However, I think the benefits of being able to send to a truly secure address FAR outweigh the risks, I don't think it will be difficult to get people to upgrade to a newer, more secure client, and accepting 0- or 1-confirmation transactions is always a bad idea.

I also think you're exaggerating the impact-- OP_EVAL does not invalidate all of the security review that has been done so far, especially if the scripting language being EVAL'ed is unchanged from what we have today.

(PS: the latest git-head QT bitcoin contains a working bitcoin URI handler)

[ByteCoin]

Major structural design changes like OP_EVAL invalidate all those assurances and put Bitcoin back at square one.

I think this is an important point. Currently the analysis that we do is rather ad-hoc and reliant on us thinking of various exploits and how to prevent them. What we should do, as Mike implies is to look at what security guarantees the existing system provides and then systematically check that any proposed changes do not unexpectedly compromise those guarantees.

From the information given, and from the implementation of OP_EVAL that I imagine, I'm having trouble thinking of the assurances that are invalidated by OP_EVAL.

Could you please provide more details Mike?

ByteCoin

[Mike Hearn]

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.

[Pieter Wuille]

There are a few different issues here.

The first is the initiation of transactions. The OP_EVAL proposal above implies an address type of the form Base58(XXX + v), corresponding to a txout <OP_DUP OP_HASH160 <XXX> OP_EQUAL OP_EVAL>. This seems to be the primary reason for advocating OP_EVAL, and I'm not sure it should be. It is very powerful, but I keep believing that secondary protocols that negotiate a transaction output are the way to go (see this proposal for an idea). There may be some legitimate advantages as well though; Gregory had an example where hashed OP_EVAL scripts could be used to increase anonymity in case of OR-based outputs.

The second is the introduction of a new script language. By retrofitting OP_NOP1 as OP_EVAL, it does not necessarily need a block chain fork, and we have the ability to modify the semantics of the language. This has massive possibilities, and should be dealt with very carefully. This is independent from the introduction of a new address type - a simple <<script2> OP_EVAL> txout script can be used, with <script2> a txout script obtained through any means. I did a proposal for improvements to the script language here, but much more discussion is necessary before we do such a thing. Casascius' idea of two conflicting transactions makes me worry though - that may be enough to not use the OP_NOP-based mechanism at all.

[Gavin Andresen]

RE: 0-confirmation OP_EVAL transactions:

I think I'm doubly-wrong.

OP_EVAL transactions are non-standard to old clients, so they are dropped before being added to the memory pool.  Old clients will not relay them, old miners that follow the IsStandard rules won't put them in blocks.

When a transaction comes in that depends on a transaction that is not in the block chain or memory pool, it is shunted into the orphan transaction pool, and isn't listed by listtransactions or show up in the GUI until all of its inputs are satisfied.

The risk would be a rogue miner putting invalid OP_EVAL transactions into blocks, which would trick old clients into showing transactions that depend on them as 0/ or 1/unconfirmed.


RE: "but bitcoin addresses are UGLY and the WRONG way to do it!"

Okey dokey.  If I recall correctly, people were saying exactly the same thing about URLs 10 years ago (...google... yup).

If your argument is OP_EVAL is possibly insecure... it seems to me it is much easier to reason about the security of OP_EVAL than to reason about the security of URI schemes or schemes for passing around a transaction to be signed or using SIGHASH_ANYONECANPAY.

I agree that protocols for passing around either transactions or signatures are needed, I just don't think agreeing on what those protocols aught to be will happen anytime soon (how much you want to bet there will be a protocol buffers versus JSON debate that rages on for at least six months?)

RE: writing up a full design doc: I've always admired the IETF's "rough consensus and running code" approach to standards-making, so I'll be happy to write up a full design doc after I've got running code.  Actually trying to IMPLEMENT multisignature transactions has taught me a whole lot about what will work in practice and what won't.


Finally, to try (in vain, probably) to focus discussion:  The use cases I care about are:

1. A user running bitcoin on a device that gets infected by malware. I want them to be able to subscribe to some service that will provide transaction confirmation for any outgoing bitcoin transactions above a certain amount per day (like my bank does with my ATM card).

2. And I want them to be able to have a 'master wallet key' stored in physical form in their safe-deposit box so they can recover their wallet if they forget their passphrase or lose all their backups.

OP_EVAL appeals to me because I can see EXACTLY how to make those use-cases work with minor variations to the infrastructure we have today for performing bitcoin payments.

[Maged]

Scripting for multi-signature transactions should be fully implemented before OP_EVAL is considered. When multi-signature transactions are working, I believe people will come to realise that the "business need" for OP_EVAL is illusory.

I expect that any bitcoin-accepting business will provide a "simple" per-transaction receiving address. Then, when the transaction is complete, the business will transfer the BTC to a multi-signature address according to their business needs.

This is analogous to how it works in regular commerce. Day-to-day transactions are handled less formally by one person (but with internal controls). For example, the cashier at the bank or at the supermarket. Larger amounts are regularly transferred into bank accounts that require multiple signatures. It would be cumbersome if a store manager was not able to (e.g.) issue a small refund without involving all of the signatories of the main account.

Consider a business that has a PayPal account. Customers don't send their payment to a PayPal address that says "these funds can be accessed by any two out of three of: a@example.com, b@example.com, c@example.com". Instead, they send their PayPal payment to a simple PayPal receiving address, and the business's own procedures take care of it from there.

Similarly, when you pay by check you write the check out to the organization's name. You don't write it out to "any two directors or the company secretary". The organization itself puts those procedures in place internally.

Even banks have developed processes that enable a teller to handle cash.

Even if I'm wrong about the "business need" for OP_EVAL being illusory, OP_EVAL can comfortably be implemented at any later date, after we have good experience with how people actually use multi-signature Bitcoin scripts in the real world. To implement OP_EVAL up-front just adds the additional risk of "getting it wrong".

Except there's a huge problem in your logic: you're not thinking with portalsBitcoins...

Let's take your supermarket cashier. What if they never needed to give change and weren't authorized to provide refunds? Would businesses instead decide that a dropbox for the money instead of a register would be better? Say, then, that managers were allowed to give refunds. It would make sense to give the managers a key to each dropbox. However, managers also often steal, too. So, the manager could only open the box if a cashier or another manager was there (in case a manager was subing for a cashier), thus the need for multi-sig transactions. Each dropbox can be emptied into the owner's account nightly. As you can see, this meets an existing business need without exposing the money to the front-line cashier and making the customer worry about semantics.

Next, let's take your wonderful check example. It's the closest thing we have to what we're actually talking about.

Similarly, when you pay by check you write the check out to the organization's name. You don't write it out to "any two directors or the company secretary". The organization itself puts those procedures in place internally.

When you give an OP_EVAL address, that is exactly what you're doing. However, you're missing a crucial point: While it's true that the organization puts the procedures in place internally for accessing the funds, what's stopping some random employee from going to the bank to withdraw all the money anyway? The answer is: the bank itself. How does the bank know who can withdraw funds? Because you told them who could withdraw funds written out to the organization's name. OP_EVAL is the same. The customer doesn't need to worry about what names to put on the check, just the organization's name. Yet, that name maps to only certain people that can access the funds, not the entire organization.

[Disposition]

Finally, to try (in vain, probably) to focus discussion:  The use cases I care about are:

1. A user running bitcoin on a device that gets infected by malware. I want them to be able to subscribe to some service that will provide transaction confirmation for any outgoing bitcoin transactions above a certain amount per day (like my bank does with my ATM card).

2. And I want them to be able to have a 'master wallet key' stored in physical form in their safe-deposit box so they can recover their wallet if they forget their passphrase or lose all their backups.

OP_EVAL appeals to me because I can see EXACTLY how to make those use-cases work with minor variations to the infrastructure we have today for performing bitcoin payments.

Where I stand: I like OP_EVAL as a feature, but agrees with Mike's concerns.

Thoughts:
1. I want the technology(bitcoin network itself) to caress less of the human element as possible, in addition I feel these things can cared for not part of the network such as the Mastery Key, escrow generally suffers from the same problem imo, but that's more subjective.

2. Any big changes, especially on this level needs better communication between possibly the major pool administrators and the miner population to insure the changes propagate through the network and that people upgrade as needed, again this is another human element of the problem.

until proper and failsafe ways and upgrade method are introduced, I'm in the "hold off on radical changes" club.

[gmaxwell]

Thoughts:
1. I want the technology(bitcoin network itself) to caress less of the human element as possible, in addition I feel these things can cared for not part of the network such as the Mastery Key, escrow generally suffers from the same problem imo, but that's more subjective.

2. Any big changes, especially on this level needs better communication between possibly the major pool administrators and the miner population to insure the changes propagate through the network and that people upgrade as needed, again this is another human element of the problem.

until proper and failsafe ways and upgrade method are introduced, I'm in the "hold off on radical changes" club.

Whats been proposed here is a generic mechanism that would be useful even if we only had machine to machine transactions.  I'm not seeing how other mechanisms can provide what op_eval provides, especially not without having more parties to trust.  Can you elaborate further on this point?

There have been a number of proposals that would make this more safe to deploy, e.g. using a flag in the coinbase to perform a majority vote of hashpower to decide the height to enable the feature.  Someone obviously needs to talk to some of the bigger miners and see if they have other concerns that need to be addressed but I don't see why a hashpower vote isn't sufficient, since the feature is non-forking.

[Gavin Andresen]

There have been a number of proposals that would make this more safe to deploy, e.g. using a flag in the coinbase to perform a majority vote of hashpower to decide the height to enable the feature.  Someone obviously needs to talk to some of the bigger miners and see if they have other concerns that need to be addressed but I don't see why a hashpower vote isn't sufficient, since the feature is non-forking.

I pulled a Satoshi and decided to implement OP_EVAL to make sure it would actually work.
  https://github.com/gavinandresen/bitcoin-git/tree/op_eval

Not ready for pulling, expect rebasing/tweaking/changing. But it is fully working on the testnet.
(example transaction here)

The code puts "OP_EVAL" in the coinbase of generated blocks, so the rest of the network can see how many miners support it.

I gathered contact information for the top ten mining pools last week; when there is rough consensus on the details, I'll contact them to see if they have concerns and/or are willing to support OP_EVAL.

I started writing up BIPs for the various pieces of OP_EVAL, I'll post them soon.