From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1BA4AC0175; Wed, 22 Apr 2020 11:52:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 1750F87EA9; Wed, 22 Apr 2020 11:52:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWAEx9XRS5em; Wed, 22 Apr 2020 11:52:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by hemlock.osuosl.org (Postfix) with ESMTPS id 14EB687EA7; Wed, 22 Apr 2020 11:52:34 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1jRDvb-0007k5-MJ; Wed, 22 Apr 2020 07:52:31 -0400 Date: Wed, 22 Apr 2020 07:51:30 -0400 From: "David A. Harding" To: Olaoluwa Osuntokun Message-ID: <20200422115130.4iinxmmtlbcefyx7@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i4wy6i4hw6p3ggir" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest 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: Wed, 22 Apr 2020 11:52:36 -0000 --i4wy6i4hw6p3ggir Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote: > On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev = wrote: > > While this is somewhat unintuitive, there are any number of good anti-D= oS > > reasons for this, eg: >=20 > None of these really strikes me as "good" reasons for this limitation > [...] > In the end, the simplest heuristic (accept the higher fee rate > package) side steps all these issues and is also the most economically > rationale from a miner's perspective.=20 I think it's important to remember than mempool behavior affects not just miners but also relay nodes. Miner costs, such as bandwidth usage, can be directly offset by their earned block rewards, so miners can be much more tolerant of wasted bandwidth than relay nodes who receive no direct financial compensation for the processing and relay of unconfirmed transactions.[1] > Why would one prefer a higher absolute fee package (which could be > very large) over another package with a higher total _fee rate_? To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults require each replacement pay a feerate of 10 nBTC/vbyte over an existing transaction or package, and the defaults also allow transactions or packages up to 100,000 vbytes in size (~400,000 bytes). So, without enforcement of BIP125 rule 3, an attacker starting at the minimum default relay fee also of 10 nBTC/vbyte could do the following: - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total fee) - Replace that transaction with 400,000 new bytes at a feerate of 20 nBTC/vbyte (2 mBTC total fee) - Perform 998 additional replacements, each increasing the feerate by 10 nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes (including the original transaction and first replacement) to ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte (1 BTC total fee) - Perform one final replacement of the latest 400,000 byte transaction with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee) Assuming 50,000 active relay nodes and today's BTC price of ~$7,000 USD/BTC, the above scenario would allow an attacker to waste a collective 20 terabytes of network bandwidth for a total fee cost of $10.50. And, of course, the attacker could run multiple attacks of this sort in parallel, quickly swamping the network. To use the above concrete example to repeat the point made at the beginning of this email: miners might be willing to accept the waste of 400 MB of bandwidth in order to gain a $10.50 fee, but I think very few relay nodes could function for long under an onslaught of such behavior. -Dave [1] The reward to relay nodes of maintaining the public relay network is that it helps protect against miner centralization. If there was no public relay network, users would need to submit transactions directly to miners or via a privately-controlled relay network. Users desiring timely confirmation (and operators of private relay networks) would have a large incentive to get transactions to the largest miners but only a small incentive to get the transaction to the smaller miners, increasing the economies of scale in mining and furthering centralization. Although users of Bitcoin benefit by reducing mining centralization pressure, I don't think we can expect most users to be willing to bear large costs in defense of benefits which are largely intangible (until they're gone), so we must try to keep the cost of operating a relay node within a reasonable margin of the cost of operating a minimal-bandwidth blocks-only node. --i4wy6i4hw6p3ggir Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6gL8IACgkQ2dtBqWwi adPTEBAAlW1qfNAZHScJ878tSxYls66RGHLennzvEQcjojkZpe8/0vVR0rKYO2Ei s+fy1gZaTSVH0xC51OyEG+lAwx6k2iS5pO655pf/s/haJb19FEzrMM3Unw9oO1SR xqaIY4BiBzdd/CREo6PJ+oMRw4zaqf7ZTqlF1KRN0rUWGQZ0a8kaNwTpfHKDtuH6 5iicHatBmY2fUGAaD81eM3167a3rqDxuM51GTJk6nU6pgnjHGwaMfgb8kK7XDhCF pXE/cqEmmTbO44Cwg7YrBVLXb/bDOIZkTy5pcDKFxlBuxV5hNzG+ezXC4PDObJqV YL8o7YkutEMXDVvuxpK1PI4GYj9ogWyyjL23p8jbUjOM2Ra3VeNfdhlo4MiX14MN 1HMACM/TJCui9eteVLkazG6Nm8XRbRB/+Bvj0gUyJieKlWfkoZBUEJIkrznXrQOq zxs8E7ZeC9ieZmRdcfFQfDAczZvznwXlSEw8ofvm01Oyt009WUbG9jtBBde1rIyX abzoJxSzA+xtL3ELfHSiWqXdgEF/58uI0gKFPhFCe8aj+srYxkFl75LkwgjIg5Ns LKYwHSw4pNVkW+eAwV/T9IVbr5vuqFXQuG1+K/IfHWd+c7ixT7yg897V0R50Zw8Y ikIb5Chh986pwx1NVch20pWukdNyiRuxa0OrPoa+4Hx+A9tcxV0= =njA6 -----END PGP SIGNATURE----- --i4wy6i4hw6p3ggir--