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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1RJLxM-0000fh-0v
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 09:09:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
helo=mail-qw0-f47.google.com;
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RJLxL-00058L-7z
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Oct 2011 09:08:59 +0000
Received: by qam2 with SMTP id 2so3025161qam.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Oct 2011 02:08:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.69.168 with SMTP id z40mr782442qci.261.1319706533800; Thu,
27 Oct 2011 02:08:53 -0700 (PDT)
Received: by 10.229.21.135 with HTTP; Thu, 27 Oct 2011 02:08:53 -0700 (PDT)
In-Reply-To: <1089B122-1274-454C-9097-700D392BF0FA@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>
Date: Thu, 27 Oct 2011 05:08:53 -0400
Message-ID: <CAAS2fgQAo-xxJxVtoXbTMZ3nvQvtiFxeqOKrN5-xxppMgmBdqg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RJLxL-00058L-7z
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: Thu, 27 Oct 2011 09:09:00 -0000
(taking this a bit out of order)
On Thu, Oct 27, 2011 at 3:32 AM, Michael Gr=C3=B8nager <gronager@ceptacle.c=
om> wrote:
> OK, let me try to explain what I see is the problem:
[snip]
> This, I find a nice and clean setup, where cryptographic keys can be mapp=
ed to assets.
From my perspective that clean boundary remains: Functionally the
script is part of the cryptographic key.
[snip]
> except if you also have the knowledge of the script that was used.
Which you must.
I can see no functional difference than if you said of the current
system "except if you also have knowledge of the final 32 bits of the
ECC private key".
I don't see any reason to expect clients to identify funds without
knowing the information required=E2=80=94 it's impossible. I mean, sure, yo=
u
_could_ bruteforce the final 32 bits of your private key=E2=80=94 or you co=
uld
attempt to try the cartesian product of every key you have with every
key seen in the block chain for finding an op_eval script. But thats
unworkable, unnecessary, equally bad for all client types, and not
being suggested. Under either system a coin is not yours unless you
know all of the right bits=E2=80=94 knowing some is not good enough.
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=E2=80=
=94
create a trust that requires multiparty signoff=E2=80=94 and securely have
senders pay into it without expecting them all to handle some rare and
complicated procedure for sending to me? (Or a burdensome address
which serializes a script and a large amount of data into hundreds of
characters, and which still may be unable to represent the rules I
wish to have govern my account=E2=80=94 and which the sender might mutate=
=E2=80=94
e.g. twiddling the threshold counts=E2=80=94 and cause me great
problems/confusion)
[snip]
> So far we the bitcoin addresses are (for all practical purposes) a one-to=
-one mapping between a pubkey and uint160. This mean that your wallet is de=
fined solely by your privatekeys (from which you can extract pubkeys and th=
en uint160 btc-addresses).
[snip]
> I agree that it will work and I (and bitcoin-js and blockexplorer) can of=
change the concept of a wallet to also include scripts, but it breaks an i=
ntrinsic logic of uint160s and transactions that has so far been quite nice=
and clean.
>
> So I also support checkmultisig to be the standard transaction type, but =
I do not appreciate the support of OP_EVAL.
On the basis of the discussion here I now oppose checkmultisig as a
standard transaction type. (Sorry, I'm not trying to be a jerk if it
came off that way, I'm not opposing it simply because you support it:)
The advantage I saw of having it was faster deployment for the
explicit escrow cases that don't need to encode the payment rules in
an address (as is needed for wallet security and trusts)... 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.
I'm concerned that this misunderstanding will moot the flexibility of
the script system because every script that doesn't look like a direct
mapping of hash160->pubkey->payee will be regarded as _broken_=E2=80=94 not
just useless to one app or another which could have simply chosen not
to generate those addresses=E2=80=94 but actually incompatible with bitcoin=
,
as is basically being argued here=E2=80=94 or, keeping in mind that people =
can
freely mine non-standard transactions, could this result in tools
which are rendered insecure by unexpected transaction types=E2=80=94 Will a
system that thinks HASH160 =3D IDENTITY recognize that a script which
also requires an additional secret key on the stack is unspendable?
Keeping checkmultisig alone as a standard transaction, when it's
functionally a redundant subset of OP_EVAL (and inferior because it
reduces the txn you can place in a block) could only further that
misunderstanding. :-/
|
