1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
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 <gronager@ceptacle.com>) 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?= <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>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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=
|
