From: "Michael Grønager" <gronager@ceptacle•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
Date: Fri, 28 Oct 2011 12:24:21 +0200 [thread overview]
Message-ID: <564C59F8-8077-4603-8EAC-389C30509F02@ceptacle.com> (raw)
In-Reply-To: <CAAS2fgQAo-xxJxVtoXbTMZ3nvQvtiFxeqOKrN5-xxppMgmBdqg@mail.gmail.com>
> 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
next prev parent reply other threads:[~2011-10-28 10:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 10:49 Mike Hearn
2011-10-25 13:21 ` Gavin Andresen
2011-10-25 14:49 ` Gregory Maxwell
2011-10-25 16:47 ` Alan Reiner
2011-10-26 8:58 ` Michael Grønager
2011-10-26 14:03 ` Gregory Maxwell
2011-10-26 15:00 ` Gavin Andresen
2011-10-27 7:32 ` Michael Grønager
2011-10-27 9:08 ` Gregory Maxwell
2011-10-28 10:24 ` Michael Grønager [this message]
2011-10-29 17:01 ` Gavin Andresen
2011-10-31 8:50 ` Michael Grønager
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564C59F8-8077-4603-8EAC-389C30509F02@ceptacle.com \
--to=gronager@ceptacle$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox