Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8A16FC0032; Sat, 21 Oct 2023 01:25:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5FD724EE9A; Sat, 21 Oct 2023 01:25:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5FD724EE9A Authentication-Results: smtp4.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=WZG1VYiC 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4ThQfn5TdqD; Sat, 21 Oct 2023 01:25:26 +0000 (UTC) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9D2ED4EE7F; Sat, 21 Oct 2023 01:25:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9D2ED4EE7F Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6425532009D2; Fri, 20 Oct 2023 21:25:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 20 Oct 2023 21:25:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type: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=1697851519; x=1697937919; bh=5eCpWAsEJBiPr QT28gdw0/8AN9UP+x/urI0jg0rdMJI=; b=WZG1VYiCdiwnxqF0ekaG281oyFsi0 HaKq589KX2PGdq2rVqPMNAvcA1oUUFSA50zI8iy8CzjkPivQ0inN3WnZJmC0lz3D v/mGAKhiVIJzn0Qu18WAB27pRoF02fOXwPhxWMZl/DSZWOg7yZRtPr5Y4Hpt3a/B ZdZrZsInq/iXSz36PlfOSGK8sw40aYhWO360AHSIcI3dJKskpD8neqBHjtypJ77l 03J/FOj9yC6RXbDu0FrlBXFQCZvVTJCw4lFJUCkZ9rePhO1NHczt5JtmcYZHnL9d dUPtgZ6Z7U65QiWisJcIWlMwqF/on/Q0ygwm6IXOV6xudbW9DFb3t5R0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjeelgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefhjedt necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho rhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 20 Oct 2023 21:25:18 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 179B85F86A; Sat, 21 Oct 2023 01:25:10 +0000 (UTC) Date: Sat, 21 Oct 2023 01:25:10 +0000 From: Peter Todd To: Matt Corallo Message-ID: References: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com> <1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com> <24a18bdd-eef6-4f96-b8a5-05f64130a5c5@mattcorallo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uDTc95ZsopYJCxIO" Content-Disposition: inline In-Reply-To: <24a18bdd-eef6-4f96-b8a5-05f64130a5c5@mattcorallo.com> Cc: Bitcoin Protocol Discussion , security@ariard.me, "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" 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, 21 Oct 2023 01:25:31 -0000 --uDTc95ZsopYJCxIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote: > > What are anchor outputs used for other than increasing fees? > >=20 > > Because if we've pre-signed the full fee range, there is simply no need= for > > anchor outputs. Under any circumstance we can broadcast a transaction w= ith a > > sufficiently high fee to get mined. >=20 >=20 > Indeed, that is what anchor outputs are for. Removing the pre-set feerate > solved a number of issues with edge-cases and helped address the > fee-inflation attack. Now, just using pre-signed transactions doesn't have > to re-introduce those issues - as long as the broadcaster gets to pick wh= ich > of the possible transactions they broadcast its just another transaction = of > theirs. >=20 > Still, I'm generally really dubious of the multiple pre-signed transaction > thing, (a) it would mean more fee overhead (not the end of the world for a > force-closure, but it sucks to have all these individual transactions > rolling around and be unable to batch), but more importantly (b) its a bu= nch > of overhead to keep track of a ton of variants across a sufficiently > granular set of feerates for it to not result in substantially overspendi= ng > on fees. Quite the contrary. Schnorr signatures are 64 bytes, so in situations like lightning where the transaction form is deterministically derived, signing = 100 extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s connection can transfer that in 64ms; latency will still dominate. RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you= use those 100 pre-signed transaction variants to do nothing more than sign every possible minimum incremental relay, you've covered a range of 1sat/vByte to 100sat/vByte. I believe that is sufficient to get mined for any block in Bitcoin's entire modern history. CPFP meanwhile requires two transactions, and thus extra bytes. Other than = edge cases with very large transactions in low-fee environments, there's no circumstance where CPFP beats RBF. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --uDTc95ZsopYJCxIO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmUzKHQACgkQLly11TVR LzeLmQ//YSQoAQfDX/A0Vqi3ULLfy0mqQOIC3USczFPjg5u3vWFe6E6KfAsl89ao rTGWxhrkwX1Ha20wJtW/nEmEOCuPmVb+qw9TrQsUU7hykN1cS48nQSOP4RcQGTJc i423jSHdtqH1Fv5/Xcdp0X8CC3Uei39/djHBzl5YOk/tSUKO3dRa9/fpXETkeu/7 4KFYF0mnjyPeajBj5QwgKUtWHei9zs0QU6omIA+cwTgGW9P9yHWTmiukZV3CYsjP YPrpjm1J67KDFPxln/Ue0EJwxAUKDfsOWRBb+z21nvPoXdVPcJA2GYtbWuCoB7Zt bEtUFZs6/j1rFURLuE8anCqCWl36hqUibtyvQ5lVK2dya/vCDfSEe6+5aoo4kInq M20kzZWdfVNp+EsDEBz66mwdiltspre0jqgrrpOVUM8jMfwYeaGy4z3gP+eo2R1y hUhzWawOMUeeB9eVECwwgtx1zMARNn0vPNF7jnSI0Dq48H5lOO/kOKWzggYh9QGb bKAEOwmb7Z70ulAqvqAQej03Ie8CVrmAFHEZrEnALrUgzIIdg8wZ3xq0isbJCRUl NDjon9T10593L81cWSY0M6s7x7nOHEF2POikYF73D0Al3IH1/OvVGHJSA2naA1GW Z1jYzuHp92VT3RYWl10H/XwuIDDGIF/XlaMtzugX7sLLCNoFhcg= =bboX -----END PGP SIGNATURE----- --uDTc95ZsopYJCxIO--