Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 238B7C002D for ; Mon, 7 Nov 2022 14:32:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E49E6400D3 for ; Mon, 7 Nov 2022 14:32:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E49E6400D3 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=u3/P6/bu X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NELhs8Pahm-n for ; Mon, 7 Nov 2022 14:32:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8456A401AF Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8456A401AF for ; Mon, 7 Nov 2022 14:32:25 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EE3875C00C9; Mon, 7 Nov 2022 09:32:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 07 Nov 2022 09:32:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm1; t=1667831542; x=1667917942; bh=y pVveW+NNy2vbTzx1U1ti37uzWIYpjQDEsN3LaJOEog=; b=u3/P6/bu2OBrkRBDG P/I8iXZafnrASA2NGo2YB+LJjVC8lmtXlWCC+XvplPh2/iaxAFzNeCDd1EH9cIyP 7xYqXcWtLsxQVxMOoAwmFJBvoY5ajJgRNCpaL0TS8aTKXTsfbrWAkuUvmNxrvXMS ajsHZnUMKwCqNnx97rgJPJ059bXcpM2K3iIRP+QYVsC4e/9q4Qo0txYopAmrn1lb SW6FaRqTEL01FJlKkVHWa7hnM8+kxEKkFOkVWFtSf3v02X1HtZz95TS27uCwCHl+ 2tXGe+uAdKX6sVGzs98ko+bPNj4g4s4kRmfpVh6mIE4B7tC8zymKKtPYt2s4xmil G97Zg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvufgfjghfkfggtgfgsehtqhhmtddtreejnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhephfetueelffdvudejjeetjeejgfejfeelieeijeduieeivdeugefffeeugeelgfeu necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvth gvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 7 Nov 2022 09:32:21 -0500 (EST) Date: Mon, 07 Nov 2022 10:32:17 -0400 From: Peter Todd To: email@yancy.lol, Bitcoin Protocol Discussion , yancy via bitcoin-dev , Anthony Towns User-Agent: K-9 Mail for Android In-Reply-To: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> References: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> Message-ID: <0A6B5781-EBC6-4D98-8AE8-43436B5F73EA@petertodd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 07 Nov 2022 14:32:27 -0000 On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev wrote: > >AJ/Antoine et al > >> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to >> solve that problem if they have only opt-in RBF available? > >Assuming Alice is a well funded advisory, with enough resources to spam t= he network so that enough nodes see her malicious transaction first, how do= es full-rbf solve this vs=2E opt-in rbf? First of all, to make things clear, remember that the attacks were talking= about are aimed at _preventing_ a transaction from getting mined=2E Alice = wants to cheaply broadcast something with low fees that won't get mined soo= n (if ever), that prevents a protocol from making forward progress=2E With full-rbf, who saw what transaction first doesn't matter: the higher f= ee paying transaction will always(*) replace the lower fee one=2E With opt-= in RBF, spamming the network can beat out the alternative=2E *) So what's the catch? Well, due to limitations in today's mempool implem= entation, sometimes we can't fully evaluate which tx pays the higher fee=2E= For example, if Alice spams the network with very _large_ numbers transact= ions spending that input, the current mempool code doesn't even try to figu= re out if a replacement is better=2E But those limitations are likely to be fixable=2E And even right now, with= out fixing them, Alice still has to use a lot more money to pull off these = attacks with full-rbf=2E So full-rbf definitely improves the situation even= if it doesn't solve the problem completely=2E