public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Kelly <mikekelly321@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
Date: Fri, 7 Feb 2020 13:55:29 +0000	[thread overview]
Message-ID: <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com> (raw)
In-Reply-To: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3682 bytes --]

  reply	other threads:[~2020-02-07 13:55 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 [this message]
2020-02-08  2:15   ` ZmnSCPxj
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=CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com \
    --to=mikekelly321@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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