summaryrefslogtreecommitdiff
path: root/f6/a763b38f74abf54084c2ced0b9f4f1a0466f36
blob: e16f44581fe5b1520b04c6aaad1ea7ce9cdefc9f (plain)
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
193
194
Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 619AAC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5088560B1B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
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 bS7r5dPz0O3O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com
 [IPv6:2607:f8b0:4864:20::431])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8BEA6606A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:32 +0000 (UTC)
Received: by mail-pf1-x431.google.com with SMTP id e28so14304333pfj.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Jan 2022 16:08:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-transfer-encoding:from:mime-version:date:message-id
 :references:in-reply-to:subject:to;
 bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=;
 b=pd+6jVWptLtqfQMdkfqR7yqasII8WcsNwlJcruGB0nTOpyxcDg4Kw8MBG2K9zns0GA
 4sxgz0UFwKNnATBYP6rexrz1qW59V2p68T9bWwwvZfeZv5QS92BnEGaeAlo+zeXbCDFS
 jrXU2DQ3HY1tpNmfqp+CEUGybH2wH+QeSv9ZsnpypKrOU9GPNB08oPWDeleJANwUsMhW
 zoL+X5VaPB2avvMMBYtNKW+JFsyWzr/WBkw22pTgO11wqOf2xr3fWGA9hvG0utuD4nq4
 zomMeUqR/gjA4NbXg8CFBnOLRx22AwzmsRbiaX3Rl8lKhGUnDohQZLLucMSkiIpmXQFe
 YVkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version:date
 :message-id:references:in-reply-to:subject:to;
 bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=;
 b=0wP9vrF91eNTGh42BsozgwKinAYtUDfG4CE7ZQbD6ggz7IbMvO1/kOSmlE8X3Etjrc
 AR3HgpM6HvtgKkmjRWkIYGhTt73D0lifRy0a3PNuPLLHEqNRCsC0nDaMUVZmM3yj3zP0
 7jGzSxxBisFKaNtD6B13AGkopXBnUGnV+pFwh7mJzvezw8eh0ebpxsrW+Sl9hXSelGCq
 ikaikf7crcV1pbGxZ/BE/9COzcfBveiWWLrej8My/0DcneyH6T6C2NJj9lWT7ArnEKAs
 Jxd8V5WR5zaTTg0jGftTv4kg+0IYAvxgs0Pq0qvcVVzGM9vvmtcnfVu1/N+Amuf9peu+
 Q0Sg==
X-Gm-Message-State: AOAM533cStvNVVSnmgkOvwS5i391bEFGC+01+2nPGnCcBuW8RXJ5oR5A
 N3xVSefCZvPa8FFkSBKv3m0RaA==
X-Google-Smtp-Source: ABdhPJxA3/Sw6FEfINVhwaZTb3HT46wRQujDiGDw4LlW5zWCBJzubKPIVZdBmlAl2rI3VySWsNIAEA==
X-Received: by 2002:aa7:8595:: with SMTP id w21mr22335245pfn.18.1643674111788; 
 Mon, 31 Jan 2022 16:08:31 -0800 (PST)
Received: from smtpclient.apple ([2601:600:9c00:1d0::ff78])
 by smtp.gmail.com with ESMTPSA id j14sm20151726pfj.218.2022.01.31.16.08.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Jan 2022 16:08:31 -0800 (PST)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 31 Jan 2022 16:08:30 -0800
Message-Id: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
References: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
In-Reply-To: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
To: Bram Cohen <bram@chia.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (19C63)
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 00:08:33 -0000


--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:


=E2=80=A6

> Is it still verboten to acknowledge that RBF is normal behavior and disall=
owing it is the feature, and that feature is mostly there to appease some pe=
ople's delusions that zeroconf is a thing? It seems a bit overdue to disresp=
ect the RBF flag in the direction of always assuming it's on.

What flag?

>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>   accept replacement transactions which would decrease fee profits
>>   of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
>=20
> There are two different common regimes which result in different incentivi=
zed 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 blo=
ck's worth of transactions the one with higher total value should win.

These are not distinct scenarios. The rational choice is the highest fee blo=
ck-valid subgraph of the set of unconfirmed transactions, in both cases (wit=
hin the limits of what is computationally feasible of course).

When collecting pooled txs the only issue is DoS protection, which is simply=
 a question of what any given miner is willing to pay, in terms of disk spac=
e, to archive conflicts for the opportunity to optimize block reward.

> It would be nice to have consolidated logic which handles both, it seems t=
he issue has to do with the slope of the supply/demand curve which in the fi=
rst case is gentle enough to keep the one transaction from hitting the rate b=
ut in the second one is basically infinite.

--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><meta http-equiv=3D"conten=
t-type" content=3D"text/html; charset=3Dutf-8"><div dir=3D"ltr"></div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Jan 3=
1, 2022, at 15:15, Bram Cohen via bitcoin-dev &lt;bitcoin-dev@lists.linuxfou=
ndation.org&gt; wrote:</blockquote></div><div dir=3D"ltr"><br></div>=E2=80=A6=
</div><div dir=3D"ltr"><br><blockquote type=3D"cite"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br></blockquote><div>Is it still verboten to acknowledge that RB=
F is normal behavior and disallowing it is the feature, and that feature is m=
ostly there to appease some people's delusions that zeroconf is a thing? It s=
eems a bit overdue to disrespect the RBF flag in the direction of always ass=
uming it's on.</div></div></div></div></blockquote><div><br></div><div>What f=
lag?</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- *=
*Incentive Compatibility**: Ensure that our RBF policy would not<br>
&nbsp; accept replacement transactions which would decrease fee profits<br>
&nbsp; of a miner. In general, if our mempool policy deviates from what is<b=
r>
economically rational, it's likely that the transactions in our<br>
mempool will not match the ones in miners' mempools, making our<br>
fee estimation, compact block relay, and other mempool-dependent<br>
functions unreliable. Incentive-incompatible policy may also<br>
encourage transaction submission through routes other than the p2p<br>
network, harming censorship-resistance and privacy of Bitcoin payments.<br><=
/blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>=
<div>These are not distinct scenarios. The rational choice is the highest fe=
e block-valid subgraph of the set of unconfirmed transactions, in both cases=
 (within the limits of what is computationally feasible of course).</div><di=
v><br></div><div>When collecting pooled txs the only issue is DoS protection=
, which is simply a question of what any given miner is willing to pay, in t=
erms of disk space, to archive conflicts for the opportunity to optimize blo=
ck reward.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div>It would be nice to have consolidated lo=
gic which handles both, it seems the issue has to do with the slope of the s=
upply/demand curve which in the first case is gentle enough to keep the one t=
ransaction from hitting the rate but in the second one is basically infinite=
.</div></div></div><br></div></blockquote></div></body></html>=

--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305--