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: <bram@chia.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 74B65C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 08:32:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5D6DB60F6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 08:32:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=chia.net
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 unX47hllafcu
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 08:32:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
[IPv6:2a00:1450:4864:20::12f])
by smtp3.osuosl.org (Postfix) with ESMTPS id 4ED6760BA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 08:32:24 +0000 (UTC)
Received: by mail-lf1-x12f.google.com with SMTP id i34so11903111lfv.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Feb 2022 00:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=ZRKlxKmyo9an29KIS+sym9XB5FNWCVUXUKStX14CGs8=;
b=BIiMNBDg7z4vv6swFtRxZ+a3kUbpjLbzCZuDL2v1bzapx8oSdQ/pWLW50C+9Mwc/AA
NVJMcsf5LMdsOnuO8c2DDXci+lSa3uRtvMRGdko+jWa+wvHNCeGAJqPcrUCDiy16CEdX
V4d7zn0ov/GnjSCfna/Kgvgb4Thsxt+lX/EvxPO2W/UX3tu2iSBMVti9zqY5HOMmFMyj
JanZNOGbtef7axbCfbNCn7LGybcd0ffniy/+WRGhG/epIze1B7P9izodJIxlgqjtZQlP
F/BS34L1pUe3UUXGqh5VWXPuq/U/y5nHmOtZ2CNBvTF/EyMeD4wY1oG/OLHYzhbXDTBs
TG2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=ZRKlxKmyo9an29KIS+sym9XB5FNWCVUXUKStX14CGs8=;
b=SNPrRr+lf5HC+/0UqPBck06UWDezqYDTsuCzCt2NMlQwCcEaAPFMSraC0WnsTE6zQW
a26M8i3KbobUreS3idYnCd6s2oqAz+/KzJad841IXEG7avkcHtSoTk0IMJ3r9OLQ/UNx
5W5Q+PAfTT7Z65pI4+V5KXwmBD+D1OUgx+STYkqTPUPejwL2fVxYbdPAVcyvVog44j2A
YtAE1v6dcoWRUGdHkm4umcIxYxOUMQ9nW7lwSjW2upUUGWAbbuuMzbaSI3vKMgcacPWA
TQhqoepwH2bnbEFrGpX00Sip8gTgo6ezt7Qdr1NPiy9zFPWuh8kS5535hojeiNNsXV7P
3PnQ==
X-Gm-Message-State: AOAM532/k5SvIxILMEcMZLMSEmN7SnEdD3DtQgvVdBYWsrwNKVLSpe+C
IJ84D4jxb68z7quQFYjlc6BELura4mlPmBWqQzg4e7i/k+Q=
X-Google-Smtp-Source: ABdhPJy8OhKBZLRWhKczMjEWhn261MUmeqM0FXmSqnBhzAqsLDPcXhJ86+TnmRk8meZjqMYv1r1Aqzt5Jg8XXRnOOcQ=
X-Received: by 2002:ac2:51d9:: with SMTP id u25mr18347123lfm.228.1643704342065;
Tue, 01 Feb 2022 00:32:22 -0800 (PST)
MIME-Version: 1.0
References: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
<20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
In-Reply-To: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
From: Bram Cohen <bram@chia.net>
Date: Tue, 1 Feb 2022 00:32:09 -0800
Message-ID: <CAHUJnBD034D4-Ru0d4b4_2eYeNUKvmMcvQCW7OJTO9YzWFYHnQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="0000000000006ccb1e05d6f0bddf"
X-Mailman-Approved-At: Tue, 01 Feb 2022 09:13:31 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF policy
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, 01 Feb 2022 08:32:25 -0000
--0000000000006ccb1e05d6f0bddf
Content-Type: text/plain; charset="UTF-8"
On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric@voskuil.org> wrote:
>
>
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly there to appease
> some people's delusions that zeroconf is a thing? It seems a bit overdue to
> disrespect the RBF flag in the direction of always assuming it's on.
>
> What flag?
>
The opt-in RBF flag in transactions.
> There are two different common regimes which result in different
> incentivized behavior. One of them is that there's more than a block's
> backlog in the mempool in which case between two conflicting transactions
> the one with the higher fee rate should win. In the other case where there
> isn't a whole block's worth of transactions the one with higher total value
> should win.
>
> These are not distinct scenarios. The rational choice is the highest fee
> block-valid subgraph of the set of unconfirmed transactions, in both cases
> (within the limits of what is computationally feasible of course).
>
It's weird because which of two or more conflicting transactions should win
can oscillate back and forth depending on other stuff going on in the
mempool. There's already a bit of that with child pays but this is stranger
and has more oddball edge cases about which transactions to route.
--0000000000006ccb1e05d6f0bddf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 31, 2022 at 4:08 PM Eric =
Voskuil <<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>> wr=
ote:<br></div><blockquote class=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=
"auto"><div dir=3D"ltr"><div dir=3D"ltr"></div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr"><br><blockquote type=3D"cite">On Jan 31, 2022, at 15:15, Br=
am Cohen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> =
wrote:</blockquote></div></div><div dir=3D"ltr"><blockquote type=3D"cite"><=
div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Is it stil=
l verboten to acknowledge that RBF is normal behavior and disallowing it is=
the feature, and that feature is mostly there to appease some people's=
delusions that zeroconf is a thing? It seems a bit overdue to disrespect t=
he RBF flag in the direction of always assuming it's on.</div></div></d=
iv></div></blockquote><div>What flag?</div></div></div></blockquote><div><b=
r></div><div>The opt-in RBF flag in transactions.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=
=3D"ltr"><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div c=
lass=3D"gmail_quote"><div>There are two different common regimes which resu=
lt in different incentivized behavior. One of them is that there's more=
than a block's backlog in the mempool in which case between two confli=
cting transactions the one with the higher fee rate should win. In the othe=
r case where there isn't a whole block's worth of transactions the =
one with higher total value should win.</div></div></div></div></blockquote=
><div>These are not distinct scenarios. The rational choice is the highest =
fee block-valid subgraph of the set of unconfirmed transactions, in both ca=
ses (within the limits of what is computationally feasible of course).</div=
></div></div></blockquote><div><br></div><div>It's weird because which =
of two or more conflicting transactions should win can oscillate back and f=
orth depending on other stuff going on in the mempool. There's already =
a bit of that with child pays but this is stranger and has more oddball edg=
e cases about which transactions to route.</div></div></div>
--0000000000006ccb1e05d6f0bddf--
|
