Quote from: theymos on November 07, 2011, 07:50:39 PM

Quote from: Lolcust on November 07, 2011, 06:57:09 PM

I'd still prefer "new and brave" transactions to use a different address format though.

Then every merchant will have to update clients whenever users want to use a new transaction type. With OP_EVAL, a merchant could keep running the same version for years (assuming there are no bugs) and still send transactions using the latest scripts.

Pardon if I am being slow, but does OP_EVAL allow for crafting new and wonderful transaction type through RPC ?

I thought that every new exotic transaction implemented by this way will still require one to implement it in the code and compile...

Quote from: theymos on November 07, 2011, 07:50:39 PM

It also improves decentralization, since there will be no need to coordinate assignment of address version numbers. (And there are only 256 address version numbers to assign -- too few to cover all scripts.)

Quite frankly, the implications of having more than 10 (let alone more than 256) distinct transaction types, each with unique "quirks" in operation, are disturbing.

The GUI will end up being like a fighter jet cockpit, for one.

I'd still like to have at least two distinct address forms, one for "simpleton" transactions (like what we have now), another for everything else, just to make demarcation between "basic" functionality and "advanced user features" more explicit. Because you know, people have trouble grokking Paypal interface (and bitcoin GUI), and having them away from getting involved with complicated 5-party signing schemes until they really know what they are doing would be wise.

Quote from: theymos on November 07, 2011, 07:50:39 PM

People who request an OP_EVAL transaction will know exactly how many extra bytes it will take to redeem the transaction. They shouldn't be surprised by fees.

With all due respect, you overestimate the average user.