Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CAAS2fgQAo-xxJxVtoXbTMZ3nvQvtiFxeqOKrN5-xxppMgmBdqg@mail.gmail.com>
Date: Fri, 28 Oct 2011 12:24:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <564C59F8-8077-4603-8EAC-389C30509F02@ceptacle.com>
References: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
	<CABsx9T3WKv3RLWT+Q6s7cCLzDL3sVRCWfmPiKcSp=_Re05m+zQ@mail.gmail.com>
	<CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
	<CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
	<7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
	<CAAS2fgTx8gEztUt-UrDObMCQtfdzZc52fzS6c1q8mm+a-TjwjQ@mail.gmail.com>
	<CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.com>
	<1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com>
	<CAAS2fgQAo-xxJxVtoXbTMZ3nvQvtiFxeqOKrN5-xxppMgmBdqg@mail.gmail.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
Precedence: list

> 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=97=

> create a trust that requires multiparty signoff=97 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!=20
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...=20

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

At least it challenges my esthetics...

Cheers,

M=