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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B1756C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Sep 2022 19:21:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7D6E74088C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Sep 2022 19:21:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7D6E74088C
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=voskuil-org.20210112.gappssmtp.com
header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=lqi64jdm
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qR0S1z2FRKRH
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Sep 2022 19:21:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 28AAB40425
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com
[IPv6:2607:f8b0:4864:20::636])
by smtp4.osuosl.org (Postfix) with ESMTPS id 28AAB40425
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Sep 2022 19:21:37 +0000 (UTC)
Received: by mail-pl1-x636.google.com with SMTP id jm5so9919428plb.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Sep 2022 12:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20210112.gappssmtp.com; s=20210112;
h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
:from:content-transfer-encoding:from:to:cc:subject:date;
bh=KeXG22/0hqjFXPm9pgFGVlK4jbkZVnyBtj/dtPy9hxc=;
b=lqi64jdmC7vApznDwVMFgQVX52k2iCcUqH1t2NXhdL7osr+Yxand+5FnBvqUlmjWra
MMg2D0Kdj7iC/LUjrqElYFAyTnKZ+flTz5fEqtgEU07ZyZ0nyaa8PYs5NKv0mhUaO00i
rpF/M9YgjmfCsCL3lOlkHLStDlKg9ljqCqbja2qj5hYM8eXJx6FQNW9zzoLT1fE6j/xw
nBb6mdf/SwpAbmNDToFvCtok0j7OF9RVt7ItpGtnDGJdQZrp5ygI5P2WOytouIiQ4Mlf
3zBbWrJCz7T5qKeaqdDUfhq3ptgH4+YIzMbIAK3kJAVPUs3Ygb/JMZm/4wmu/AMbMJmk
Dpxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
:from:content-transfer-encoding:x-gm-message-state:from:to:cc
:subject:date;
bh=KeXG22/0hqjFXPm9pgFGVlK4jbkZVnyBtj/dtPy9hxc=;
b=jiqNZuCRoe7WcrUgOzqV4i0wEc/qutXdlW4U1K86ZEC+xU0R/QltLHpMQkuz9dUOub
MJLIjk4t0FcZi7ah1mqENVBWJuMFqtFYmAAgqlLzRX1BftxSvJqjlGrBLrRpPyleN/lZ
pDptrISV3j8S05E8I+oZtFfp1hztef7uaP+HY7xFzrv7BInhKxq/lXnpIH6LPefI9tO6
/PV98y8eFSZTh28Rj8vjldDI+Y7dwyNtfG/5w4eZoh9M8v+D9nm6KrNBNV8KxXBJPRZ5
Q8mk9Q8DaBzvcYGShMZ7ok/j8pP9NzdajRsxEcjdvsJafSS6pfBGz8tHEZGrkc/KxNiH
4mmQ==
X-Gm-Message-State: ACrzQf1yiidGfepNRn1Q2MaJCjbOBLKR/619R+1bMHVvJMs7HXdSXTSV
WsI0H/FjPy+daeWb8bGc2kdj0xfjgUmHZw==
X-Google-Smtp-Source: AMsMyM4d+rde+HcIqNsK3QvXYmONWLLYErf8/nA0xSOZDCQKZoSpsxIj/4Q48E30XPDGlQPN/Mlciw==
X-Received: by 2002:a17:903:228c:b0:178:3bc7:8a3f with SMTP id
b12-20020a170903228c00b001783bc78a3fmr28288851plh.88.1664306496447;
Tue, 27 Sep 2022 12:21:36 -0700 (PDT)
Received: from smtpclient.apple ([50.35.67.197])
by smtp.gmail.com with ESMTPSA id
30-20020a63155e000000b0043c268a8911sm1915470pgv.4.2022.09.27.12.21.35
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 27 Sep 2022 12:21:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 27 Sep 2022 12:21:35 -0700
Message-Id: <AA9BD913-E5BA-4D70-B3DB-9D83C1BBB62E@voskuil.org>
References: <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
In-Reply-To: <A485FF21-3B14-49B4-BC53-99AFAA90E38D@voskuil.org>
To: alicexbt <alicexbt@protonmail.com>
X-Mailer: iPhone Mail (19G82)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Packaged Transaction Relay
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: Tue, 27 Sep 2022 19:21:38 -0000
Thanks again for the feedback. Comments inline.
> On Sep 27, 2022, at 02:29, alicexbt <alicexbt@protonmail.com> wrote:
>=20
> =EF=BB=BFHi Eric,
>=20
>=20
>> If by "range" you mean a connected tx subgraph, I don't see why not. But n=
ote that nodes only operate over signed txs. PSBT is a wallet workflow.
>=20
> Matt Corallo mentioned that pre-signed transactions created with low fee r=
ate become an issue when they are broadcasted after a long time and there is=
a high demand for block space at that moment.
Yes, I understood this. There are many ways that a fee may be created which i=
s too low for propagation.
> Example:=20
>=20
> Bob created PSBT1 in a multi party contract with fee rate 5 sat/vbyte howe=
ver its taking hours/days to confirm the transaction with such low fee rate.=
>=20
> Carol created PSBT1 (5 sat/vbyte), PSBT2 (10 sat/vbyte) and PSBT3 (20 sat/=
vbyte) for spending same inputs. She broadcasted PSBT3 which got confirmed i=
n a few minutes.=20
>=20
>=20
>> Always. Only signed transactions are accepted. But assuming you are refer=
ring to a transaction that has been produced by a pre-signing workflow, I'm n=
ot sure how this would be distinct from any other tx.
>=20
>=20
> `minfeefilter` for all peers of my node was 0.00001000 at the time of writ=
ing this email. I am assuming nobody creates pre-signed transaction with fee=
rate below 1 sat/vbyte. How often does it happen that `minfeefilter` is abo=
ve this default value?
I don=E2=80=99t consider node configuration relevant, regardless of its appa=
rent consistency.
>> I'm not sure I follow this, maybe you could reword it. But it seems that y=
ou are saying that CPFP fee-bumping is a problem scenario and the complexity=
of the proposed solutions are not justified by such scenarios.
>=20
>=20
> Sorry that sentence was confusing. Yes complexity isn't justified for CPFP=
fee-bumping txs below minimum fee rate.
>=20
>=20
>> There are many node implementations used presently. And of course these a=
re protocol proposals, which presumes more than one implementation.
>=20
>=20
> Yes, a few implementations exist (knots, libbitcoin, btcd, bcoin etc.) how=
ever they aren't used by lot of nodes. Based on this [chart][1] 98% nodes us=
e bitcoin core. Lot of bitcoin protocol proposals are influenced by bitcoin c=
ore contributors and things could be different if even 30% nodes used other i=
mplementations.
I don=E2=80=99t consider such a measure relevant. This is a protocol conside=
ration. Also consider that many nodes are not visible, and aspects of nodes,=
such as for p2p communication, are embedded into applications such as walle=
ts - which could easily exceed the number of visible nodes.
>> I don't consider this relevant to any protocol considerations. Miners sho=
uld always be expected to select the most optimal set of txs available in th=
e time available to do so.
>=20
>=20
> Agree, miners should be expected to select most optimal set of txs. Howeve=
r, according to one [comment][2] by Pieter Wuille, miners could affect the s=
ecurity of some bitcoin projects with MEV.
This would be a deficiency in such projects, by assuming economic irrational=
ity. The fact that fees will become a greater percentage of the block reward=
is a surprise to no one.
>> Over time we are likely to see that the only policies that remain in wide=
spread application are those that are necessary for DOS protection (fee rate=
), as other restrictions are not economically rational and cannot be enforce=
d. We've seen recent debate regarding dust policy, and op_return policy. "no=
n-standard" txs are perfectly valid but get stuck very easily. I'll reiterat=
e, any policy beyond what is published via the protocol will cause the above=
problems.
>=20
> I completely agree with this.
>=20
>=20
> [1]: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html
> [2]: https://bitcoin.stackexchange.com/questions/107787/front-running-in-b=
itcoin#comment123441_107796
>=20
>=20
> /dev/fd0
|
