Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6D34EC013E for ; Sat, 8 Feb 2020 08:11:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 61AE986886 for ; Sat, 8 Feb 2020 08:11:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqGzCAgwC6Gc for ; Sat, 8 Feb 2020 08:11:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by fraxinus.osuosl.org (Postfix) with ESMTPS id DF20784589 for ; Sat, 8 Feb 2020 08:11:29 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id q15so1586983qki.2 for ; Sat, 08 Feb 2020 00:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EvxVLdG/iWKsDqJOLscvmChkNdJjMZ2srVwacbhJdWU=; b=cZl7TGno6iK9YH5fNqfLBpzTmEcub9ZiUVtfjthKiPS1AE4bT+WhMpLQd3/V7a8uFK Q/dSRfKS6EYDiQSK4zDMCkSkEAKVXj8u9HnBcjo8exgvEfcVHMUefInUhKpsw3nWsDIa dau96xU8ESV/PBpBxBFz1lv4AZgion4Yq7yTWIl2gvdQVaX+21Pt1EbQ0JIuAYjTrN5u 5KbyeTOrQAbt57UJd2Va1QA3K3SLsVh+rDWqTIB7p+Ww1scgFoSXzygNkVaCGD3erhkf pJRPLc3XWRYp+fX/15DQQ1O6EXQm/hHnnrRLuckru4rnUqjhZM3I65Z04Y4pKL9lNd5U YnpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EvxVLdG/iWKsDqJOLscvmChkNdJjMZ2srVwacbhJdWU=; b=jMj2uGZt3VRKx/8hgYAd9i4ZEbNQS9c/1MY7nuB2O0CV/G6Nb4CyCwq9h5LRz3fwMQ hIUouiCokJa555vTCL9SGISc4FxTENMnoOTn5wMnZzUUcvpB80cIQun8uZ94u4wvtmF2 2YlO6yldQeGTESm9z/WqY2EhZQ3BMSj8KgkCtiOP0OZq86Bb8wSqHDidv8ujqUIzgYFt JqxAzThBNTwWJYNn5oYaDWEZvOjVvLaAz8/17yx5SqgIqjHb4crlWrCblFlHwteD95Tl JO40LeppX+KXAMeMwuRogHFvPczJ+IXJiaCBgCFimyCzRD2FTBc5l0yk1BqcOtL6SNKs YG0g== X-Gm-Message-State: APjAAAW7+Mbk4VDLPFRL4sjVagx8g6I6jD/+NMmDLOqi5rAccF3sszRb up36qNZY/XcDvEYixzlSvWQcUaM7yUMk+ROvOFE= X-Google-Smtp-Source: APXvYqyFYH5l6nmhKSKALwjSsY+W40EHVvpelVSzJ/j31+lXr4PkGglvZtehHTH4z0qYWzfHmmruxQP43nph9UEzqbs= X-Received: by 2002:a37:a12:: with SMTP id 18mr2539759qkk.249.1581149488259; Sat, 08 Feb 2020 00:11:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mike Kelly Date: Sat, 8 Feb 2020 08:11:17 +0000 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000095a687059e0c0d7d" X-Mailman-Approved-At: Sat, 08 Feb 2020 14:44:40 +0000 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: Sat, 08 Feb 2020 08:11:31 -0000 --00000000000095a687059e0c0d7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj, thanks for your reply. Comments in line. On Sat, Feb 8, 2020 at 02:15, ZmnSCPxj wrote: > 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 suc= h > 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 > attested to in the blockchain. Yes, it intentionally violates that rule. It=E2=80=99s unclear to me right = now what the consequence/cost of doing so in this specific way would be. Are you able to explain? > > Purge attacks can still be defended against and does not require mass > 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 transaction > that just offers to pay mining fees and transfers it back to me (i.e. chi= ld > pays 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 fo= r > the transactions being censored (i.e. offered via child-pays-for-parent i= n > this case) is an economic counterattack on the censoring miner (i.e. it > forgoes the mining fees). > > With enough self-interested users, the fee offered to confirm the > transactions 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 > censorship (and the basis of the censorship-resistance of Bitcoin). The attack itself is better classified as a form of sabotage than censorship. 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 demonstration that will damage the network=E2=80=99s future ability to offe= r settlement assurances. Trying to use Child Pays For Parent to defend in a bidding war against 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, any amo= unt retrieved is profit. The defender, on the other hand, is always losing value. This is exactly the kind of conflict and discoordination the attack is intended to induce. Cheers, M > > 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] https://twitter.com/mikekelly85/status/1217590668735983622 > > [1] > https://medium.com/@mikekelly85/uncontested-safe-protocol-e5af8c145f1 > > > > Cheers, > > M > > > > On Sat, Feb 1, 2020 at 10:12 PM ha su via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > Hi all, > > > > > > I think I discovered an interesting form of sabotage attack (possible > for miners) that tries to create coordination disincentives among Bitcoin > users - named after the dystopian movie The Purge, where all crime is leg= al > for 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 wit= h > a minimum of technical knowledge or access to public tools can > opportunistically double-spend their txns back to themselves. (the proces= s > 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 > sabotage (e.g. DoS by mining only empty blocks) in that it specifically > disrupts the coordination process among users in response to the attack. > > > > > > By giving some users a chance to benefit from the attack, the attacke= r > gives them a vested interest in staying on the attack chain. If enough > users accept the invitation to double-spend, it might become harder to co= me > to consensus on how to deal with the attack. > > > > > > Purge attacks probably don=E2=80=99t constitute a bigger risk than ot= her 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 > attacks, at > https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-pu= rge-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 > --=20 Mike http://twitter.com/mikekelly85 http://linkedin.com/in/mikekelly123 --00000000000095a687059e0c0d7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj, thanks for your reply. Comments in line.
On Sat, = Feb 8, 2020 at 02:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
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 poo= l

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.

