Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 63C8AC0012 for ; Sat, 18 Dec 2021 17:52:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3E76C84BA5 for ; Sat, 18 Dec 2021 17:52:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=petertodd.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-YO6_zL6zFF for ; Sat, 18 Dec 2021 17:52:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp1.osuosl.org (Postfix) with ESMTPS id D694C84B9A for ; Sat, 18 Dec 2021 17:52:17 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com. (8.15.2/8.15.2) with ESMTP id 1BIHqE5f053335; Sat, 18 Dec 2021 17:52:14 GMT (envelope-from user@petertodd.org) Received: from petertodd.org (76-10-157-59.dsl.teksavvy.com [76.10.157.59]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id 1BIHqBDj039826 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 17:52:12 GMT (envelope-from user@petertodd.org) Received: by petertodd.org (Postfix) with ESMTPSA id AFCF2A2FD3; Sat, 18 Dec 2021 12:52:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=petertodd.org; s=mail; t=1639849930; bh=y3Csh9s6UZC6RXViHswvCgLwdPXJSkU47ej4FcRDpGk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m/RQstAEc4NXms4f+SIl+EnStRn9n3Uas0s55iEtN+sfnrMcMtNTgSSoQ2bdGEduG juWhi2kCAUjB+QPq38JD4kc7EehFl4itGDmi73Qx6Xx9Dvf/te/qX5hH9qdUHKeLHi TEg3XQ4Q+UB7T8uwAfCWNjuXQbWSOBEVFVKsYJXx2qjGIkDWhljtuVLq+bHBHb8vq/ lF7Em/3Cvke5txPnpyJub875YNdhw5nf5o4yKEQk92Cy/HIV9VY34URmAboME2ateV SdN0c0M/uMjvjhD2hmHkjtMozWCFTMP0lAQ8HBSIetTxX3r1AUf0Bt6JtN2JA9tnyK jt9D0/tDCExvg== Received: by localhost (Postfix, from userid 1000) id 32EF25F76E; Sat, 18 Dec 2021 12:52:07 -0500 (EST) Date: Sat, 18 Dec 2021 12:52:07 -0500 From: Peter Todd To: Jeremy , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7xZG4+OLekTtL899" Content-Disposition: inline In-Reply-To: X-Server-Quench: 3b104958-602b-11ec-ba2e-8434971169dc X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwoUHFAXAgsB AWcbWlNeVV97WGA7 bAxPbAVDY09JQQBj T0pMXVMcFXcReV1z ckQeURB6dQMIeX52 YUIsXSJaXEBzcE5g RE5WR3AHZDIzdTJO UhVFfwdXdApNfx5D YwQsGhFYa3VsNCMk FAgyOXU9MCtqYBxP RRkKNlsWEw4lAzo4 AiooM30uGwUvRjk4 KB0gYnUbBktZaBl0 aTNX X-Authentic-SMTP: 61633532353630.1024:7600 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.157.59/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0 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: Sat, 18 Dec 2021 17:52:19 -0000 --7xZG4+OLekTtL899 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 18, 2021 at 08:51:46AM -0800, Jeremy via bitcoin-dev wrote: > Small idea: >=20 > ease into getting rid of full-rbf by keeping the flag working, but make > enforcement of non-replaceability something that happens n seconds after > first seen. >=20 > this reduces the ability to partition the mempools by broadcasting > irreplaceable conflicts all at once, and slowly eases clients off of > relying on non-RBF. >=20 > we might start with 60 seconds, and then double every release till we get > to 600 at which point we disable it. Making replacability turn on _after_ an expiry time is reached has been suggested before, IIRC by Matt Corallo. However I believe the approach of enabling full-rbf _until_ a time is reached is clever and novel. I'd suggest doing both at once. Long-running txs are certainly useful. But = if a tx hasn't been mined in a few blocks, it certainly can't be relied on for zeroconf. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --7xZG4+OLekTtL899 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmG+H7QACgkQLly11TVR LzerEhAAqdDnFedH86hLYnQFaDpUi5XL+9yYqqycNKCA3kH1/x9qjzuwEKvpYb7O GTfmiqeEC8OpBovmRfbS0dNkm0PKTRdyPCNx/DD/2sa6MTZB6ceaqI1eNFvu0wBe AD+frQMOeguGeocjYDB1WWEaD4LdF1CTYDyTVLh8IzbO1rXYvCdAq9TN6GWI7Var ibelo9qLDkvoQgMObQBfaQVNOvofQaQwBVAAbUisa0IXdMP1Y8XRPwqhhvBPIisM jRnV4oNXyegqSYJ2oSFLFuUqN4RNodwgu7hxilU1HPnJdXMj9r0t+usxJ/cqIuN9 ILPAODssKhyI0BQQF/HgW8PYFY3Iz/vS1vGSzBL1VCoURdOqvPjHuWdy8+C7JR85 7t2DfshIoKStNkEyvw/ecRRkiS4683CfgL8dEkXCIWhtsenmZZ4eyomotFIVf4u2 w1Ym8JLNBAKYbjNquwjABIIZygtxSGnSdnri+HH5wlUTfGSm4tie4QalD4TG+WC3 uFO/NOIbUvUX50OHBgO3zv8ka83OCQ9adx2aaSSLnAvXpCvj9r+2DWDGa143t/7D /ukiG3z/Mh0isjIAd7CDqGxjCVXCfANU8Y48KthtVrtDl1sP7zBGWjpFcqxJU/+X rpRDluOd5734txbpkSxIpOPX72obsdV2hSqLVOvrxr1GYY5VfAU= =a3eL -----END PGP SIGNATURE----- --7xZG4+OLekTtL899--