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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C957E93D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 22:30:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDBD3121
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 22:30:54 +0000 (UTC)
Received: by mail-ua0-f174.google.com with SMTP id k90so145553299uak.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 15:30:54 -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;
bh=Dpu/3cog1ZhO/11vkcFHZ+yd4tbnW5WB2gbhdp2RIOs=;
b=TKVeb5/y5+yYAgTwoda1fcFGVK37e/vOw7RV+NZzaLcM+3D7BQ8h36PUWueMXS46ko
dNJydbOrD0lwgjzBv4PetsIB2/aY90SPunYjDaMAECnhWHmt0xKVUMqKFwPAiLPw3Oru
WT+Es/mmBCIL+467aT02xAakgRR6AxLoAb52LA34OAl+Dur9wAjyexrraEK3EOdwlPTQ
Pca5hUMvl2Xh83hSOYeRIwOp65H5K5T2Wvq0jqvNoRCRhJIMkky2DeT2y4TaeXkyc154
lcQcNYOAtJNGovvGYziBWJReHeY8rQ5iDp9DYAFW48gSazxfBx/xk0pYYJ6KUI81Lv5/
sZdw==
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;
bh=Dpu/3cog1ZhO/11vkcFHZ+yd4tbnW5WB2gbhdp2RIOs=;
b=PKBeHASVh6ubgUhLlFOvmZzc0cvDFlls9QkCPIRQGPoelMdnbIo4RPgq0cRNY9OifY
azYEfyd0GVwpFow2M60t2I3qRL1EkCpue3nvatwKGhMMlP6p9l7R8G6fEGNEuqlOsE5T
x5y1Rq5E6cKkKoSNB5shkXNJhpFF1t5ENZhVbB2alaEgTbgnoR22dhAESmzOk3feOIi9
aRqw1jzMzxy6TBPLtMKm0GWnc/IT7d97V4BdOE3B0z71EIXQjEQe4AlP8psYbUH+VgKL
hoSDd78DlaP8e5MHYrngIJMiZi3EWihUMVL0IXhmxKWTbOUeT9xJltNzko4YQ/aK9Mla
t9DQ==
X-Gm-Message-State: AEkooutO1NY3sHk81gTwcOXu4sJSyx+CMu9zKQJ12T5TvFnevj2DXDVAidU6p4ySdBAIWKodCbTHaGkW/MmljA==
X-Received: by 10.31.98.135 with SMTP id w129mr12746660vkb.93.1471386654077;
Tue, 16 Aug 2016 15:30:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.51.77 with HTTP; Tue, 16 Aug 2016 15:30:52 -0700 (PDT)
Received: by 10.31.51.77 with HTTP; Tue, 16 Aug 2016 15:30:52 -0700 (PDT)
In-Reply-To: <CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
<201608161937.20748.luke@dashjr.org>
<20160816194332.GA5888@fedora-21-dvm>
<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 17 Aug 2016 00:30:52 +0200
Message-ID: <CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c094e68d7fa34053a37e6da
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] 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: Tue, 16 Aug 2016 22:30:55 -0000
--94eb2c094e68d7fa34053a37e6da
Content-Type: text/plain; charset=UTF-8
On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness. Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.
That implies that everyone will see both versions and be able to make that
choice. Unfortunately, those two versions will be definition be in conflict
with each other, and thus only one will end up paying a fee. We're can't
relay two transactions for the price of one, or we'd expose the p2p network
to a very cheap DDoS attack: just send increasingly small versions of the
same transaction.
Segwit's third party mallebility protection makes it not an issue for
dependent contracts if transactions are mauled (=apparently the verb
related to malleability), but there are still good reasons for senders not
to gratuitously make their transactions extensible in size or other
resources.
--
Pieter
--94eb2c094e68d7fa34053a37e6da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Aug 17, 2016 00:23, "Russell O'Connor via bitcoi=
n-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:</p>
<p dir=3D"ltr">> If one's goal is to mess with an transaction to pre=
vent it from being mined, it is more effective to just not relay the transa=
ction rather than to mess with the witness.=C2=A0 Given two transactions wi=
th the same txid and different witness data, miners and good nodes ought to=
mine/relay the version with the lower cost (smaller?) witness data.</p>
<p dir=3D"ltr">That implies that everyone will see both versions and be abl=
e to make that choice. Unfortunately, those two versions will be definition=
be in conflict with each other, and thus only one will end up paying a fee=
. We're can't relay two transactions for the price of one, or we=
9;d expose the p2p network to a very cheap DDoS attack: just send increasin=
gly small versions of the same transaction.</p>
<p dir=3D"ltr">Segwit's third party mallebility protection makes it not=
an issue for dependent contracts if transactions are mauled (=3Dapparently=
the verb related to malleability), but there are still good reasons for se=
nders not to gratuitously make their transactions extensible in size or oth=
er resources.</p>
<p dir=3D"ltr">--<br>
Pieter<br>
</p>
--94eb2c094e68d7fa34053a37e6da--
|
