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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C7B8F1BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 00:34:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com
[209.85.220.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32154238
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 18 Aug 2016 00:34:05 +0000 (UTC)
Received: by mail-qk0-f179.google.com with SMTP id t7so3467727qkh.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 17:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=qJGkPo/dy44zX9w11FfccBwRto/RkfzydR186Y4IKic=;
b=JM+on/U0e3+LzoCLAEZST05SopKF2wY0wouD5wPmFRLqU5bncmPUZHTs9AyejLRlxT
sNM+oUsxd8zLD+AA8ucmnJaPuuRI8PNWcjSz2ig6sPW55yM559+u7O1dkJPwkVRbq84n
YNafvWzJb5S31He9Tc6DVToiOWr8eoXajwgaHhpDnuqwk6ZVPX31uMe/02UtMd7iHU/b
3nygkipVoVq1L6JeIglwjqDTq7Ng9eWZhn6hkSqBgpGbeddX3X926tbZXsFWyzr0jna9
0dCawExp4KSbPS3FF3Z5YBJKIWX+IY7N7MSm3w+BX8I8zJOAsPYeI3pVlxxwxdx4wyPX
vr/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=qJGkPo/dy44zX9w11FfccBwRto/RkfzydR186Y4IKic=;
b=YNpuT9vLTUVTkrusXt9S/lSrfcrK17KcX7ikustRNIqVE2dhCTN7VoDIwp6w2Z5NE8
WK7a3cmPYW05QWdZL+2HRl0vaamox8mutjH4MmzXzRitpcouWKNkS7+IsI6c2FhhPRCn
iILhxPS7UorylPj3vR5M05P40Gk7JK97rMIxz6LydZZc8YQf9sfGYBq2PzHGpDQQZyox
jiD+bmRb4dyHtt9joFbkTFfnYu8DRRSPm7PEmVFH2PnAiy4DrIanDPwhg0cnQsEHTyZH
cG4it4axvDY/nEDpDqFGwW9Hjkt7WzBoENW6F6lnlte95oexOUdyTQH4ejTGvDu4O5sM
QpgQ==
X-Gm-Message-State: AEkoouve7zahxFb33WqEK0SE31CsFaTU1bR40go/MMcCw5xTuQb2DDs5bVw+OWfTUO+Ur+0QY5VG1d65WWaroQ==
X-Received: by 10.55.5.17 with SMTP id 17mr48162700qkf.279.1471480444467; Wed,
17 Aug 2016 17:34:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.221 with HTTP; Wed, 17 Aug 2016 17:33:24 -0700 (PDT)
In-Reply-To: <CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
<976728541.94211.1471402973613@privateemail.com>
<201608170440.35767.luke@dashjr.org>
<703193091.96057.1471428948569@privateemail.com>
<CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>
<CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Wed, 17 Aug 2016 21:33:24 -0300
Message-ID: <CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11488a682fbd5c053a4dbdbf
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 18 Aug 2016 00:34:05 -0000
--001a11488a682fbd5c053a4dbdbf
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I think that we're not attacking the real source of the problem: that the
> > witness data size is not signed.
>
> It's not possible to do that for the general case, since you may not
> even know the witness size in advance (even for checksig's ECDSA, the
> encoding is variable sized).
>
> That's why scripts can check a maximum witness size, and not necessarily
an exact value.
I think that is overly focusing on "someone might change the feerate",
> yes that is an example of an undesirable witness tampering, but it's
> not the only one.
>
> I don't think fees are the problem. There is another problem. Let me
re-explain.
If I send a transaction to an IoT device (say to an OpenDime or to the old
Firmcoin), and the OpenDime must verify that the transaction has been mined
(SPV verification), then it may expect the witness program to be of certain
maximum size (an implementation-imposed limit). If a Miner modifies the
witness size and makes it too large, then the device may not be able to
accept the transaction and the bitcoins may be lost. Lost because the
private key is in the device, and because the device cannot accept that
cloned transaction, never ever.
The same is true (although less strict) for side-chains and drive-chains:
they may have certain restrictions on the size of transactions they accept
to lock bitcoins.
That's why I'm proposing that a transaction becomes INVALID if the witness
size is higher than the expected size (by the sender).
--001a11488a682fbd5c053a4dbdbf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <span dir=3D"ltr"><=
<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On=
Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
> I think that we're not attacking the real source of the problem: t=
hat the<br>
> witness data size is not signed.<br>
<br>
</span>It's not possible to do that for the general case, since you may=
not<br>
even know the witness size in advance (even for checksig's ECDSA, the<b=
r>
encoding is variable sized).<br>
<br></blockquote><div>That's why scripts can check a maximum witness si=
ze, and not necessarily an exact value.<br><br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
I think that is overly focusing on "someone might change the feerate&q=
uot;,<br>
yes that is an example of an undesirable witness tampering, but it's<br=
>
not the only one.<br>
<br>
</blockquote></div>I don't think fees are the problem. There is another=
problem. Let me re-explain. <br>If I send a transaction to an IoT device (=
say to an OpenDime or to the old Firmcoin), and the OpenDime must verify th=
at the transaction has been mined (SPV verification), then it may expect th=
e witness program to be of certain maximum size (an implementation-imposed=
=C2=A0 limit). If a Miner modifies the witness size and makes it too large,=
then the device may not be able to accept the transaction and the bitcoins=
may be lost. Lost because the private key is in the device, and because th=
e device cannot accept that cloned transaction, never ever.<br><br>The same=
is true (although less strict) for side-chains and drive-chains: they may =
have certain restrictions on the size of transactions they accept to lock b=
itcoins.<br><br></div><div class=3D"gmail_extra">That's why I'm pro=
posing that a transaction becomes INVALID if the witness size is higher tha=
n the expected size (by the sender).<br><br></div><div class=3D"gmail_extra=
"><br></div></div>
--001a11488a682fbd5c053a4dbdbf--
|
