Michael Grønager [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-28 🗒️ Summary of this message: OP_EVAL may not ...
đź“… Original date posted:2011-10-28
🗒️ Summary of this message: OP_EVAL may not be essential to Bitcoin, and there are concerns about the complexity it adds to transactions and the lack of transparency for recipients.
đź“ť Original message:> Could you suggest how else we could gain the advantages of op_eval
> without it? How can I secure my wallet under whatever scheme I like—
> create a trust that requires multiparty signoff— and securely have
> senders pay into it without expecting them all to handle some rare and
> complicated procedure for sending to me?
Yes - by the burdensome address ;) - which I am not sure I consider that much of a trouble, for practical uses... Anyway, it could just be added to the URI scheme and then it would still only be a click away.
> but it
> seems to me that there is a serious misunderstanding that there is a
> bijection between hash160s and public keys, and one between ECC
> private keys and spendable transactions, and that this bijection is
> desirable or even essential to bitcoin.
So far we had by the standard transactions a nice bijection, I do however, share your concern for other and more rich scripting... And here we need to make some choices!
Do we want to keep this notion of transactions between addresses or do we want to start unfold the richness of the scripting - I am not sure we actually gain that much from OP_EVAL and the extra scripting. And what bothers me is that you then cannot define a set of data (be that key, scripts or whatever) from which you can obtain all possible txes send to you. If I e.g. looses this argument and want to donate a beer to each of you and Gavin, that I want you to drink together. I would make a "both of two" btc-addresses script transaction using OP_EVAL. And post it.
You would then not be able to know that you actually got a beer unless I told you so in a mail.
This means that we move from a setup where transactions needs not only to be asked for but also they need to be announced by the sender. I don't like this...
Further, if you make a uint160 from a OP_EVAL script and post this as a bitcoin address - the user should then know that this was a special address - otherwise he would be sending money nowhere. I agree that this could be encoded into the bitcoin address using e.g. a 2... instead of a 3..., but as you mention yourself this is only the start of the OP_EVAL uses and hence you would need a whole series of strange numbering to define what script a specific address was referring to.
At least it challenges my esthetics...
Cheers,
M
🗒️ Summary of this message: OP_EVAL may not be essential to Bitcoin, and there are concerns about the complexity it adds to transactions and the lack of transparency for recipients.
đź“ť Original message:> Could you suggest how else we could gain the advantages of op_eval
> without it? How can I secure my wallet under whatever scheme I like—
> create a trust that requires multiparty signoff— and securely have
> senders pay into it without expecting them all to handle some rare and
> complicated procedure for sending to me?
Yes - by the burdensome address ;) - which I am not sure I consider that much of a trouble, for practical uses... Anyway, it could just be added to the URI scheme and then it would still only be a click away.
> but it
> seems to me that there is a serious misunderstanding that there is a
> bijection between hash160s and public keys, and one between ECC
> private keys and spendable transactions, and that this bijection is
> desirable or even essential to bitcoin.
So far we had by the standard transactions a nice bijection, I do however, share your concern for other and more rich scripting... And here we need to make some choices!
Do we want to keep this notion of transactions between addresses or do we want to start unfold the richness of the scripting - I am not sure we actually gain that much from OP_EVAL and the extra scripting. And what bothers me is that you then cannot define a set of data (be that key, scripts or whatever) from which you can obtain all possible txes send to you. If I e.g. looses this argument and want to donate a beer to each of you and Gavin, that I want you to drink together. I would make a "both of two" btc-addresses script transaction using OP_EVAL. And post it.
You would then not be able to know that you actually got a beer unless I told you so in a mail.
This means that we move from a setup where transactions needs not only to be asked for but also they need to be announced by the sender. I don't like this...
Further, if you make a uint160 from a OP_EVAL script and post this as a bitcoin address - the user should then know that this was a special address - otherwise he would be sending money nowhere. I agree that this could be encoded into the bitcoin address using e.g. a 2... instead of a 3..., but as you mention yourself this is only the start of the OP_EVAL uses and hence you would need a whole series of strange numbering to define what script a specific address was referring to.
At least it challenges my esthetics...
Cheers,
M