Date: Sat, 08 Feb 2020 02:15:32 +0000
To: Mike Kelly <mikekelly321@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
In-Reply-To: <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
 <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
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)
Precedence: list

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 <bitcoin-dev@lists.=
linuxfoundation.org> 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