diff options
| author | Peter Todd <pete@petertodd.org> | 2022-10-31 13:51:10 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-31 17:51:17 +0000 |
| commit | 1107a4edcdcb95588230c44437122eaaa8a3255e (patch) | |
| tree | ad0aec8aa46a2a056ed2c57c6fdcb8261e49c8dd | |
| parent | 53a17c40962fa42d693e344155e03c1045cbe8e0 (diff) | |
| download | pi-bitcoindev-1107a4edcdcb95588230c44437122eaaa8a3255e.tar.gz pi-bitcoindev-1107a4edcdcb95588230c44437122eaaa8a3255e.zip | |
Re: [bitcoin-dev] On mempool policy consistency
| -rw-r--r-- | 1c/fabed50ccf546b1c7918c2fcd222edeaa6387b | 183 |
1 files changed, 183 insertions, 0 deletions
diff --git a/1c/fabed50ccf546b1c7918c2fcd222edeaa6387b b/1c/fabed50ccf546b1c7918c2fcd222edeaa6387b new file mode 100644 index 000000000..9752e5da7 --- /dev/null +++ b/1c/fabed50ccf546b1c7918c2fcd222edeaa6387b @@ -0,0 +1,183 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id D497FC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 31 Oct 2022 17:51:17 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 990A360AD8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 31 Oct 2022 17:51:17 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 990A360AD8 +Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, + unprotected) header.d=messagingengine.com header.i=@messagingengine.com + header.a=rsa-sha256 header.s=fm3 header.b=At6UqSTM +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.602 +X-Spam-Level: +X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 AySZ_364Er0X + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 31 Oct 2022 17:51:16 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EBD20607C1 +Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com + [66.111.4.27]) + by smtp3.osuosl.org (Postfix) with ESMTPS id EBD20607C1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 31 Oct 2022 17:51:15 +0000 (UTC) +Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) + by mailout.nyi.internal (Postfix) with ESMTP id 616F55C0103; + Mon, 31 Oct 2022 13:51:13 -0400 (EDT) +Received: from mailfrontend1 ([10.202.2.162]) + by compute4.internal (MEProxy); Mon, 31 Oct 2022 13:51:13 -0400 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= + messagingengine.com; h=cc:cc:content-type:date:date:feedback-id + :feedback-id:from:from:in-reply-to:in-reply-to:message-id + :mime-version:references:reply-to:sender:subject:subject:to:to + :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= + fm3; t=1667238673; x=1667325073; bh=a/JxqbPUfX7BKHVEJdKHFyxXlIJg + lN96HHKo4KEdeSo=; b=At6UqSTMfdQspZsOY2gnDDxNHfOQ4q/TIM6IfVFYJ5GS + XZL6YVhSXRTaa23s5oHaaQmllSrWdQV+4TZcXuMj9Ig1LAN/vtJQKu9r1dUxo1rn + ZIq08f/81UQDBgoQ0N7mjgLaX3/xHCxBkcW377jWbcWejbS3LnLKM7bTXkmYfOlw + fPhK49wh4cnLfimDSImin3liLCFp8WDyA3KJIE/IFayg/CvbjrotBK+Wn6HNml3b + 38LGQOUIKacxlPGVTJfDfAfWvco4EHyOkdECpHXQvk3u2MTPwKRfS2azIDHQNH2V + 7VSAS+AW4IPAiP6EQdj5UhGd+GUHEsY90g/EG0AppQ== +X-ME-Sender: <xms:EAtgYxqE4dt1gQcZH5twcaxXLdMcwmYVPsnQaRtRjV7_yKhNGL-SNg> + <xme:EAtgYzq3otcKhrFJAc1Yt27-WLKgJUkgOyRS8_7nmKq_UDyNjtMwFhb8m_S2cvnUA + jMKb7_qd6ao8-H07lw> +X-ME-Received: <xmr:EAtgY-N3vi3XPyg7gRVGSHixmmM5kZFRmHR_uxzMg_luIKrPQTzuVPmUUhZ97kSodlxjM2xnEM-cWw-Qrd1IvE80Cng0_4fF> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudefgddutdegucetufdoteggodetrfdotf + fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen + uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne + cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv + rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth + gvrhhnpedttdegtdffteeukeffhfffkeekiefhteduvdetjeeujeffgeevgefhudetjefh + veenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne + cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv + sehpvghtvghrthhouggurdhorhhg +X-ME-Proxy: <xmx:EAtgY85p9j2LjzmWAVJlDDK9GxsTtBAJNZPtsGLkZghS4gqhB_jJ3w> + <xmx:EAtgYw7lJS8zUJ1HuQQVq1V6BokMlj5zrCyVrUD2U-KgrYUIWfHbTA> + <xmx:EAtgY0i3u-y-2tk4hxfsGcwgCbmssQwxxQjYURDEikjG4y1goJRuKw> + <xmx:EQtgY73RhzxuS2fa_t9KNBBwLs1HGi9tmA5hxLEsG4mpBkRepuo2bg> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, + 31 Oct 2022 13:51:12 -0400 (EDT) +Received: by localhost (Postfix, from userid 1000) + id 5E64E5F86F; Mon, 31 Oct 2022 13:51:10 -0400 (EDT) +Date: Mon, 31 Oct 2022 13:51:10 -0400 +From: Peter Todd <pete@petertodd.org> +To: email@yancy.lol, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <Y2ALDu36tMQxVr/i@petertodd.org> +References: <Y1nIKjQC3DkiSGyw@erisian.com.au> + <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com> + <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com> + <23dac89d36c356b9266db07e09c2de8e@yancy.lol> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="UiZssDDyd9AgECKb" +Content-Disposition: inline +In-Reply-To: <23dac89d36c356b9266db07e09c2de8e@yancy.lol> +Cc: Greg Sanders <gsanders87@gmail.com> +Subject: Re: [bitcoin-dev] On mempool policy consistency +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: Mon, 31 Oct 2022 17:51:17 -0000 + + +--UiZssDDyd9AgECKb +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote: +>=20 +> Protocol Devs, +>=20 +> After reading through this email thread and BIP125, I'm curious if non-rbf +> nodes will relay full-rbf transactions and vice versa. That is to say, if +> only one non-rbf node exists on the network, however, every other node +> implements full-rbf, will the transaction still be propagated? IE can we +> always guarantee a path through the network for either transaction type no +> matter what the combination of network policies are? + +1) There are nodes that signal full-rbf, and preferentially peer to each ot= +her, +thus ensuring good transaction propagation. The most recent patch to implem= +ent +this is: https://github.com/bitcoin/bitcoin/pull/25600 + +There's enough peers running full-rbf that the last time I started up a new +node on a fresh IP address, it happened to have a peer relaying full-rbf +replacements to it. And of course, if people want full-rbf to work more +reliably, it's very easy to just run some nodes with a large number of outg= +oing +peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't very ha= +rd. + +2) There's nothing special about a "full-rbf transaction" other than the fa= +ct +that it's replacing a previously broadcast transaction that didn't signal +replacement. There is not consensus over the mempool, so in certain cases +non-full-rbf nodes will in fact broadcast replacements when they didn't hap= +pen +to receive the "first" transaction first. + +The latter makes testing full-rbf a bit problematic, as if you don't take +special measures to ensure good propagation a small % of the time the +"replacement" transaction will in fact be the one that gets gets mined. + +> > Does fullrbf offer any benefits other than breaking zeroconf +> > business practices? If so, what are they? +>=20 +> I think AJ mentioned this earlier, but adding more configuration options +> always increases code complexity, and with that, there is likely more +> unforeseen bugs. However, there is a section of network participants that +> rely on both types of transaction policy, so from my limited view-point, = +it +> seems worth accommodating if possible. + +Since all the machinery to do replacemnt already exists, adding a full-rbf +config flag is particularly trivial. It requires just a single line in the +mempool code. + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--UiZssDDyd9AgECKb +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNgCwwACgkQLly11TVR +LzcKmxAAjaTvECWJgd5PSABejnf86zoGMJQ4mBt5QgF1i+i8KBJ3MI//ISFW6uwM +lrO9rnfGpo8rzr7fqav+stQhhGJnR2ZizSlQ0rkDFPNbOwQijPGC9g4T74EQgH66 +i3VVTqFo+zo/tYgY8VnyHn5CZ1C66rTPfRFxpuVJzYcTMrjTqZcNeabtbxhcKQTP +ilvLSpJh5PY+bTGr8BgMYDwt2glEQ4j/Sh6dq7TtMSMhRM4bpErE9eC7tZqoG4Tz +OZnYpngX0zDKuqX/RnvpLNGCGcvR5hKLl/RzNZigZWKzIe/vl2xNHIw+Vl7qfHl3 +1OlBRYWYYWxJzlnqrmRujuVkL8ywa8zvxfTdTb6+BoKUDI/r6yAFoUucpUs5mJcJ +/9cKBGnKRTG6C03YQaUb9Gw5SsqGz1KZVkyYWlIrP7B3KaoLklEK9QAp4kWFgBBo +3abOBPYTfnHu0oSBmepXhHPzKoHyda9cLJAAaKEI41+0c3/kt2kLH9H5NbkwDYtJ +vH+ffh6PTLicvbesEhbSpmeOtKjQTqUtuD3nAL8udt3lOyyfqSNrsUpGjb5nNbcc +ataeF5AC+n4MafZuJM7dcQC/8VrsTggUXtNRTuCBtXHMhTVTGiUEwYRSLUgOWBMO +T81kgh7fYBZftfmbS5grV69Wf98BQ1Y2zzSM76oDQdiNyG9OpDc= +=5ySU +-----END PGP SIGNATURE----- + +--UiZssDDyd9AgECKb-- + |