OP_EVAL proposal

[Lolcust]

Ah, now IC the rational core of the concern, no need to bother theymos

However... How does the receiver get to know what his fees will be like ?

Let's say I want you to send me an escrow-OP_EVAL transaction. I want you to send, like... oh, 5 BTC.

It would be very unkosher if there would be no way for me to know in advance what fee to expect "on my end" after the escrow authority signs stuff (oh noes, it ated 3 BTC out of 5!  )

I expect it'll be dependent on the size of the transaction needed to use the OP_EVAL output. That has to be known in advance, otherwise you can't create a spendable OP_EVAL output. Of course, the actual fees will depend on the democratic (well, more or less) decisions from the miners.

Well, as long as it essentially ends up being dependent on something deterministic - like "output"'s size, it should be fine.

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

[1714113727]

1714113727

[1714113727]

1714113727

[1714113727]

1714113727

[theymos]

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.

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.)

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.

[Lolcust]

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...

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.
 

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.

[jojkaart]

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...

No, OP_EVAL allows the person paying to pay the recipient (who has provided the address) by any transaction type imaginable. That is, even without any support for the particular transaction type in the payer's wallet. That's because OP_EVAL makes it unnecessary for the wallet software to understand the output.

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.

Because OP_EVAL encodes the transaction type in the address itself, no-one ever needs to receive transaction types they don't support. So wallet software can pick and choose. With OP_EVAL the wallet software creator is free to choose which transactions it can handle and ignore others (because, well, you just won't give out any addresses for transactions you don't support).

Important thing to note here is the separation of wallet and node. Node needs to be able to handle the scripts of any transactions that are possible. However, wallet software doesn't have this need.

[Lolcust]

Well, Gavin explained in #bitcoin-dev that the plan is actually to have two addresstypes, one for "vanilla" old-timer transactions, and another as catch-all for "advanced" OP_EVAL stuff, which is something I am quite fine with.

Now, the transaction type pluralism is mildly disturbing. People manage to terribly screw up (and whine) with just one transaction type exposed to them and supported on all client soft, I can only imagine the magnitude of chaos when there is a whole load of divergent transaction types with affinity to a particular type of wallet software.

Good thing BTC is not a corporation. We'd have to hire entire India and most of Ukraine for tech support

[theymos]

The average user won't have to worry about it. If you enable the feature where a second device is required for spending, the client will just start giving you addressversion-1 addresses. You won't notice any other change, since the client will handle everything.

[Lolcust]

I think you slightly misunderstand me here. I definitely can see multisigns being fairly user-transparent and friendly.

256+ "exotic" transaction types ? not so much. But I guess it is best to start discussing the issue when a lot of "exotic" stuff starts popping up.

As long as exotica goes to a separate addresstype and Auntie can keep sending coins the old way, oblivious to the "pro stuff", I am okay.

[mmeijeri]

Bump.

I know the proposal has been withdrawn, but I wondered if people thought OP_EVAL should be implemented some day, perhaps far in the future.

[maaku]

Most if not all of the real world use cases for OP_EVAL are handled by P2SH.

[crazy_rabbit]

Is OP_EVAL functional on testnet?

[jgarzik]

Is OP_EVAL functional on testnet?

Pay-to-script-hash (P2SH) is functional on testnet and mainnet.  OP_EVAL has long been superceded and discarded.