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
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1RIkA9-0005oF-S5
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 16:47:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=etotheipi@gmail.com;
helo=mail-wy0-f175.google.com;
Received: from mail-wy0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RIkA8-00015G-UH
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 16:47:41 +0000
Received: by wyg19 with SMTP id 19so1037153wyg.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Oct 2011 09:47:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.202.149 with SMTP id fe21mr4700366wbb.15.1319561254102;
Tue, 25 Oct 2011 09:47:34 -0700 (PDT)
Received: by 10.180.95.34 with HTTP; Tue, 25 Oct 2011 09:47:34 -0700 (PDT)
In-Reply-To: <CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
References: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
<CABsx9T3WKv3RLWT+Q6s7cCLzDL3sVRCWfmPiKcSp=_Re05m+zQ@mail.gmail.com>
<CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
Date: Tue, 25 Oct 2011 12:47:34 -0400
Message-ID: <CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=000e0cdf690ecf6d1804b0224bc5
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RIkA8-00015G-UH
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: Tue, 25 Oct 2011 16:47:41 -0000
--000e0cdf690ecf6d1804b0224bc5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell@gmail.com>wrote=
:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider=97 It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that the=
y
will notify you of transacitons that include you, I don't see anything wron=
g
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you o=
n
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
--000e0cdf690ecf6d1804b0224bc5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwel=
l <span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmai=
l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <<a hr=
ef=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote=
:<br>
> You give the hash to whoever is paying you, and store the hash --><=
br>
> script =A0mapping when you do that (assuming you're not using a<br=
>
> deterministic wallet; if you are, you probably just increment a<br>
> counter in the wallet).<br>
<br>
</div>If anyone finds that solution unsatisfying, consider=97 It's alre=
ady the<br>
case that I could take one of your disclosed public keys and create an<br>
infinite series of secondary keys out of it for which only you could<br>
decode, and the only way for you to find them in the blockchain would<br>
be to have performed the same procedure and made a note of the<br>
addresses you're watching for.<br><br></blockquote><div><br></div><div>=
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for=
multi-signature transactions. =A0It sounds like to me, that you can still =
use the regular OP_CHECKMULTISIG if you are concerned about these things. =
=A0If you're dealing with too many parties with questionable reliabilit=
y that they will notify you of transacitons that include you, I don't s=
ee anything wrong with declaring that you'd only prefer dealing with OP=
_CMS transactions and not OP_EVAL (besides some grumbling from them that th=
eir way is "better"). =A0 Either way, they're screwing themse=
lves, too, if they want to include you on transactions and don't notify=
you as such (kind of defeats the purpose of multi-sig txs).</div>
<div><br></div><div>(2) I think it's unnecessary to discuss cases where=
you somehow lose your mappings but not your private keys. =A0In order for =
OP_EVAL scripts to work, the subscripts/mappings are *just as important* as=
your regular private keys. =A0They should be kept in your wallet forever j=
ust like your private keys--and thus you lose none of them or all of them. =
=A0The only real difference is that they aren't sensitive like your pri=
vate keys, so they don't have to be encrypted.</div>
<div><br></div><div>(3) There should most definitely be a button on the mai=
n client that allows you to "Add OP_EVAL script" or something alo=
ng those lines (maybe something with a less obscure name). =A0We need to ma=
ke it as easy as possible for someone to add such a script/mapping to their=
wallet. =A0Although, this invites a breach of one of my core rules of user=
interfaces: =A0if the functionality is dependent on the user performing so=
me regular maintenance task, you better be prepared for all users to fail a=
t doing it. =A0Even diligent users are going to forget/mess-up sometimes. =
=A0If failure at performing this task results in breaking the client or los=
ing money, we should avoid promoting that usage paradigm.</div>
</div><br>
--000e0cdf690ecf6d1804b0224bc5--
|
