Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D497FC002D for ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudefgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpedttdegtdffteeukeffhfffkeekiefhteduvdetjeeujeffgeevgefhudetjefh veenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv sehpvghtvghrthhouggurdhorhhg X-ME-Proxy: 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 To: email@yancy.lol, Bitcoin Protocol Discussion Message-ID: References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--