Yes, it intentionally violates that rule. It=E2=80=99s unclear to= me right now what the consequence/cost of doing so in this specific way wo= uld be. Are you able to explain?



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 censors= hip of all transactions in the block under attack), the increased mining fe= es for the transactions being censored (i.e. offered via child-pays-for-par= ent in this case) is an economic counterattack on the censoring miner (i.e.= it forgoes 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).

The attack itself is better class= ified as a form of sabotage than censorship. 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 demonstration that will damage the net= work=E2=80=99s future ability to offer settlement assurances.

Trying to use Child Pays For Parent t= o defend in a bidding war against an opportunist attacker retrieving spent = Bitcoin via RBF is a losing game for the defender. There=E2=80=99s no oppor= tunity cost for the attacker, any amount retrieved is profit. The defender,= on the other hand, is always losing value. This is exactly the kind of con= flict and discoordination the attack is intended to induce.

Cheers,
M



Regards,
ZmnSCPxj


> Since I raised this with Hasu in early Jan[0], I've been looking f= or ways to eliminate transaction replacement that are consensus compatible = (since first safe seen is not). The best I could come up with is "Unco= ntested Safe", which I've tried to sketch out in a brief medium ar= ticle[1].
>
> Am I retracing steps? Feedback would be appreciated.
>
> [0]=C2=A0https://twitter.com/mikekell= y85/status/1217590668735983622
> [1]=C2=A0https://medium.co= m/@mikekelly85/uncontested-safe-protocol-e5af8c145f1
>
> Cheers,
> M
>
> On Sat, Feb 1, 2020 at 10:12 PM ha su via bitcoin-dev <bitcoin-dev@= lists.linuxfoundation.org> wrote:
>
> > Hi all,
> >
> > I think I discovered an interesting form of sabotage attack (poss= ible for miners) that tries to create coordination disincentives among Bitc= oin users - named after the dystopian movie The Purge, where all crime is l= egal for one night every year.
> >
> > TLDR
> > * An attacker replaces the most recent blocks full of transaction= s with empty blocks.
> > * Previously confirmed txns return into the mempool, where anyone= with a minimum of technical knowledge or access to public tools can opport= unistically 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 assur= ances, e.g. the future finality of transactions. It differs from other form= s of sabotage (e.g. DoS by mining only empty blocks) in that it specificall= y disrupts the coordination=C2=A0process among users in response to the att= ack.=C2=A0
> >
> > By giving some users a chance to benefit from the attack, the att= acker gives them a vested interest in staying on the attack chain. If enoug= h users accept the invitation to double-spend, it might become harder to co= me to consensus on how to deal with the attack.
> >
> > Purge attacks probably don=E2=80=99t constitute a bigger risk tha= n other known forms of sabotage attacks, but seem like an interesting spin = where the attacker specifically targets the pre-coordination of defenders.<= br> > >
> > You can find the full report, incl. some mitigations against sabo= tage attacks, at=C2=A0https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-wi= th-purge-attacks/
> >
> > Your feedback is highly appreciated.
> >
> > Regards,
> > Hasu
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
>
> --
> Mike
>
> http://twitter.com/mikekelly85
> http://linkedin.com/in/mikekelly123
--
--00000000000095a687059e0c0d7d--