Delivery-date: Mon, 22 Jul 2024 11:00:33 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVxKq-0005na-BE for bitcoindev@gnusha.org; Mon, 22 Jul 2024 11:00:33 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-260ff7f8381sf4164747fac.0 for ; Mon, 22 Jul 2024 11:00:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1721671225; cv=pass; d=google.com; s=arc-20160816; b=zoohXcrDjscw6rBupHa6b0YPAN5AEsA883FE2okRwXVMWzyRq+24vudAbvtw5gX6C1 8yDGC0LRkaG9X/feSE1QCRX/yOF/Unhso7l2FkSg0eOWRo7/sZb8/0BQZrG0/A6S8vZ4 0lvaWZuEXQYCqlIue5U3NL+Sjx9vh62LD8E+5KbKxXH6dwOoNOi01sblB8oX9i69Af0O uAzCYVlUro/kavV9xtlBIYxi3cUq43ML7UPR+iUPpiJhGr/m9hQr4LvLE3qGPYmqHd3f 5fDZ9tqEFud2xRjaRB+KeNJdQR7HvTDui0nnPUW+IKm+EUj3fFVNKSWoFdHf+S/yZTq1 sPOw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:sender:dkim-signature; bh=+hfA1238bBic8/4I4IkglJUauORvNB2UBYrScvQW/xk=; fh=f6/s/WOZ+Tkv9KZlHD76D/4Z9jN0B3DK7MQvWoH2RZo=; b=SZVvktqgrQaIB9TVLWf03OEgFwv8u+3n4PTPAc+I2Q6CzwKmMYpXAqqZ7CD22vYU2T UZaSF/D13Crk/XxzNySP7lCo3meiwGktTJM2Y0P70sBSM9YcsOvXbIvXiNjyX8IM/fek nPPK05FtXvGQlJiqSdA2BxjAuXpNfDDhPpk7EvF6mqyWcNGT2jaPr/xqZn7KijhR4V/x KqWyzG9qFThIIHhgvEMKfCEUOMQj3lpQ30jQQ60lK8cdDo9ME2EdV6J6M2Ht52CqWwqH su3uP7ED100wj2DgPNLf1+Vc7sTKl0xOU1Maak/O+UYpybzQ6A61wPk851hWVspvngbZ u2zA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=bEpCEvUV; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.147 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721671225; x=1722276025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=+hfA1238bBic8/4I4IkglJUauORvNB2UBYrScvQW/xk=; b=Fs3q7SN8hkGiivPq7Cq0rWdUnwBRhIYLezqeXvOnOhfiisTL0xv72iVvzdDD0O9Iz/ jX1wdDOEJyEO9tEgmq/YdMNYd1Se0F1cdeifEcbP4+Tc547A7JcyElfBVzwgHjdySjvf avlW6A8+IjQLKRVNbtQdtFxD9xJlRr7Upp4Zk55RgOyubR7I27n6dnNk6bMI+WifWi3+ kUAN6yXKyI4yhtdRpAuG7B+40agpAIkohaTPfEmV5syVzgTT+s44tI2N2iaxNhJvdofj +dxtPpcLylczb8/sD2RhjNiNYIxBtaM54OK1IgdW/yS+ElIUPxFi4aWJLw7s4cSIEpvV 6Y+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721671225; x=1722276025; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=+hfA1238bBic8/4I4IkglJUauORvNB2UBYrScvQW/xk=; b=TvgW24KNf0XU1XZTJYF3eYRGhWX3zGz4eLN6ZWb3RT2iuDGTuSRz6m3W65er5VoBBz he44uxSo0nT6QzWw9t8mxij9pKV4h1QJacw416BoO7ivZsAV2lLp/qI3Bwr74sUXBi8O HDrmms2vL5v1A0Ri11N2I6rpgwT2QteCUAXhJ5lF9aRWbt5I26jfiBPVtpQ5qqs2mipt bU1A910yOuesDNEaXDNt9NI3eBmHWfJ+dmQMbODfjncGm5Yim03BtxlRGYCtdSPRNe1R rG3kmNhH6oz29im7Eqc8deb+EAfL5RIXrC3rI/RxOfirp73SUg5ZyTP42qI/hPazhpQV TB4g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXf5Rzme4hmH/T+7vzYQUaoxH9cKrjt9W+WT/+cyERLajdjB4EbxmoK1++qokuqNZnz13et5xV1sp/P1tV9M5fIigia+6Y= X-Gm-Message-State: AOJu0YwEJi+bbQinYBAKiw/S6KPatN6Lkw0+6Gm8BYDXjj9ATDyQ7Pog QBa7yG/MssCc9Ato7vf513ZWvDO0raWRPsxbIfPve+s8yLACTSE6 X-Google-Smtp-Source: AGHT+IHbKMUwxloRSAqPRPkKTbqCgDhhW8+JpJToZu5ydhhqloLbM5J1oJ6Xy5BcE4ipudubXtPRqA== X-Received: by 2002:a05:6870:b1c2:b0:25e:922:57a7 with SMTP id 586e51a60fabf-2638dfb011bmr6958509fac.1.1721671224789; Mon, 22 Jul 2024 11:00:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6870:4e01:b0:264:3056:9e20 with SMTP id 586e51a60fabf-2643056a041ls3560363fac.0.-pod-prod-09-us; Mon, 22 Jul 2024 11:00:23 -0700 (PDT) X-Received: by 2002:a05:6870:3045:b0:260:44a4:c8b5 with SMTP id 586e51a60fabf-261216174b8mr307610fac.7.1721671223196; Mon, 22 Jul 2024 11:00:23 -0700 (PDT) Received: by 2002:a05:6808:329a:b0:3da:a27f:25ca with SMTP id 5614622812f47-3dadf206240msb6e; Mon, 22 Jul 2024 10:13:57 -0700 (PDT) X-Received: by 2002:a05:6830:dc4:b0:708:bea8:ae3f with SMTP id 46e09a7af769-709009b1513mr10046063a34.25.1721668436717; Mon, 22 Jul 2024 10:13:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1721668436; cv=none; d=google.com; s=arc-20160816; b=QBK8rx0HMS/Ch9UpY7BvCZSy6udzNoeCwquaAQDdc/OnEM975OTW8ayniwmt+nC4YG 1aHDBbLvpyKSkbOv9SEvW1k6XUFdfARfLxuEo/MzU89hezrPJLVCD1ZkoUSu6WP3ELFE oUU3Ubnq64ZsjJ8GIqvFo9Oo+9oFCy+oFu5J7xN0P8NRt3iVLO1SdcBbWN2iiO1GTEdc oGDOG3AReXHLlcO3yjmuH9IwBwduwjSP9GLijK/lEbdOOzoeJ4Se9nlzmrPuSxDn6d3v aTaurYhlZjFw+mjSMMz7ON6/DH+1ruR8mpKCCWFuBMG0wxLMQJXuTnXtPvXaoBewc9Zp 2FEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:dkim-signature; bh=0FSLfyL/BKsz3G1Mx40ulIw74kUQXUCpx3s9bSpwTnk=; fh=qAkUFgesXJOBZlEhHhc6qjOrC9x9vwcQK9K5cSmyNz0=; b=lmXILKsVg+9070L84+DJzfYZSnpNyUKLfTM3w8nHYSjZFe7nUC0TJ2CxZl/rlUdJUb 0QiltZa0PsbrFFLmXivJbkatbTbGuMEMs9DT5mOe2MXe7So8Auq6C0Xpvj3SEY1RE116 87fI+CuJZDXornnIIRkOnVrZCMKxYNY1I6ep7+5NDtzN493BPgAV0qLvfzGF6SwMY6qI Lgi94MHgnfLpAJcC5Gs5fvqM9NONImxN+bg4EOIsj+kMIpIxjcr/rLprhI9sKxCO/DB7 vAk5077v/EJMSRhP45KJdTSNUBBwhewzu3SZU5zPq11g4PY9YdiD76bO1bXAlv9QTHJR n+IQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=bEpCEvUV; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.147 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fout4-smtp.messagingengine.com (fout4-smtp.messagingengine.com. [103.168.172.147]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-708f60adf88si356765a34.2.2024.07.22.10.13.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 10:13:56 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.147 as permitted sender) client-ip=103.168.172.147; Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.nyi.internal (Postfix) with ESMTP id 2CF1013800B5; Mon, 22 Jul 2024 13:13:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 22 Jul 2024 13:13:56 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheejgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpeefhfdvjefggedvjeehveeihfdvffehffeutdfgteettefhhedtueetueelueeu tdenucffohhmrghinhepghhoohhglhgvrdgtohhmpdhpvghtvghrthhouggurdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv sehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 22 Jul 2024 13:13:55 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 849725F83F; Mon, 22 Jul 2024 17:13:48 +0000 (UTC) Date: Mon, 22 Jul 2024 17:13:48 +0000 From: Peter Todd To: "David A. Harding" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/GffXKu588ogAARA" Content-Disposition: inline In-Reply-To: X-Original-Sender: pete@petertodd.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=bEpCEvUV; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.147 as permitted sender) smtp.mailfrom=pete@petertodd.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 1.2 (+) --/GffXKu588ogAARA Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote: > > I believe the authors of [BIP431...] don't want to admit that they've > > wasted a large amount of engineering time on a bad proposal. > > You've previously argued against designing contract protocols to depend > CPFP-style fee bumping for their offchain transactions, however that is > what is widely used by LN today and it appears to be what LN and other > offchain protocol developers want to use in the future. If we accept > that, at least for the purposes of argument, what can we do to improve > CPFP fee bumping for LN? To be clear, the reason why I came up with one-shot RBFR was _because_ I wanted to find a pinning solution for CPFP (and SIGHASH_ANYONECANPAY) transactions. If everything could use pure RBF, eg via pre-signed transcations, RBFR would be much less useful. > All we really need at this point is to enable package relay so that > parent transactions are no longer subject to a dynamic mempool minimum > when they're bundled with a high-feerate child. Preliminary support for > that should be released in the next major version of Bitcoin Core, with > improved support being worked on for later releases. > > Package relay is the only thing we need at this point because the > existing LN protocol makes use of CPFP carve-out, which minimizes > transaction pinning issues. > > However, another substantial Bitcoin Core improvement, cluster mempool, > is incompatible with CPFP carve-out. TRUC is an alternative to CPFP > carve-out that is easy to reason about, easy to use, more general in > nature (good news for newer contract protocols), and which can possibly > be automatically applied to existing LN onchain transactions, allowing > cluster mempool to be deployed ASAP without requiring any significant > changes to anyone else's software. So as I explained in my stand-alone email, we can cleanly get rid of the CPFP carve-out with RBFR *without* needing to change anyone else's software: https://groups.google.com/g/bitcoindev/c/vfbF7QyVwPE/m/-ewtlB5-AQAJ TRUC does _not_ allow cluster mempool to be deployed ASAP. It requires all existing L2 protocols that need the CPFP carve-out to upgrade, and likely close and reopen channels. This is a massive downside to TRUC. > As you've shown[2], the main downside of TRUC transactions (if we're > going to depend on CPFP-style fee bumping anyway) is that users of TRUC > transactions who have a malicious counterparty might need to pay a > slightly higher onchain feerate than they would need to pay under the > same situation with CPFP carve-out. However, the increase is small > enough that most honest parties should be able to afford it, so there's > no incentive for a counterparty to do it. As I explained months ago, the oddly high 1000vB limit chosen in TRUC allows attackers to make TRUC users pay significantly higher fee rates in many mempool situations, including the situation we are in right now: https://petertodd.org/2023/v3-txs-pinning-vulnerability At the moment, a typical TRUC using LN transaction can, IIRC, be forced to pay something like a 4x higher fee as the difference between "will confirm in the next block" and "won't confirm for days, if ever", is less than 1sat/VB. I suggested that limit be reduced to something closer to a typical CPFP use-case, and my suggestion was rejected. This gets even worse with keyless ephemeral outputs using TRUC, as *anyone* can itercept one of those and create a pin. An attacker could, for example, run compact block enabled nodes and simply wait for LN nodes using compact blocks to broadcast keyless ephemeral output, CPFP-using transactions, detect those transactions, and automatically pin them. > The alternative to TRUC that you've proposed is replace-by-feerate > (RBFr). This is also compatible with existing LN transactions and it's > conceptually super simple (I assume the code is too), which is > wonderful. However, it's downsides are: > > 1. It fundamentally enables a significant amount of free relay. I'll > sketch a super basic attack at the end of this email that costs 0.55 > BTC per day ($67,000 USD) to 100x the amount of bandwidth used by > relay nodes. I'm sure more efficient attacks are possible. See my analysis at the end. You are analyzing the wrong thing, and missing the fact that comparable attacks are already possible. Indeed, even attacks that are probably much *worse*. > An attacker who is able to consume an excessive amount of relay node > bandwidth at relatively low cost may be able to create both > short-term and long-term problems for all Bitcoin users. If the > created problems result in a rapid increase in user feerates, then > free relay attacks become cheaper due to low feerate transactions > being automatically evicted from the bottom of the mempool. Relay bandwidth and fee-rates don't have any direct connection in Bitcoin Core. Fee-rates are set by users outbidding each other. Unless an attacker is willing to outbid actual user transactions, paying money to do so, they can't make fee-rates increase (modulo certain exploitable/broken fee-rate estimators making bad assumptions about mempools, but that's not a new problem). > 2. It may allow empting the mempool at relatively low cost. An attacker > sending just 750 transactions at the top mempool feerate can > guarantee eviction of every honest user's transactions. The attacker > can then replace 300 MB of transactions with a single 43,179 vbyte > transaction. Even if the replacement transaction pays 100 > sats/vbyte, when you compare that to the 1,000,000 vbytes of > next-block transactions each miner lost, the miner is only earning an > effective feerate of 4.3 sats/vbyte. I covered that attack in my one-shot RBFR writeup: https://petertodd.org/2024/one-shot-replace-by-fee-rate#fill-and-dump-attack It's not a concern for a few reasons: 0. It's a class of attack that is already possible without RBFR: obviously, you can fill and dump by simply double-spending your fill transactions. Eg, this is obviously easy to do with full-rbf! 1. One-shot RBFR - my actual incentive-compatible proposal - is not vulnerable to fill-and-dump attacks the way you described, as you can't "dump" the top of the mempool with one-shot RBFR. The "dump" transactions won't be accepted, as one-shot RBFR only allows you to replace transactions with a low fee-rate that won't be mined in the near future. 2. Miners routinely run with much larger mempools than normal nodes. As I mentioned elsewhere, in my discussions with miners, mempools of 1GB or more were common. 3. Rebroadcasting is easy. Anyone can rebroadcast previously broadcast transactions. If people actually tried fill-and-dump attacks, all they'd succeed in doing is briefly kick out some transactions from typical mempools, at the cost of creating a bunch of higher fee-rate transactions that will most likely get mined at great expense to the attacker. > Further, it's easy to imagine situations where evicting > time-sensitive transactions from mempools might allow theft of funds > in excess of a few thousand dollars (my immediate thoughts go to > situations involving watchtowers). Watchtowers are actually a uniquely *bad* example. Recall that watchtowers merely broadcast pre-signed justice transactions in response to a revoked commitment transaction being mind. AFAIK, all existing watchtower implementations pre-sign the transactions with a fixed, high, fee-rate. What they actually should do is provide the watchtower with multiple pre-signed transactions at different fee-rates, up to the economic maximum. But I digress. As explained above, rebroadcasting is trivial, and watchtowers are expected to run 24/7 anyway. Secondly, one-shot RBFR prevents the replacement of any transaction that is expected to be mined soon. So if the justice transaction was signed with a high enough fee-rate to get mined, the only thing the attacker can do is outbid it (and all transactions before it). Which is true without RBFR anyway! Finally, in general, while applications like Lightning are time-sensitive, they're not *that* time sensitive. LND uses 144 blocks as its default CSV delay, giving you an entire day to get a transaction mined. Doing fill-and-dump attacks dozens of times in a row is not cheap. > 3. Limiting the worst-case free relay and excessive mempool eviction > requires additional rules (e.g. one-shot RBFr) that are challenging > to implement and analyze at present, as several devs have noted[3]. > Both implementation and analysis should become much easier if cluster > mempool is deployed (also noted by devs), but the deployment of > cluster mempool requires removal of CPFP carve-out, and removal of > CPFP carve-out requires either the upgrade of thousands of LN nodes > and channels or a drop-in solution (ideally one that can be analyzed > independently from cluster mempool, like TRUC). As I explained separately, you are very incorrect in your description of the CPFP carve-out. In fact, it's RBFR that is our only path to having a cluster mempool without requiring existing applications to upgrade. As for implementation, it is true that implementing one-shot RBFR is harder without a cluster mempool. But fee estimation is something Bitcoin Core already does. It would be fine to either 1) re-use the fee estimation machinery to get a reasonable minimum one-shot fee-rate, 2) periodically generate a block and use the minimum fee-rate of that block. Mempools aren't a consensus, so it simply isn't necessary for every mempool to agree exactly on what the minimum one-shot fee-rate is, for the same reason that it's not necessary for every mempool to agree on the same minimum relay fee-rate. > > this is quite an odd case of Core politics > > I began writing this reply to force me to examine your claims for > myself. You have a long history of noticing things other people missed. Thanks! > A simple free relay attack using RBFr > > ## Constants > > 100,000 vbytes == ~400,000 bytes > A 1-input, 1-output P2TR scriptpath spend with the maximum amount > of witness data allowed by Bitcoin Core defaults > > 111 vbytes == 162 bytes > A 1-input, 1-output P2TR keypath spend > > ## Attack > > - Attacker obtains 500,000 UTXOs > > - For each UTXO > > - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000 > byte) transacton. > > - Waits for it to propagate. > > - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement > that is 111 vbytes (162 bytes). > > ## Analysis > > - At 162 bytes each, 500,000 transactions is 81 MB. I think that will > fit in a default-sized mempool. > > - The total amount of transaction data relayed is 500_000 * (400_000 + > 162), or about 200 GB. > > - The typical daily bandwidth requirement of a blocks-only node is > roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying > node is about the same due to compact blocks, but realistically, it's > a small multiple of that. Call it 2 GB per day. > > - This implies the attack push each RBFr relay node to use 100x a > non-RBFr relay node. > > - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At > my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats, > or 0.55 BTC (about $37,000 USD). > > - This analysis ignores the cost of obtaining the UTXOs and possibly > later consolidating them, but it also ignores some easy optimizations > such as batching the replacements. G First of all, subtlety of the class of attack you are describing is it matters a lot whether or not you expect the double-spend transactions to be mined in the near future. With one-shot RBFR - my actual proposal for Bitcoin Core - the fee-rate of the double-spend is required to be sufficiently high to be likely to be mined in the near future. With pure RBFR, which is implemented in Libre Relay as an _experiment_, the double-spend merely needs to be a higher fee-rate. This difference is one reason why I'm not proposing that Core actually implement pure RBFR! So the relevant question is, can you pull off this class of attack with Bitcoin Core's current relay rules? The answer is absolutely yes. The only significant difference is you'll be invalidating the big, "fill", transactions with transations paying economic fee-rates, either in a block, or likely to soon be in a block. Thus one-shot RBFR makes no difference: the same class of attacks are possible whether or not it exists. Secondly, your attack requires $37,000. That amount of money would pay for 2700TB of bandwidth at 0.01 USD/GB, the (expensive!) cost of bandwidth on Digital Ocean. There's about 20,000 publicly accessible nodes. So for that amount of money, you could just DoS attack all 20,000 nodes simultanously with about 185GB of data each. Digital Ocean is a very expensive way to get DoS attack bandwidth, so realistically an attacker would probably pay even less for the attack. Even worse, you could use that bandwidth to perform a conflicting transactions attack. For each publicly accessible node, broadcast a different, 100,000vB/400,000B, transaction spending the same UTXO. Each node will waste bandwidth telling it's ~100 peers (including non-public nodes) about that transaction, reducing the attackers bandwidth cost by a factor of ~100. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp6TTAJ399CKbY5s%40petertodd.org. --/GffXKu588ogAARA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaek0EACgkQLly11TVR Lzew2g//Wy67c/8Eh02NhzVaKPOo4svIOpPNGLmEiXfsmzQqSSWEDzfcIcIC2WK9 utfP6q+NOeDrlAmj9orgqN/a4h8dkyGw7EQgHr9itIt/eC2CcHpFc7uiXojEFtJ3 4QcJpmSPfDLbTfcyX9OIBtBtXT70vltq+aSk7JxvjSJc2c8QX5TmKQoDVWftRYvg 5ii1JSEhtE6A0rqFzpNdKkpRS/xJaWxeBJLu6hlGPvrWi6HtJ4cIdFsamh5u/9yA CJQQunwjSt6GDsG3xi3K6f9XsHNCdTFrebkay4tQk29IFiydY45S4XfrPQo2Vpji xVlDxvwAefFmI2lgiD+OScOVlPVyxPjYSK5PfO/V478vL+KzDkNYyW1ekaWmh2wE UQ/R1kaVsELzoXIV4XuXqguN0JrcfyTkReyXqEGEqGQKVQUFjBuM2JqdFvp72IUg 7vjccjnZUGrYkBEQP5NLfzV1a42gGMQScONy9zkg4/EtPqdlYCwUf5Ry7DpvczX3 M8PBsWxs2GTUdnIOrcW0gFfJ5VryAIYhITojvqMTcA73+ZA8l/ESBNtUfbMWmbTq J3mthKLutzWriHnvg3JczDf+IQymptu5+a3H5XyczjPyLzvLOv8jLnTyN4bKp49b bLo5avrM2cZWuhXXPy2M+oV3i+/cOD2C3lPDFSgT13L2fb8dcIk= =lnz8 -----END PGP SIGNATURE----- --/GffXKu588ogAARA--