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

[Mike Kelly <mikekelly321@gmail.com>]

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

Hi ZmnSCPxj, thanks for your reply. Comments in line.

On Sat, Feb 8, 2020 at 02:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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
>
-- 
Mike

http://twitter.com/mikekelly85
http://linkedin.com/in/mikekelly123

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