From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 53ABAC013E for ; Sat, 8 Feb 2020 02:15:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 4EC6820411 for ; Sat, 8 Feb 2020 02:15:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBYH3d+u-av3 for ; Sat, 8 Feb 2020 02:15:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by silver.osuosl.org (Postfix) with ESMTPS id DC9522040D for ; Sat, 8 Feb 2020 02:15:36 +0000 (UTC) Date: Sat, 08 Feb 2020 02:15:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581128133; bh=EcL0QvXXixtsd02/7UfHELRljrDIOHwYGH1Yxht9gwA=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=EmvoV9wOpXMjU4cnKzhEqp0q0No986wIOB+jTBqJtewB097RkhwDRgyYOuhjm57p4 DB31ftVbqKBBWXISV7y44gzkVcyukSLOiM+F7O18leUipO0sGbG4oiy0Hb/xh08kIR 8uOwb+Ab4Lb4VIfhnCSmA3X7eZSJPRMEUJZRqwro= To: Mike Kelly , Bitcoin Protocol Discussion 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 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: Sat, 08 Feb 2020 02:15:39 -0000 Good morning M, What do you mean by this? > Nodes reject announced blocks that: > > * include transactions that are in contest with any in their mempool > * include transactions that are in contest with any in the contest pool Is this intended to be a consensus rule, i.e. nodes will never accept such = a block? Because if so, this fails the principle of Blockchain Self-Containment, i.e= . consensus rules can only check what is in the blockchain. The mempool (and contest pool) is not in the blockchain as it is never atte= sted to in the blockchain. If this is not a consensus rule (i.e.e nodes can be convinced to accept an = announced block that violates the above via some rule, such as sufficient c= onfirmations) then this does not protect against purge attacks. -- Purge attacks can still be defended against and does not require mass coope= ration. 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 transaction that= just offers to pay mining fees and transfers it back to me (i.e. child pay= s for parent) to convince miners to mine the purged transaction. As the Purge attack is "just" a censorship attack (i.e. a censorship of all= transactions in the block under attack), the increased mining fees for the= transactions being censored (i.e. offered via child-pays-for-parent in thi= s case) is an economic counterattack on the censoring miner (i.e. it forgoe= s the mining fees). With enough self-interested users, the fee offered to confirm the transacti= ons can be substantial enough that non-censoring miners can be convinced to= mine those transactions. No coordination necessary, as is typical for all defenses against censorshi= p (and the basis of the censorship-resistance of Bitcoin). Regards, ZmnSCPxj > Since I raised this with Hasu in early Jan[0], I've been looking for ways= to eliminate transaction replacement that are consensus compatible (since = first safe seen is not). The best I could come up with is "Uncontested Safe= ", which I've tried to sketch out in a brief medium article[1]. > > Am I retracing steps? Feedback would be appreciated. > > [0]=C2=A0https://twitter.com/mikekelly85/status/1217590668735983622 > [1]=C2=A0https://medium.com/@mikekelly85/uncontested-safe-protocol-e5af8c= 145f1 > > Cheers, > M > > On Sat, Feb 1, 2020 at 10:12 PM ha su via bitcoin-dev wrote: > > > Hi all, > > > > I think I discovered an interesting form of sabotage attack (possible f= or miners) that tries to create coordination disincentives among Bitcoin us= ers - named after the dystopian movie The Purge, where all crime is legal f= or one night every year. > > > > TLDR > > * An attacker replaces the most recent blocks full of transactions with= empty blocks. > > * Previously confirmed txns return into the mempool, where anyone with = a minimum of technical knowledge or access to public tools can opportunisti= cally double-spend their txns back to themselves. (the process is the same = as double-spending regular zero-conf txns) > > > > The attack seems useful to undermine trust in Bitcoin's assurances, e.g= . the future finality of transactions. It differs from other forms of sabot= age (e.g. DoS by mining only empty blocks) in that it specifically disrupts= the coordination=C2=A0process among users in response to the attack.=C2= =A0 > > > > By giving some users a chance to benefit from the attack, the attacker = gives them a vested interest in staying on the attack chain. If enough user= s accept the invitation to double-spend, it might become harder to come to = consensus on how to deal with the attack. > > > > Purge attacks probably don=E2=80=99t constitute a bigger risk than othe= r known forms of sabotage attacks, but seem like an interesting spin where = the attacker specifically targets the pre-coordination of defenders. > > > > You can find the full report, incl. some mitigations against sabotage a= ttacks, at=C2=A0https://blog.deribit.com/insights/destabilizing-bitcoin-con= sensus-with-purge-attacks/ > > > > Your feedback is highly appreciated. > > > > Regards, > > Hasu > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- > Mike > > http://twitter.com/mikekelly85 > http://linkedin.com/in/mikekelly123