[bitcoin-dev] Purge attacks (spin on sabotage attacks)

[ZmnSCPxj]

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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Mike
>
> http://twitter.com/mikekelly85
> http://linkedin.com/in/mikekelly123