public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Mike Kelly <mikekelly321@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
Date: Sat, 08 Feb 2020 02:15:32 +0000	[thread overview]
Message-ID: <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com> (raw)
In-Reply-To: <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>

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 attested 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 confirmations) then this does not protect against purge attacks.

--

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. child 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 for the transactions being censored (i.e. offered via child-pays-for-parent 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 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).

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 legal 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 with a minimum of technical knowledge or access to public tools can opportunistically 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 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 attacker 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 come to consensus on how to deal with the attack.
> >
> > Purge attacks probably don’t constitute a bigger risk than other 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-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


  reply	other threads:[~2020-02-08  2:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 13:38 [bitcoin-dev] Purge attacks (spin on sabotage attacks) ha su
2020-02-07 13:55 ` Mike Kelly
2020-02-08  2:15   ` ZmnSCPxj [this message]
2020-02-08  8:11     ` Mike Kelly
2020-02-09  0:00       ` ZmnSCPxj
2020-02-09 10:15         ` Mike Kelly
2020-02-09 23:59           ` ZmnSCPxj
2020-02-10 15:28             ` Mike Kelly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mikekelly321@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox