diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-02-09 23:59:56 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-02-10 00:00:06 +0000 |
| commit | 319d532f47fb51f8321bb0695181b18d23c30821 (patch) | |
| tree | a51c9b788ce38a6076ca1f9d2635bdf6ad4194a3 | |
| parent | 912ab517a064fec9a7bf213b598ae6747fe0d417 (diff) | |
| download | pi-bitcoindev-319d532f47fb51f8321bb0695181b18d23c30821.tar.gz pi-bitcoindev-319d532f47fb51f8321bb0695181b18d23c30821.zip | |
Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
| -rw-r--r-- | b9/0621343d2c6b79d7da6fd8204cb44c9d8898be | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/b9/0621343d2c6b79d7da6fd8204cb44c9d8898be b/b9/0621343d2c6b79d7da6fd8204cb44c9d8898be new file mode 100644 index 000000000..6b20cd9dd --- /dev/null +++ b/b9/0621343d2c6b79d7da6fd8204cb44c9d8898be @@ -0,0 +1,219 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A7CB3C0171 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Feb 2020 00:00:06 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id 90D928734E + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Feb 2020 00:00:06 +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 Ngo+7NcWZMPO + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Feb 2020 00:00:04 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch + [185.70.40.135]) + by hemlock.osuosl.org (Postfix) with ESMTPS id 367438733F + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 10 Feb 2020 00:00:04 +0000 (UTC) +Date: Sun, 09 Feb 2020 23:59:56 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1581292801; + bh=uqLJAocTflV64A7DSvDjElMh5ZgETYVYO5aTw32xEkw=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: + Feedback-ID:From; + b=kr33PekGvseiR2GzbIK7dWwJGwzBQMRVWXkJt9ewulTvggpCDZ1YqPBKQzsEnC4R8 + pvrnpwleO7OmJBk131haVDEDftrCw2y6jszAKquZm/2aYCThaHbYf65JkVZuAAe9ny + hjTUS6z3xZe9/fpFxGQ3dv/Ba/FILgItHRXj0w60= +To: Mike Kelly <mikekelly321@gmail.com> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <MQqr0u8z7KvEmdMtR7wez_tcwJIaKbfcBSJkv4DrVeg_NlgiX9R-ILWlvb596VLEh74NrIMC1l0Wh0XOz1pcnywMjAtJ_m60LezEU9rrU5E=@protonmail.com> +In-Reply-To: <CANqiZJYvtmuoDh7eqH+2xYTqC=hxMEBV-+9rD4w30yC7v4o31Q@mail.gmail.com> +References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com> + <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com> + <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com> + <CANqiZJapjRvf5p=yD2BGqYxn_zR8HBHgU=ncKDROZbWersZxBg@mail.gmail.com> + <u0lEEiLwMX1seNC4Wz7nfizIB2zaj4HfINI9rnh0ZBPJkW02uMw-6HCWemKpz5xr8MYxkTQWpCa4ucnM5Qj82qBlgW5BnlUBd5Pv2f_Ho6A=@protonmail.com> + <CANqiZJYvtmuoDh7eqH+2xYTqC=hxMEBV-+9rD4w30yC7v4o31Q@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 10 Feb 2020 00:00:06 -0000 + +Good morning M, + + +> I don't see how the scenario you outline here has anything to do with the= + mechanism I proposed. An empty block doesn't contain any transactions (by = +definition) so it wont contest any transactions in any given node's mempool= +. The aim isn't to prevent empty nodes, it's to discourage miners from incl= +uding transactions in their block that conflict with the eventually-consist= +ent state of consensus in the mempool. +> =C2=A0 + +What? + +From the original post: + +> TLDR +> * An attacker replaces the most recent blocks full of transactions with e= +mpty blocks. + +Are you sure you are solving the same problem? + +The mempool **has no consensus**. +It is strictly an optimization, preventing a node from needlessly broadcast= +ing transactions. + +Making consensus dependent on the state of the mempool requires that you re= +cord the state of the mempool at the point at which the block snapshot was = +taken. +Otherwise, newly-started nodes can be fooled into taking the "wrong" consen= +sus branch leading to persistent chainsplits. + +> +> > Always avoid violating that principle in any consensus code. +> > If it is not committed to in the block and is not provable using only d= +ata you provide with the block, you cannot use it safely without risking ch= +ainsplit. +> > +> > (and no, banning or even disincentivizing SPV mining will not work, dif= +ferent nodes have different views of the mempool and temporary chainsplits = +can occur by chance where one chainsplit has transactions that are not conf= +irmed in the other chainsplit, which again is just another short-term inadv= +ertent Purge attack on the network.) +> > +> > > +> > > > Purge attacks can still be defended against and does not require ma= +ss cooperation. +> > > > If there is a transaction that is economically beneficial to me, it= + does so by paying some Bitcoins to me. +> > > > If it pays Bitcoins to me, I can spend those Bitcoins in a transact= +ion that just offers to pay mining fees and transfers it back to me (i.e. c= +hild pays for parent) to convince miners to mine the purged transaction. +> > > > As the Purge attack is "just" a censorship attack (i.e. a censorshi= +p of all transactions in the block under attack), the increased mining fees= + for the transactions being censored (i.e. offered via child-pays-for-paren= +t in this case) is an economic counterattack on the censoring miner (i.e. i= +t forgoes the mining fees). +> > > +> > > > With enough self-interested users, the fee offered to confirm the t= +ransactions can be substantial enough that non-censoring miners can be conv= +inced to mine those transactions. +> > > > No coordination necessary, as is typical for all defenses against c= +ensorship (and the basis of the censorship-resistance of Bitcoin). +> > > +> > > The attack itself is better classified as a form of sabotage than cen= +sorship. The goal is to demonstrate the ongoing mutability of transactions = +beyond any inherent heuristic for =E2=80=9Cfinality=E2=80=9D. iow it is a d= +emonstration that will damage the network=E2=80=99s future ability to offer= + settlement assurances. +> > > +> > > Trying to use Child Pays For Parent to defend in a bidding war agains= +t an opportunist attacker retrieving spent Bitcoin via RBF is a losing game= + for the defender. There=E2=80=99s no opportunity cost for the attacker, an= +y amount retrieved is profit. The defender, on the other hand, is always lo= +sing value. This is exactly the kind of conflict and discoordination the at= +tack is intended to induce. +> > +> > Your defender, in this attack, should avoid the Sunk Cost Fallacy here. +> > If the defender has been so foolish as to provide a product or service = +based on only a *few* confirmations, like 1 or 2, then that product or serv= +ice has been Sunk, and it should ignore the Sunk Cost here. +> > +> > From that point of view, the attacker and the defender are simply biddi= +ng up from the *same* value, i.e. the value of the UTXO that is being remov= +ed by the purge attack. +> > As the same value is under contest on both sides, they are equally matc= +hed and both censoring and non-censoring miners will get the same incentive= +, splitting up the network into two nearly equal halves, and then chance (l= +ucky block discovery) decides between which is the winner or the loser. +> > +> > The difference here is that the chainsplit in this case is in a metasta= +ble state, and once a string of lucky block discoveries occurs, it falls in= +to a stable state and now everybody agrees again on who won and who lost. +> > Your solution risks *persistent* *stable* chainsplits. +> > Worse, this occurrence without your solution would only happen if some = +miners actually attack the blockchain. +> > With your solution, persistent chainsplits can occur without malice, si= +mply chance. +> +> How would this mechanism produce a chainsplit by chance? + +I already described it in the previous post. + +Purge attacks happen all the time, when two miners mine blocks at nearly th= +e same time, but with different sets of transactions in their blocks. +And as I pointed out, any mechanism which uses non-block data (such as memp= +ool data) *will* lead to persistent chainsplits. + +> =C2=A0 +> +> > And as in many things in life, the only winning move is not to play. +> > Just wait for more than a small number of confirmations (e.g. 6 is gene= +rally considered safe), and the chance that a Purge attack on your transact= +ions succeeds is low enough that worse force majeur (a rogue asteroid hitti= +ng your datacenter, for example) is more likely. +> +> I got to thinking about "purge attacks" and mitigations because I was red= + teaming how G20 states that have seized the major mining operations could = +most effectively destroy value and confidence in Bitcoin. This scenario is = +_a lot_ more likely than=C2=A0rogue asteroids. +> +> What happens if the G20 decide to reorg deeper 6 - say 10, or even 20? +> +> If the Bitcoin continues to offer replace by fee I think this will be the= +ir first attack with seized majority hashrate; +> +> - mine offline +> - reach > 10 deep empty block reorg as heaviest chain=C2=A0 +> - announce it +> - semi-honest mine with a preference for RBF'ed "root" txns, ignoring any= + profitable child pays for parent. +> - repeat above, until some goal reached (eg. $ value of Bitcoin reaching = +x) +> - switch to "DoS mode" where you empty block reorg the chain tip +> +> If we got rid of RBF, their only option would be DoS mode. Once it stops,= + honest mining could resume and the blocks will fill back up again with tra= +nsactions out of the mempool preserved in the right order.# + +You ***cannot*** get rid of RBF. +The incentives of miners mean they will actually want to implement RBF and = +ignore any "convention" of RBF-flagging. +My understanding is that there are claims that a minority of miners already= + do this (possibly Peter Todd has more information, but I am uncertain), an= +d will accept "full" RBF i.e. ignore the RBF flag and always apply RBF to a= +ll transactions regardless. +Nothing in consensus prevents this, and this is why we always wait for conf= +irmation. + + +Regardless of however many blocks are attacked, always remember that in the= + end, this is still a *censorship* attack: it is attempting to censor Bitco= +in completely. +As such, this page applies: https://github.com/libbitcoin/libbitcoin-system= +/wiki/Censorship-Resistance-Property + + +Regards, +ZmnSCPxj + |