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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CE11990
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 07:39:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3986E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 07:39:56 +0000 (UTC)
Received: by wicll6 with SMTP id ll6so61110077wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 00:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-type; bh=ELv58C6ORMSz0Giq540UCs6TecRw/GZcwRP8INyoh+c=;
b=oh52ZmPzYUk6QzgwVdR4iSHVjWRuhVIVCb24T3CnMLx2YWRNFz7ki4tpiGaYze1afR
joQq/YFjZqzcCJzQcFyiHBhZJMkVUq4nAD3U1vf2hsRZ2cpb4gQfnKmxwl/x6lUTxOqh
OnNIX271aeVfYXiBBXqMCP14Gv/9obmA3mWlXHD6/PqrvABDewn55Fh8RlGPzsXYZvvq
qTtrY2TvXZrqml2Auxdtxh4YfJhCxdy24tMj17K63pwovGDvflbsS97e9AMcSg8Aud4a
E2Km+z4KsarX/O95oOUUaxmCfjiPKJYk1IcNTPfaNAt0zqwKqluAafCQuOVR19lA/dUU
6xtg==
X-Received: by 10.180.206.230 with SMTP id lr6mr9665346wic.69.1445413195262;
Wed, 21 Oct 2015 00:39:55 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510210618.56159.luke@dashjr.org>
In-Reply-To: <201510210618.56159.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 07:39:45 +0000
Message-ID: <CALxbBHVdXrdh6fdSyLdkPP_D4MSbofOr01kc9L9QuQTWZ33N1w@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c3877e0eaf7b0522987c03
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 07:39:57 -0000
--001a11c3877e0eaf7b0522987c03
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:
> On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev
> wrote:
> > The proposal is implemented (see below), by computing the normalized
> > transaction ID when adding them to the UTXO and storing them along with
> the
> > coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> > OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> > how to best refactor the common functionality into reusable blocks. And
> the
> > annotating incoming transactions with their normalized inputs is a bit
> > cumbersome, maye somebody has some pointers here as well?
> This doesn't completely close malleability (which should be documented in
> the
> BIP), so I'm not sure it's worth the cost, especially if closing
> malleability
> later on would need more. How about specifying flags upfront in the UTXO-
> creating transaction specifying which parts the signature will cover? This
> would allow implementation of fully malleability-proof wallets.
>
As far as I see it the only remaining venues for malleability are the use
of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use
of non-sighash_all flags is already an explicit permission to modify the
transactions, by adding and removing inputs and outputs, so I don't see how
these can be made non-malleable. Am I missing something?
>
> Additionally, you have a flag to control whether the opcode behaves as
> VERIFY
> or not. Non-VERIFY is not possible as a softfork (without doing a
> second/new
> P2SH) since it can be negated.
>
Yes, this is my mistake and has been pointed out in the PR, I will amend
the PR to make the verify flag mandatory, which also guarantees that the
top of the stack contains a non-null element, thus resulting in a
successful evaluation on non-updated clients.
>
> Luke
>
--001a11c3877e0eaf7b0522987c03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 21=
, 2015 at 8:19 AM Luke Dashjr <<a href=3D"mailto:luke@dashjr.org">luke@d=
ashjr.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monda=
y, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:<br>
> The proposal is implemented (see below), by computing the normalized<b=
r>
> transaction ID when adding them to the UTXO and storing them along wit=
h the<br>
> coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and<br>
> OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointer=
s into<br>
> how to best refactor the common functionality into reusable blocks. An=
d the<br>
> annotating incoming transactions with their normalized inputs is a bit=
<br>
> cumbersome, maye somebody has some pointers here as well?</blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
This doesn't completely close malleability (which should be documented =
in the<br>
BIP), so I'm not sure it's worth the cost, especially if closing ma=
lleability<br>
later on would need more. How about specifying flags upfront in the UTXO-<b=
r>
creating transaction specifying which parts the signature will cover? This<=
br>
would allow implementation of fully malleability-proof wallets.<br></blockq=
uote><div><br></div><div>As far as I see it the only remaining venues for m=
alleability are the use of sighash flags that are not SIGHASH_ALL, as menti=
oned in the BIP. Any use of non-sighash_all flags is already an explicit pe=
rmission to modify the transactions, by adding and removing inputs and outp=
uts, so I don't see how these can be made non-malleable. Am I missing s=
omething?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally, you have a flag to control whether the opcode behaves as VERI=
FY<br>
or not. Non-VERIFY is not possible as a softfork (without doing a second/ne=
w<br>
P2SH) since it can be negated.<br></blockquote><div><br></div><div>Yes, thi=
s is my mistake and has been pointed out in the PR, I will amend the PR to =
make the verify flag mandatory, which also guarantees that the top of the s=
tack contains a non-null element, thus resulting in a successful evaluation=
on non-updated clients.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<br>
Luke<br>
</blockquote></div></div>
--001a11c3877e0eaf7b0522987c03--
|
