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.
Topic: OP_EVAL proposal (Read 13117 times)
Pay-to-script-hash (P2SH) is functional on testnet and mainnet. OP_EVAL has long been superceded and discarded.
Is OP_EVAL functional on testnet?
Most if not all of the real world use cases for OP_EVAL are handled by P2SH.
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.
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.
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.
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.
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.
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
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
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...
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.
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.
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.
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! )
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.
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! )
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.
Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)
I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail
With OP_EVAL, the fees for inputs will stay with the sender, while the fees for the output are moved to the receiver (who'll pay them when he uses them as inputs). So what OP_EVAL does is make everyone responsible for their own stuff.
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!
) 
Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)
I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail
With OP_EVAL, the fees for inputs will stay with the sender, while the fees for the output are moved to the receiver (who'll pay them when he uses them as inputs). So what OP_EVAL does is make everyone responsible for their own stuff.
fair enough, now i understood what what was meant with that feature. This will enable all merchants treat sub cent amounts like any other quantity, not having to take fees into consideration.
Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)
I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail
With OP_EVAL, the fees for inputs will stay with the sender, while the fees for the output are moved to the receiver (who'll pay them when he uses them as inputs). So what OP_EVAL does is make everyone responsible for their own stuff.
This addresses theymos' concern that senders shouldn't be burdened with extra fees from longer scriptPubKeys. Instead, for more complex transactions, the scriptSig is longer which means that the owner of the address bears the cost of potentially increased fees.[/li][/list]
Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)
I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail
Addresses for arbitraritly complex transactions are fixed forever. No more new address types need be introduced.
In my very humble opinion, giving "new and exciting" types of BTC transactions a different address type (either as "catch-all" for all innovative transactions or have a separate address type for each "officially supported" new transaction type,) to avoid confusion and help people grok new and fairly complicated functionality more easily.
Methinks that different addresses for exotic transactions will actually increase usability, especially for "the kind of person" who only lives in GUI and won't touch the user manual
unless ABSOLUTELY necessary You can do the RS code over the digits directly. It's so much nicer if the base is a 2^n however. 
E.g. if we were using a base 64 the implementation of the encoder (/checker) would be just a few lines of code and a table.
E.g. if we were using a base 64 the implementation of the encoder (/checker) would be just a few lines of code and a table.Ah, that's good. When I was looking around for different RS implementations, I saw it written somewhere that it requires base 2^n. Good to know this isn't the case. I'm looking forward to seeing your code
- Joel
the base-58 encoding slightly degrades the effectiveness in some cases, though. With base-58 encoding, it's entirely possible to get 2 byte error in the decoded content with an error in just one unlucky position in the base-58 encoded string.
Individual base58 characters don't map to sections of bits, so any error would change every single byte in the decoded data. Some special error correcting code is need here; I don't think normal ones apply if base58 is used.
You can do the RS code over the digits directly. It's so much nicer if the base is a 2^n however.
E.g. if we were using a base 64 the implementation of the encoder (/checker) would be just a few lines of code and a table.the base-58 encoding slightly degrades the effectiveness in some cases, though. With base-58 encoding, it's entirely possible to get 2 byte error in the decoded content with an error in just one unlucky position in the base-58 encoded string.
Individual base58 characters don't map to sections of bits, so any error would change every single byte in the decoded data. Some special error correcting code is need here; I don't think normal ones apply if base58 is used.
Personally, I'd like to see the checksum being done with error correcting codes, like reed-solomon codes. Not because it improves error detection but because it allows for automatic error recovery. 4 bytes of reed-solomon code would be enough to fix up to 2 bytes of error in the address. Error detection would be guaranteed for up to 4 bytes of error.
the base-58 encoding slightly degrades the effectiveness in some cases, though. With base-58 encoding, it's entirely possible to get 2 byte error in the decoded content with an error in just one unlucky position in the base-58 encoded string.
This is not all that important for the functioning of the system but it would be more user friendly for those who have to type the address in manually for whatever reason. This way, the system could handle a typo or two without requiring the user to retype the address. To me, this looks like a choice to the same direction as choosing base-58 encoding instead of base-64 was.
- Joel
the base-58 encoding slightly degrades the effectiveness in some cases, though. With base-58 encoding, it's entirely possible to get 2 byte error in the decoded content with an error in just one unlucky position in the base-58 encoded string.
This is not all that important for the functioning of the system but it would be more user friendly for those who have to type the address in manually for whatever reason. This way, the system could handle a typo or two without requiring the user to retype the address. To me, this looks like a choice to the same direction as choosing base-58 encoding instead of base-64 was.
- Joel
Jump to: