From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9249FC002D for ; Thu, 20 Oct 2022 22:52:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 61B7E60D80 for ; Thu, 20 Oct 2022 22:52:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 61B7E60D80 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=ppA04AeZ 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 SwtIwafDLhoM for ; Thu, 20 Oct 2022 22:52:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E818A60D78 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by smtp3.osuosl.org (Postfix) with ESMTPS id E818A60D78 for ; Thu, 20 Oct 2022 22:52:06 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 248235C0083; Thu, 20 Oct 2022 18:52:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 20 Oct 2022 18:52:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1666306326; x=1666392726; bh=5CXR4dZXH/exrzzinZvnsJMqpkX+ TUjtcVC0jkWe6aM=; b=ppA04AeZL0hQ9EIUGPo7lvlpR/Fyu8RUUjBQNaTQCrib zes34vBnyQzaoKBS+ooHaNSk+9vwZYMDZH28IV3uHnDmhjrNe/ITQ0F0a9mHnuOr qh5av0fkX9dL/QHw2e+jSXwkHlCLMrRws2aQ/0QpkvqlmDKH0kbdKW9ljFMf9/UE ST7wF4ewiiBQJtxH+xi6WcX5bG7HeKX8FR4oGNAi/PFb9KK/4Ue4Qv+GZ60WeFuM 5dXMC2PUz6DCnyKhoGHNfnn6xB079L3+k5wEp2m4m5sD43SzVscWSiokh6pOhDcS jQxfUnok0poVUHPsP0QqM/TvwEubRGsb6nbrzcvRQg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeljedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhepiedvvdelieekjeeukefgtdelfeegheehleffueehteeghfelveejfeelgeevffef necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepuhhsvghrsehpvghtvghrthhouggurdho rhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Oct 2022 18:52:05 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A203F204BA; Thu, 20 Oct 2022 18:52:03 -0400 (EDT) Date: Thu, 20 Oct 2022 18:52:03 -0400 From: Peter Todd To: John Carvalho , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fji6oTZc/OXz86eb" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) 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: Thu, 20 Oct 2022 22:52:08 -0000 --fji6oTZc/OXz86eb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2022 at 08:23:20AM +0200, John Carvalho via bitcoin-dev wro= te: > Simply, 0conf acceptance can be monitored and enforced by the merchant and > exposure to doublespends can be both mitigated and limited in size per > block. It is less expensive to be double-spent occasionally than to have a > delayed checkout experience. Responsible 0conf acceptance is both rational > and trusting. >=20 > RBF assurances are optionally enforced by miners, and can be assisted by > node mempool policies. It is not reliable to expect replaceable payments = to > be enforced in a system designed to enforce integrity of payments. RBF is > both irrational and trusting. My OpenTimestamps calendars all use RBF for optimal fee discovery. The fact= is, about 95% of OTS transactions mined are replacements rather than originals.= I also took a quick look, and found examples of replacements mined by Foundry USA, AntPool, F2Pool, Binance Pool, ViaBTC, SlushPool, Luxor, MARA Pool, and Poolin. That's at least 97.21% of all hashing power supporting opt-in RBF. Are you claiming that almost all hashing power is irrational? > RBF is a whim of a feature where engineers made the mistake of thinking a > hack that basically incentivizes rollbacks and uncertainty might be useful > because we can pretend Bitcoin has an undo button, and we can pretend to > game the fee market by low-balling rates until txns get in. Electrum *literally* has an undo button, implemented with RBF. I've used it= a half dozen times, and it's worked every time. > Miners serve full nodes. What is more likely, a node set that prefers > blocks with replaced txns, or a node set that rejects blocks with replaced > txns? Has anyone _ever_ implemented a node that rejects blocks containing double-spends? I don't believe the code to reject such blocks even exists. = Note that it should: that's a terrible idea that could lead to sever consensus problems. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --fji6oTZc/OXz86eb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAmNR0Q4ACgkQJIFAPaXw kfunNggAgLy2ksIrK1Lof1lLzFfn/j1lxx9JfreK6JtVwHs4cR39drNsxX0PPGvw /ztO3o2EeBvILnnnR2JFp5kblDwBcUXH/u6mqPLIK3+YdNcH0Q2h62gCiRHBy+7b nndo12LNXmMpnuO8Mwrj2OU56uhza/6JfZsj4NmTaIinlupJj5X3joLq5p9UuVqH vmawLPPItGcbykrsl1lJB2G/I8Y62CALVt6q7o/014zxdmuEnxRliPH3YJJ4/P4p AfAfo+LVfT5MaKOc6WI5b8Yd4b4IeCMnMVQi+zLjMnFl22FZINZIwjov5sLuYrCA XAWK8Me8Cim3J7taxuZnCJ9nKDn60Q== =X7lH -----END PGP SIGNATURE----- --fji6oTZc/OXz86eb--