Bitcoin Forum
December 03, 2016, 02:37:51 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: OP_EVAL proposal  (Read 10839 times)
Lolcust
Member
**
Offline Offline

Activity: 112


Hillariously voracious


View Profile
November 07, 2011, 06:57:09 PM
 #61

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

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!  Cheesy )

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.

Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse Wink

Feed the Lolcust!
NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67
BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M
GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
1480732671
Hero Member
*
Offline Offline

Posts: 1480732671

View Profile Personal Message (Offline)

Ignore
1480732671
Reply with quote  #2

1480732671
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 07, 2011, 07:50:39 PM
 #62

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Lolcust
Member
**
Offline Offline

Activity: 112


Hillariously voracious


View Profile
November 07, 2011, 08:16:20 PM
 #63

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.

Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse Wink

Feed the Lolcust!
NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67
BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M
GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
jojkaart
Member
**
Offline Offline

Activity: 97


View Profile
November 07, 2011, 08:36:37 PM
 #64

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
Member
**
Offline Offline

Activity: 112


Hillariously voracious


View Profile
November 07, 2011, 10:18:56 PM
 #65

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 Cheesy

Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse Wink

Feed the Lolcust!
NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67
BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M
GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 07, 2011, 11:18:49 PM
 #66

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Lolcust
Member
**
Offline Offline

Activity: 112


Hillariously voracious


View Profile
November 08, 2011, 09:36:52 PM
 #67

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.

Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse Wink

Feed the Lolcust!
NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67
BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M
GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
May 18, 2013, 06:38:04 PM
 #68

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.

ROI is not a verb, the term you're looking for is 'to break even'.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
May 19, 2013, 03:44:20 AM
 #69

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
crazy_rabbit
Legendary
*
Offline Offline

Activity: 1162


RUM AND CARROTS: A PIRATE LIFE FOR ME


View Profile
May 23, 2013, 11:24:47 PM
 #70

Is OP_EVAL functional on testnet?

more or less retired.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
May 24, 2013, 02:50:07 PM
 #71

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!