* [bitcoin-dev] Purge attacks (spin on sabotage attacks)
@ 2020-01-31 13:38 ha su
2020-02-07 13:55 ` Mike Kelly
0 siblings, 1 reply; 8+ messages in thread
From: ha su @ 2020-01-31 13:38 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1790 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-01-31 13:38 [bitcoin-dev] Purge attacks (spin on sabotage attacks) ha su
@ 2020-02-07 13:55 ` Mike Kelly
2020-02-08 2:15 ` ZmnSCPxj
0 siblings, 1 reply; 8+ messages in thread
From: Mike Kelly @ 2020-02-07 13:55 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-07 13:55 ` Mike Kelly
@ 2020-02-08 2:15 ` ZmnSCPxj
2020-02-08 8:11 ` Mike Kelly
0 siblings, 1 reply; 8+ messages in thread
From: ZmnSCPxj @ 2020-02-08 2:15 UTC (permalink / raw)
To: Mike Kelly, Bitcoin Protocol Discussion
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@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-08 2:15 ` ZmnSCPxj
@ 2020-02-08 8:11 ` Mike Kelly
2020-02-09 0:00 ` ZmnSCPxj
0 siblings, 1 reply; 8+ messages in thread
From: Mike Kelly @ 2020-02-08 8:11 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-08 8:11 ` Mike Kelly
@ 2020-02-09 0:00 ` ZmnSCPxj
2020-02-09 10:15 ` Mike Kelly
0 siblings, 1 reply; 8+ messages in thread
From: ZmnSCPxj @ 2020-02-09 0:00 UTC (permalink / raw)
To: Mike Kelly; +Cc: Bitcoin Protocol Discussion
Good morning M,
> > > 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?
Violation of this principle can cause persistent chainsplits where you induce one set of nodes to see one view of reality while another set of nodes see another view.
For instance, suppose two innocent miners happen to find blocks at nearly the same time.
Unfortunately for them, one miner happened to be using "SPV" mining i.e. mining empty blocks.
From the point of view of arbitrary nodes, this is indistinguishable from a one-block purge attack as described.
Yet this happenstance occurrence now causes a chainsplit, as some number of nodes (those near to the SPV-mining miner) think that miner is innocent of wrongdoing and will support the "purged" chainsplit, whereas those near the other miner will consider that block bad and will support the other "unpurged" chainsplit.
This is an even worse consequence than any purge attack, and could happen completely by chance with no malice involved.
Always avoid violating that principle in any consensus code.
If it is not committed to in the block and is not provable using only data you provide with the block, you cannot use it safely without risking chainsplit.
(and no, banning or even disincentivizing SPV mining will not work, different nodes have different views of the mempool and temporary chainsplits can occur by chance where one chainsplit has transactions that are not confirmed in the other chainsplit, which again is just another short-term inadvertent Purge attack on the network.)
>
> > 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.
Your defender, in this attack, should avoid the Sunk Cost Fallacy here.
If the defender has been so foolish as to provide a product or service based on only a *few* confirmations, like 1 or 2, then that product or service has been Sunk, and it should ignore the Sunk Cost here.
From that point of view, the attacker and the defender are simply bidding up from the *same* value, i.e. the value of the UTXO that is being removed by the purge attack.
As the same value is under contest on both sides, they are equally matched and both censoring and non-censoring miners will get the same incentive, splitting up the network into two nearly equal halves, and then chance (lucky block discovery) decides between which is the winner or the loser.
The difference here is that the chainsplit in this case is in a metastable state, and once a string of lucky block discoveries occurs, it falls into a stable state and now everybody agrees again on who won and who lost.
Your solution risks *persistent* *stable* chainsplits.
Worse, this occurrence without your solution would only happen if some miners actually attack the blockchain.
With your solution, persistent chainsplits can occur without malice, simply chance.
And as in many things in life, the only winning move is not to play.
Just wait for more than a small number of confirmations (e.g. 6 is generally considered safe), and the chance that a Purge attack on your transactions succeeds is low enough that worse force majeur (a rogue asteroid hitting your datacenter, for example) is more likely.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-09 0:00 ` ZmnSCPxj
@ 2020-02-09 10:15 ` Mike Kelly
2020-02-09 23:59 ` ZmnSCPxj
0 siblings, 1 reply; 8+ messages in thread
From: Mike Kelly @ 2020-02-09 10:15 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7477 bytes --]
Hi ZmnSCPxj,
On Sun, Feb 9, 2020 at 12:00 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning M,
>
> > > > 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?
>
> Violation of this principle can cause persistent chainsplits where you
> induce one set of nodes to see one view of reality while another set of
> nodes see another view.
> For instance, suppose two innocent miners happen to find blocks at nearly
> the same time.
> Unfortunately for them, one miner happened to be using "SPV" mining i.e.
> mining empty blocks.
>
> From the point of view of arbitrary nodes, this is indistinguishable from
> a one-block purge attack as described.
> Yet this happenstance occurrence now causes a chainsplit, as some number
> of nodes (those near to the SPV-mining miner) think that miner is innocent
> of wrongdoing and will support the "purged" chainsplit, whereas those near
> the other miner will consider that block bad and will support the other
> "unpurged" chainsplit.
> This is an even worse consequence than any purge attack, and could happen
> completely by chance with no malice involved.
>
>
I don't see how the scenario you outline here has anything to do with the
mechanism I proposed. An empty block doesn't contain any transactions (by
definition) so it wont contest any transactions in any given node's
mempool. The aim isn't to prevent empty nodes, it's to discourage miners
from including transactions in their block that conflict with the
eventually-consistent state of consensus in the mempool.
> Always avoid violating that principle in any consensus code.
> If it is not committed to in the block and is not provable using only data
> you provide with the block, you cannot use it safely without risking
> chainsplit.
>
> (and no, banning or even disincentivizing SPV mining will not work,
> different nodes have different views of the mempool and temporary
> chainsplits can occur by chance where one chainsplit has transactions that
> are not confirmed in the other chainsplit, which again is just another
> short-term inadvertent Purge attack on the network.)
>
>
> >
> > > 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.
>
> Your defender, in this attack, should avoid the Sunk Cost Fallacy here.
> If the defender has been so foolish as to provide a product or service
> based on only a *few* confirmations, like 1 or 2, then that product or
> service has been Sunk, and it should ignore the Sunk Cost here.
>
> From that point of view, the attacker and the defender are simply bidding
> up from the *same* value, i.e. the value of the UTXO that is being removed
> by the purge attack.
> As the same value is under contest on both sides, they are equally matched
> and both censoring and non-censoring miners will get the same incentive,
> splitting up the network into two nearly equal halves, and then chance
> (lucky block discovery) decides between which is the winner or the loser.
>
> The difference here is that the chainsplit in this case is in a metastable
> state, and once a string of lucky block discoveries occurs, it falls into a
> stable state and now everybody agrees again on who won and who lost.
> Your solution risks *persistent* *stable* chainsplits.
> Worse, this occurrence without your solution would only happen if some
> miners actually attack the blockchain.
> With your solution, persistent chainsplits can occur without malice,
> simply chance.
>
How would this mechanism produce a chainsplit by chance?
>
> And as in many things in life, the only winning move is not to play.
> Just wait for more than a small number of confirmations (e.g. 6 is
> generally considered safe), and the chance that a Purge attack on your
> transactions succeeds is low enough that worse force majeur (a rogue
> asteroid hitting your datacenter, for example) is more likely.
>
>
I got to thinking about "purge attacks" and mitigations because I was red
teaming how G20 states that have seized the major mining operations could
most effectively destroy value and confidence in Bitcoin. This scenario is
_a lot_ more likely than rogue asteroids.
What happens if the G20 decide to reorg deeper 6 - say 10, or even 20?
If the Bitcoin continues to offer replace by fee I think this will be their
first attack with seized majority hashrate;
- mine offline
- reach > 10 deep empty block reorg as heaviest chain
- announce it
- semi-honest mine with a preference for RBF'ed "root" txns, ignoring any
profitable child pays for parent.
- repeat above, until some goal reached (eg. $ value of Bitcoin reaching x)
- switch to "DoS mode" where you empty block reorg the chain tip
If we got rid of RBF, their only option would be DoS mode. Once it stops,
honest mining could resume and the blocks will fill back up again with
transactions out of the mempool preserved in the right order.#
Hope that makes sense.
Best,
Mike
[-- Attachment #2: Type: text/html, Size: 8540 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-09 10:15 ` Mike Kelly
@ 2020-02-09 23:59 ` ZmnSCPxj
2020-02-10 15:28 ` Mike Kelly
0 siblings, 1 reply; 8+ messages in thread
From: ZmnSCPxj @ 2020-02-09 23:59 UTC (permalink / raw)
To: Mike Kelly; +Cc: Bitcoin Protocol Discussion
Good morning M,
> I don't see how the scenario you outline here has anything to do with the mechanism I proposed. An empty block doesn't contain any transactions (by definition) so it wont contest any transactions in any given node's mempool. The aim isn't to prevent empty nodes, it's to discourage miners from including transactions in their block that conflict with the eventually-consistent state of consensus in the mempool.
>
What?
From the original post:
> TLDR
> * An attacker replaces the most recent blocks full of transactions with empty blocks.
Are you sure you are solving the same problem?
The mempool **has no consensus**.
It is strictly an optimization, preventing a node from needlessly broadcasting transactions.
Making consensus dependent on the state of the mempool requires that you record the state of the mempool at the point at which the block snapshot was taken.
Otherwise, newly-started nodes can be fooled into taking the "wrong" consensus branch leading to persistent chainsplits.
>
> > Always avoid violating that principle in any consensus code.
> > If it is not committed to in the block and is not provable using only data you provide with the block, you cannot use it safely without risking chainsplit.
> >
> > (and no, banning or even disincentivizing SPV mining will not work, different nodes have different views of the mempool and temporary chainsplits can occur by chance where one chainsplit has transactions that are not confirmed in the other chainsplit, which again is just another short-term inadvertent Purge attack on the network.)
> >
> > >
> > > > 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.
> >
> > Your defender, in this attack, should avoid the Sunk Cost Fallacy here.
> > If the defender has been so foolish as to provide a product or service based on only a *few* confirmations, like 1 or 2, then that product or service has been Sunk, and it should ignore the Sunk Cost here.
> >
> > From that point of view, the attacker and the defender are simply bidding up from the *same* value, i.e. the value of the UTXO that is being removed by the purge attack.
> > As the same value is under contest on both sides, they are equally matched and both censoring and non-censoring miners will get the same incentive, splitting up the network into two nearly equal halves, and then chance (lucky block discovery) decides between which is the winner or the loser.
> >
> > The difference here is that the chainsplit in this case is in a metastable state, and once a string of lucky block discoveries occurs, it falls into a stable state and now everybody agrees again on who won and who lost.
> > Your solution risks *persistent* *stable* chainsplits.
> > Worse, this occurrence without your solution would only happen if some miners actually attack the blockchain.
> > With your solution, persistent chainsplits can occur without malice, simply chance.
>
> How would this mechanism produce a chainsplit by chance?
I already described it in the previous post.
Purge attacks happen all the time, when two miners mine blocks at nearly the same time, but with different sets of transactions in their blocks.
And as I pointed out, any mechanism which uses non-block data (such as mempool data) *will* lead to persistent chainsplits.
>
>
> > And as in many things in life, the only winning move is not to play.
> > Just wait for more than a small number of confirmations (e.g. 6 is generally considered safe), and the chance that a Purge attack on your transactions succeeds is low enough that worse force majeur (a rogue asteroid hitting your datacenter, for example) is more likely.
>
> I got to thinking about "purge attacks" and mitigations because I was red teaming how G20 states that have seized the major mining operations could most effectively destroy value and confidence in Bitcoin. This scenario is _a lot_ more likely than rogue asteroids.
>
> What happens if the G20 decide to reorg deeper 6 - say 10, or even 20?
>
> If the Bitcoin continues to offer replace by fee I think this will be their first attack with seized majority hashrate;
>
> - mine offline
> - reach > 10 deep empty block reorg as heaviest chain
> - announce it
> - semi-honest mine with a preference for RBF'ed "root" txns, ignoring any profitable child pays for parent.
> - repeat above, until some goal reached (eg. $ value of Bitcoin reaching x)
> - switch to "DoS mode" where you empty block reorg the chain tip
>
> If we got rid of RBF, their only option would be DoS mode. Once it stops, honest mining could resume and the blocks will fill back up again with transactions out of the mempool preserved in the right order.#
You ***cannot*** get rid of RBF.
The incentives of miners mean they will actually want to implement RBF and ignore any "convention" of RBF-flagging.
My understanding is that there are claims that a minority of miners already do this (possibly Peter Todd has more information, but I am uncertain), and will accept "full" RBF i.e. ignore the RBF flag and always apply RBF to all transactions regardless.
Nothing in consensus prevents this, and this is why we always wait for confirmation.
Regardless of however many blocks are attacked, always remember that in the end, this is still a *censorship* attack: it is attempting to censor Bitcoin completely.
As such, this page applies: https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
2020-02-09 23:59 ` ZmnSCPxj
@ 2020-02-10 15:28 ` Mike Kelly
0 siblings, 0 replies; 8+ messages in thread
From: Mike Kelly @ 2020-02-10 15:28 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9484 bytes --]
Hi ZmnSCPxj, thanks for sticking with me on this.
On Mon, Feb 10, 2020 at 12:00 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning M,
>
>
> > I don't see how the scenario you outline here has anything to do with
> the mechanism I proposed. An empty block doesn't contain any transactions
> (by definition) so it wont contest any transactions in any given node's
> mempool. The aim isn't to prevent empty nodes, it's to discourage miners
> from including transactions in their block that conflict with the
> eventually-consistent state of consensus in the mempool.
> >
>
> What?
>
> From the original post:
>
> > TLDR
> > * An attacker replaces the most recent blocks full of transactions with
> empty blocks.
>
> Are you sure you are solving the same problem?
>
Yes.
There is no way to prevent someone with the majority of hash rate doing
empty block reorgs. This is not new and it's not the problem/point of a
purge attack. The point of a purge attack is that _under the conditions of
an empty block reorg_ if the network affords transaction replacement (ie.
RBF) then users with who instructed transactions which are now un-confirmed
and back in the mempool have the opportunity to double spend them by
replacing the transaction that was considered finalised. We can prevent
this scenario by eliminating transaction replacement in the network.
>
> The mempool **has no consensus**.
> It is strictly an optimization, preventing a node from needlessly
> broadcasting transactions.
>
> Making consensus dependent on the state of the mempool requires that you
> record the state of the mempool at the point at which the block snapshot
> was taken.
> Otherwise, newly-started nodes can be fooled into taking the "wrong"
> consensus branch leading to persistent chainsplits.
>
No need to record the state of the mempool. Newly-started nodes should
select the heaviest chain as per usual.
>
> >
> > > Always avoid violating that principle in any consensus code.
> > > If it is not committed to in the block and is not provable using only
> data you provide with the block, you cannot use it safely without risking
> chainsplit.
> > >
> > > (and no, banning or even disincentivizing SPV mining will not work,
> different nodes have different views of the mempool and temporary
> chainsplits can occur by chance where one chainsplit has transactions that
> are not confirmed in the other chainsplit, which again is just another
> short-term inadvertent Purge attack on the network.)
> > >
> > > >
> > > > > 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.
> > >
> > > Your defender, in this attack, should avoid the Sunk Cost Fallacy here.
> > > If the defender has been so foolish as to provide a product or service
> based on only a *few* confirmations, like 1 or 2, then that product or
> service has been Sunk, and it should ignore the Sunk Cost here.
> > >
> > > From that point of view, the attacker and the defender are simply
> bidding up from the *same* value, i.e. the value of the UTXO that is being
> removed by the purge attack.
> > > As the same value is under contest on both sides, they are equally
> matched and both censoring and non-censoring miners will get the same
> incentive, splitting up the network into two nearly equal halves, and then
> chance (lucky block discovery) decides between which is the winner or the
> loser.
> > >
> > > The difference here is that the chainsplit in this case is in a
> metastable state, and once a string of lucky block discoveries occurs, it
> falls into a stable state and now everybody agrees again on who won and who
> lost.
> > > Your solution risks *persistent* *stable* chainsplits.
> > > Worse, this occurrence without your solution would only happen if some
> miners actually attack the blockchain.
> > > With your solution, persistent chainsplits can occur without malice,
> simply chance.
> >
> > How would this mechanism produce a chainsplit by chance?
>
> I already described it in the previous post.
>
> Purge attacks happen all the time, when two miners mine blocks at nearly
> the same time, but with different sets of transactions in their blocks.
> And as I pointed out, any mechanism which uses non-block data (such as
> mempool data) *will* lead to persistent chainsplits.
>
> >
> >
> > > And as in many things in life, the only winning move is not to play.
> > > Just wait for more than a small number of confirmations (e.g. 6 is
> generally considered safe), and the chance that a Purge attack on your
> transactions succeeds is low enough that worse force majeur (a rogue
> asteroid hitting your datacenter, for example) is more likely.
> >
> > I got to thinking about "purge attacks" and mitigations because I was
> red teaming how G20 states that have seized the major mining operations
> could most effectively destroy value and confidence in Bitcoin. This
> scenario is _a lot_ more likely than rogue asteroids.
> >
> > What happens if the G20 decide to reorg deeper 6 - say 10, or even 20?
> >
> > If the Bitcoin continues to offer replace by fee I think this will be
> their first attack with seized majority hashrate;
> >
> > - mine offline
> > - reach > 10 deep empty block reorg as heaviest chain
> > - announce it
> > - semi-honest mine with a preference for RBF'ed "root" txns, ignoring
> any profitable child pays for parent.
> > - repeat above, until some goal reached (eg. $ value of Bitcoin reaching
> x)
> > - switch to "DoS mode" where you empty block reorg the chain tip
> >
> > If we got rid of RBF, their only option would be DoS mode. Once it
> stops, honest mining could resume and the blocks will fill back up again
> with transactions out of the mempool preserved in the right order.#
>
> You ***cannot*** get rid of RBF.
>
What is the evidence for this claim? Is there a proof?
> The incentives of miners mean they will actually want to implement RBF and
> ignore any "convention" of RBF-flagging.
>
Yes, under the current design. This is an attempt to change the incentives
of the protocol so that this is not the case. To try and reduce the
severity of empty block reorg attacks.
> My understanding is that there are claims that a minority of miners
> already do this (possibly Peter Todd has more information, but I am
> uncertain), and will accept "full" RBF i.e. ignore the RBF flag and always
> apply RBF to all transactions regardless.
> Nothing in consensus prevents this, and this is why we always wait for
> confirmation.
>
>
The whole point of this sabotage attack is that it demonstrates that
confirmation is not a reasonable way of managing this risk. If the depth of
the empty block reorg was 20, even if everyone stuck to the arbitrary 6
confirmation rule, nearly every Bitcoin transaction from the 14 blocks
between `chaintip-6` and `chaintip-20` is at risk of being double spent as
it lands back in the mempool.
>
> Regardless of however many blocks are attacked, always remember that in
> the end, this is still a *censorship* attack: it is attempting to censor
> Bitcoin completely.
> As such, this page applies:
> https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property
Censorship of availability of the network? That's DoS ie. what a standard
empty reorg attack.
Purge attack is an extension of this that extends such an into the realm of
sabotage, where the integrity of previously-adequately-confirmed
transactions is compromised by allowing users to double spend them.
Cheers,
M
[-- Attachment #2: Type: text/html, Size: 11288 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-10 15:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-31 13:38 [bitcoin-dev] Purge attacks (spin on sabotage attacks) ha su
2020-02-07 13:55 ` Mike Kelly
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox