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
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9B04EC0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:43:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 61BC260B13
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:43:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 61BC260B13
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=W3LjHw0i
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gGNJuhH8sdmY
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:43:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5A04B60A47
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
[IPv6:2a00:1450:4864:20::632])
by smtp3.osuosl.org (Postfix) with ESMTPS id 5A04B60A47
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:43:49 +0000 (UTC)
Received: by mail-ej1-x632.google.com with SMTP id
a640c23a62f3a-969f90d71d4so447130066b.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 03 Jun 2023 05:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685796227; x=1688388227;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=lfJbB4nnOpiRcDU4kn5wDRxl3r2/PAbo+jeQsRN6N8Y=;
b=W3LjHw0idNZy5YOztA5BrWdTslNQhMHL7gNFUg2e0go188DQm7Sz33t1hbZoCFlNBA
SJN81AXYOaI5w1zk3OBgrX18um17ci8SDkWjoXYPFsEaqP5At8hTLywoFj1e4wGXKNZH
qdZ1vjsXtFNqBz26/ZNoYlwWJYKDWagdkTGG7eglJaUV3xPA0PRumC0aWEqWsXc15/Cy
vpGWQzEYhvbZjEAGcSMqjZxvRk89hb1JjJRnI+q9b0ZUW+4QmYMLr9RKkhQvcbVd8w9k
hF41Y437odNNkKhZa+4ScyvI6nEXKLp4Vk5WsFCrfGLK4u3io5H9TzKGKBF7K9uN2XHW
FgeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685796227; x=1688388227;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=lfJbB4nnOpiRcDU4kn5wDRxl3r2/PAbo+jeQsRN6N8Y=;
b=U4AupJuCw+WahyYmUYAWIpDNrqIwEVZwLDc8WcuEfyGFoVhGSW0mEUhnglkJpGDnRN
tleTngSacoDWbEZvldfRWgbTuC6DDcjqQja5VkuNjmTT8qDNmgO/qvPktn4G09SYdqxn
t8XLnH342j5aorwJoSVHoyen9OzycUGHVVO34+OsCZ7mUUB5E4MkJFpWhruYchc1Wmr0
Vey3QHzTrByrynYP0qyebi6EVE/2fXkzjYht/lHjK8D7UJYAb8i0HMfxntKylQ6at54d
40gc+K67PJ5NLHI15l/XvrC/FUBW/5KRLD9T501mlr484IsLcQ5UNP90cHvCBn6eqQo5
mAtQ==
X-Gm-Message-State: AC+VfDzFt1c7l5NtL8PnMcgdIviwKSStQfPYw31m9Am+cUkX1v6v6RDo
vxWOzCEq/eObNPTpVk4ml+G8C7QsL/ZH2bHfMsg=
X-Google-Smtp-Source: ACHHUZ5huYIzNQyjcfTdic14xazhLCC3or1p/y5Z3I9g99fhXjDa/umUs8AGey7qF3eu3En158MnveZYYvkCdQgwCqM=
X-Received: by 2002:a17:907:724b:b0:94f:395b:df1b with SMTP id
ds11-20020a170907724b00b0094f395bdf1bmr1223093ejc.21.1685796227207; Sat, 03
Jun 2023 05:43:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
<29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
<CAJBJmV9JYYOSJXbzhrGTrv3jf_qGoLRbq9COgbBmuinpNAOhDg@mail.gmail.com>
<CAJBJmV_UR9ND2vK1+BVeKQ==xdsamJ_7U-X4LH67J9g57UrkTw@mail.gmail.com>
<CAB3F3Dugso9MUqr5hMMorL7FargPPspiof+0-qkYGnP_SLyELg@mail.gmail.com>
<CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
In-Reply-To: <CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sat, 3 Jun 2023 08:43:38 -0400
Message-ID: <CAB3F3Dvm1KAHN2OoA_av2WE1=WZ0hNU6paAtN6c9L6+QFw6pfw@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000049584c05fd390550"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 03 Jun 2023 12:43:50 -0000
--00000000000049584c05fd390550
Content-Type: text/plain; charset="UTF-8"
No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.
Cheers,
Greg
On Sat, Jun 3, 2023, 8:36 AM Joost Jager <joost.jager@gmail.com> wrote:
> > Depending on policy to mitigate this annex malleability vector could
>> mislead developers into believing their transactions are immune to
>> replacement, when in fact they might not be.
>>
>> The issue I'm talking about is where someone's transaction is denied
>> entry into the mempool entirely because a counter-party decided to put in a
>> strictly worse transaction for miners by bloating the weight of it, not
>> adding fees. A strictly worse "API" for paying miners for no gain seems
>> like a bad trade to me, especially when there are reasonable methods for
>> mitigating this.
>>
>
> Just to expand this, an example would be a transaction with inputs A' and
> B' signed by two parties A and B. A has a fully signed transaction in
> hands, but can't publish it because B created and published an alternative
> version of it with a large annex for input B'. Wouldn't miners just accept
> A's version because it's fee rate is higher? I am looking at this case
> assuming the user has a direct connection to a miner, ignoring any
> potential concerns related to p2p transport.
>
> Joost
>
--00000000000049584c05fd390550
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">No in this case the txid is identical. Only the wtxid is =
malleated, with annex data stuffed to max transaction size.=C2=A0<div dir=
=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto">Greg</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Sat, Jun 3, 2023, 8:36 AM Joost Jager <<a href=3D"mailto:joost.ja=
ger@gmail.com">joost.jager@gmail.com</a>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>> Depending on=
policy to mitigate this annex malleability vector could mislead developers=
into believing their transactions are immune to replacement, when in fact =
they might not be.=C2=A0<br></div><div><br></div><div>The issue I'm tal=
king about=C2=A0is where someone's transaction is denied entry into the=
mempool entirely because a counter-party decided to put in a strictly wors=
e transaction for miners by bloating the weight of it, not adding fees. A s=
trictly worse "API" for paying miners for no gain seems like a ba=
d trade to me,=C2=A0especially when there are reasonable methods for mitiga=
ting this.</div></div></blockquote><div><br></div><div>Just to expand this,=
an example would be a transaction with inputs A' and B' signed by =
two parties A and B. A has a fully signed transaction in hands, but can'=
;t publish it because B created and published an alternative version of it =
with a large annex for input B'. Wouldn't miners just accept A'=
s version because it's fee rate is higher? I am looking at this case as=
suming the user has a direct connection to a miner, ignoring any potential =
concerns related to p2p transport.</div><div><br></div><div>Joost</div></di=
v></div>
</blockquote></div>
--00000000000049584c05fd390550--
|
