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
|
Return-Path: <joost.jager@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6A0D8C0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:36:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 3E80540135
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:36:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3E80540135
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=PmIW7ovj
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9drBjzoyKAy8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:36:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 383BD400DA
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
[IPv6:2a00:1450:4864:20::62d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 383BD400DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Jun 2023 12:36:29 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id
a640c23a62f3a-97458c97333so313147866b.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 03 Jun 2023 05:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685795787; x=1688387787;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Vd+dMZya97bwj05pgbMgi7u1HNoGbO22xdNX7+XbnME=;
b=PmIW7ovj3/VE/OALUenbKn4jJ/1bQ4qPpIVsn+h1PoCq4UbSK/S3MbinwLmgWsorEl
zfQnMlH8LICZVhplS/iFMVTiQ6sFQY8XMAB3dKutWaL5StwCQc4it5Rh1MFCmTUMw+lP
MZLAv6sGBZH5xUPq9HNW0/bcMAzqDoB+hlFqckzK0Lui7uwZSmLsfMn6ZQz5EaSd4XI0
F4D1hx7cq8KSK2B8INWPb5kjeQCKniawfi6Oen2iCNwpnWfEnaCaADoWGZYQyduzkARU
dgrQg+xeX4sR7cRFXB8Q8gmszTtbXFP46p/xYd/7utonek3zYXWyxl4Q10Q1DKBl1g7d
yGEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685795787; x=1688387787;
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=Vd+dMZya97bwj05pgbMgi7u1HNoGbO22xdNX7+XbnME=;
b=UlR0mDR8nQpazLShXxNCj2Tl0uDtJ7Z/FbaMcV1DeEGbXuwUvwRaIG+qabRWlqQB+p
IHUVWvJLvZaBAAd6O6pvX5WNwVhJepciuRBiZQPRvKzOuytR2wl7a9k66CyVQcUnr95R
8+NV/UJbNOHze55/RHOJKCl/jA7kMGwM3Mpi8Wjv/4Mkr125EMEGKOT/ojplg+uO90OG
3SQ1W/77pNnt0gENC7IHVU/lxqhx+g3Eqr+LUeMeP4jTYG5EEb8cC7UrMnyOA8rLiKE+
o1gBeFrwAqcTUBkWiHbz46oAw3o63soFgCjI+sHxFXEs+eVA5yDk0iGSqJzHK1JBFZUp
yUWQ==
X-Gm-Message-State: AC+VfDwTzkD9dOIOfpZjgLiq4TT805XQN4r/tb2q028tlk9lBZBcsmj9
cntYlgFycho+obwS6Bej+wF7KxVeX6oQA9y06XI=
X-Google-Smtp-Source: ACHHUZ5QB8Btf4yesDTTOVBd79lvyYKXoR6PGmH/ejvDCtBlfFtjrx0taB/W12QPc0tux5daakPUbPkipi7JzOhs0sQ=
X-Received: by 2002:a17:907:6e23:b0:974:e767:e1e7 with SMTP id
sd35-20020a1709076e2300b00974e767e1e7mr1467584ejc.28.1685795787025; Sat, 03
Jun 2023 05:36:27 -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>
In-Reply-To: <CAB3F3Dugso9MUqr5hMMorL7FargPPspiof+0-qkYGnP_SLyELg@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 14:35:51 +0200
Message-ID: <CAJBJmV8G4cS1Utr7WQskv4xFG0hAZ9-W8Gv5kRBdJmhuTgbBkw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000cb2e505fd38eb5f"
X-Mailman-Approved-At: Sat, 03 Jun 2023 13:20:56 +0000
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:36:30 -0000
--0000000000000cb2e505fd38eb5f
Content-Type: text/plain; charset="UTF-8"
>
> > 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
--0000000000000cb2e505fd38eb5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" 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 mitiga=
te this annex malleability vector could mislead developers into believing t=
heir transactions are immune to replacement, when in fact they might not be=
.=C2=A0<br></div><div><br></div><div>The issue I'm talking about=C2=A0i=
s 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 &qu=
ot;API" for paying miners for no gain seems like a bad trade to me,=C2=
=A0especially when there are reasonable methods for mitigating 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 bec=
ause B created and published an alternative version of it with a large anne=
x 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 h=
as a direct connection to a miner, ignoring any potential concerns related =
to p2p transport.</div><div><br></div><div>Joost</div></div></div>
--0000000000000cb2e505fd38eb5f--
|
