Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A7CB3C0171 for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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