From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RJjc2-0007Nr-Ij for bitcoin-development@lists.sourceforge.net; Fri, 28 Oct 2011 10:24:34 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RJjc1-0007zB-1d for bitcoin-development@lists.sourceforge.net; Fri, 28 Oct 2011 10:24:34 +0000 Received: from [192.168.0.15] (2508ds5-oebr.0.fullrate.dk [95.166.54.87]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9SAOLY1028633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Oct 2011 12:24:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Fri, 28 Oct 2011 12:24:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <564C59F8-8077-4603-8EAC-389C30509F02@ceptacle.com> References: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com> <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com> To: Gregory Maxwell X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RJjc1-0007zB-1d Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 10:24:34 -0000 > 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=