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.
Yes, it intentionally violates that rule. It’s 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. 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).
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 “finality”. iow it is a demonstration that will damage the network’s future ability to offer 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’s no opportunity 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 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 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