path: root/aa/69acfdbad0aa69eea0315f2f82afecc09d94c1

Return-Path: <mikekelly321@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9CCEBC0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 15:28:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 8799F847D1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 15:28:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id X-kgTuiCALs2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 15:28:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com
 [209.85.222.193])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id E5D5684547
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 15:28:32 +0000 (UTC)
Received: by mail-qk1-f193.google.com with SMTP id z19so3826087qkj.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 07:28:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=0g/Zv6UMVo4E7n2YDpVQ3/3P2xE2/HT/3zLeLOapgms=;
 b=a0QMOS2tpexxhX0mG6Gem/yjS2cvLhBKpeadlqUwdx1Hl1SwR/0xcXUeg/PK0d6uqo
 HPbDRb3yNA3kLM+zIExf77yeshHMlgagn/5CRwRxLZIBwRKSEfrzc4L4cSY4I+hm7DWj
 ht5gAlNQgYySojHl0y2g2c85gaHKxuYIoob16iPS0ksFu7uGx12RyYfqEjRcxmRQktsO
 b3YQDAB5WnF9Mik6fN9iCakJ7S2edQlhZN8+z8do3L1gSG8RZG9zPUSpyz9V1qd5HM3S
 +UecgPY9O0Zt2GFss2/QD6uQNHBWukr01yyn+oyMJVFccwTKg/z/igQ+L+YH6imZ1+gX
 zp7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=0g/Zv6UMVo4E7n2YDpVQ3/3P2xE2/HT/3zLeLOapgms=;
 b=uehBjvbZowOTmKjZrePNVQCM6kOFfE9HmAe2QhCU1MXY1m+ZKUCIjScFmQr4+O3R7t
 wLXCRS3pnISQuQjhimuNi5KAtsj42XR0sFil4xypmDG2rESV/GSVBkGQhixoBrrghdSg
 RB/wJTZ5wzEUy5eunhArZcC/PsybNwrp1Ah2LYiBnKcaSaNrvE3H6fLKs3lBdVKmGV8P
 62ENeu+CTr3UTmzk/+eKL3vdlcpdScdIdyNyDcelxThLR20VGRykMcdHf0lWx2q12xC/
 HXDMG2Ep3BuFMg5rtwaPyIfXbHKrzn64GaT0i1ojGteIqM33DNPJ7/b3vGMqZf9z+x8Q
 j+xA==
X-Gm-Message-State: APjAAAWKhYKholoTcbLgpTqGw56KbZgBbb5GMdpDiYw7pVbSYqUCylWl
 6BW7gBjs1IZLjpHNH0c7Ii9nGPmYYNDeYfuynYs=
X-Google-Smtp-Source: APXvYqy352x9L1i4ZgEwOyQViHgRDJ6CkcbXqbMi1OF92p8ksVSqF4GluuUMLK0E4QPq2sjFUYAQDreRxDivmKeCNPM=
X-Received: by 2002:ae9:f303:: with SMTP id p3mr1832786qkg.344.1581348511788; 
 Mon, 10 Feb 2020 07:28:31 -0800 (PST)
MIME-Version: 1.0
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
 <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
 <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
 <CANqiZJapjRvf5p=yD2BGqYxn_zR8HBHgU=ncKDROZbWersZxBg@mail.gmail.com>
 <u0lEEiLwMX1seNC4Wz7nfizIB2zaj4HfINI9rnh0ZBPJkW02uMw-6HCWemKpz5xr8MYxkTQWpCa4ucnM5Qj82qBlgW5BnlUBd5Pv2f_Ho6A=@protonmail.com>
 <CANqiZJYvtmuoDh7eqH+2xYTqC=hxMEBV-+9rD4w30yC7v4o31Q@mail.gmail.com>
 <MQqr0u8z7KvEmdMtR7wez_tcwJIaKbfcBSJkv4DrVeg_NlgiX9R-ILWlvb596VLEh74NrIMC1l0Wh0XOz1pcnywMjAtJ_m60LezEU9rrU5E=@protonmail.com>
In-Reply-To: <MQqr0u8z7KvEmdMtR7wez_tcwJIaKbfcBSJkv4DrVeg_NlgiX9R-ILWlvb596VLEh74NrIMC1l0Wh0XOz1pcnywMjAtJ_m60LezEU9rrU5E=@protonmail.com>
From: Mike Kelly <mikekelly321@gmail.com>
Date: Mon, 10 Feb 2020 15:28:20 +0000
Message-ID: <CANqiZJaurc6xUcq4Rg=J26xeQFt7Kn=SexgXWwDJ_U3OoCPGNQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000004fb14b059e3a64a7"
X-Mailman-Approved-At: Mon, 10 Feb 2020 15:30:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 15:28:34 -0000

--0000000000004fb14b059e3a64a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 tha=
t
> 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 =E2=80=9Cfinality=E2=80=9D=
. iow it is a
> demonstration that will damage the network=E2=80=99s future ability to of=
fer
> 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=E2=80=99s no opportunity cost for the=
 attacker,
> any amount retrieved is profit. The defender, on the other hand, is alway=
s
> losing value. This is exactly the kind of conflict and discoordination th=
e
> attack is intended to induce.
> > >
> > > Your defender, in this attack, should avoid the Sunk Cost Fallacy her=
e.
> > > If the defender has been so foolish as to provide a product or servic=
e
> 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 bein=
g
> 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 the=
n
> 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 w=
ho
> lost.
> > > Your solution risks *persistent* *stable* chainsplits.
> > > Worse, this occurrence without your solution would only happen if som=
e
> 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 reachin=
g
> 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 an=
d
> 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 alway=
s
> 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-Resistanc=
e-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

--0000000000004fb14b059e3a64a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi=C2=A0ZmnSCPxj, thanks for sticking with=C2=A0me on=
 this.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Mon, Feb 10, 2020 at 12:00 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSC=
Pxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Good morning M,<br>
<br>
<br>
&gt; I don&#39;t see how the scenario you outline here has anything to do w=
ith the mechanism I proposed. An empty block doesn&#39;t contain any transa=
ctions (by definition) so it wont contest any transactions in any given nod=
e&#39;s mempool. The aim isn&#39;t to prevent empty nodes, it&#39;s to disc=
ourage miners from including transactions in their block that conflict with=
 the eventually-consistent state of consensus in the mempool.<br>
&gt; =C2=A0<br>
<br>
What?<br>
<br>
From the original post:<br>
<br>
&gt; TLDR<br>
&gt; * An attacker replaces the most recent blocks full of transactions wit=
h empty blocks.<br>
<br>
Are you sure you are solving the same problem?<br></blockquote><div><br></d=
iv><div>Yes. </div><div><br></div><div>There is no way to prevent someone w=
ith the majority of hash rate doing empty block reorgs. This is not new and=
 it&#39;s not the problem/point of a purge attack. The point of a purge att=
ack is that _under the conditions of an empty block reorg_ if the network a=
ffords transaction replacement (ie. RBF) then users with who instructed tra=
nsactions which are now un-confirmed and back in the mempool have the oppor=
tunity to double spend them by replacing the transaction that was considere=
d finalised. We can prevent this scenario by eliminating transaction replac=
ement in the network.</div><div></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<br>
The mempool **has no consensus**.<br>
It is strictly an optimization, preventing a node from needlessly broadcast=
ing transactions.<br>
<br>
Making consensus dependent on the state of the mempool requires that you re=
cord the state of the mempool at the point at which the block snapshot was =
taken.<br>
Otherwise, newly-started nodes can be fooled into taking the &quot;wrong&qu=
ot; consensus branch leading to persistent chainsplits.<br></blockquote><di=
v><br></div><div>No need to record the state of the mempool. Newly-started =
nodes should select the heaviest chain as per usual.=C2=A0</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;<br>
&gt; &gt; Always avoid violating that principle in any consensus code.<br>
&gt; &gt; 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 risk=
ing chainsplit.<br>
&gt; &gt;<br>
&gt; &gt; (and no, banning or even disincentivizing SPV mining will not wor=
k, different nodes have different views of the mempool and temporary chains=
plits can occur by chance where one chainsplit has transactions that are no=
t confirmed in the other chainsplit, which again is just another short-term=
 inadvertent Purge attack on the network.)<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Purge attacks can still be defended against and does no=
t require mass cooperation.<br>
&gt; &gt; &gt; &gt; If there is a transaction that is economically benefici=
al to me, it does so by paying some Bitcoins to me.<br>
&gt; &gt; &gt; &gt; If it pays Bitcoins to me, I can spend those Bitcoins i=
n a transaction that just offers to pay mining fees and transfers it back t=
o me (i.e. child pays for parent) to convince miners to mine the purged tra=
nsaction.<br>
&gt; &gt; &gt; &gt; As the Purge attack is &quot;just&quot; a censorship at=
tack (i.e. a censorship of all transactions in the block under attack), the=
 increased mining fees for the transactions being censored (i.e. offered vi=
a child-pays-for-parent in this case) is an economic counterattack on the c=
ensoring miner (i.e. it forgoes the mining fees).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; With enough self-interested users, the fee offered to c=
onfirm the transactions can be substantial enough that non-censoring miners=
 can be convinced to mine those transactions.<br>
&gt; &gt; &gt; &gt; No coordination necessary, as is typical for all defens=
es against censorship (and the basis of the censorship-resistance of Bitcoi=
n).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The attack itself is better classified as a form of sabotage=
 than censorship. The goal is to demonstrate the ongoing mutability of tran=
sactions beyond any inherent heuristic for =E2=80=9Cfinality=E2=80=9D. iow =
it is a demonstration that will damage the network=E2=80=99s future ability=
 to offer settlement assurances.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Trying to use Child Pays For Parent to defend in a bidding w=
ar against an opportunist attacker retrieving spent Bitcoin via RBF is a lo=
sing game for the defender. There=E2=80=99s no opportunity cost for the att=
acker, any amount retrieved is profit. The defender, on the other hand, is =
always losing value. This is exactly the kind of conflict and discoordinati=
on the attack is intended to induce.<br>
&gt; &gt;<br>
&gt; &gt; Your defender, in this attack, should avoid the Sunk Cost Fallacy=
 here.<br>
&gt; &gt; If the defender has been so foolish as to provide a product or se=
rvice based on only a *few* confirmations, like 1 or 2, then that product o=
r service has been Sunk, and it should ignore the Sunk Cost here.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt; As the same value is under contest on both sides, they are equall=
y matched and both censoring and non-censoring miners will get the same inc=
entive, splitting up the network into two nearly equal halves, and then cha=
nce (lucky block discovery) decides between which is the winner or the lose=
r.<br>
&gt; &gt;<br>
&gt; &gt; The difference here is that the chainsplit in this case is in a m=
etastable state, and once a string of lucky block discoveries occurs, it fa=
lls into a stable state and now everybody agrees again on who won and who l=
ost.<br>
&gt; &gt; Your solution risks *persistent* *stable* chainsplits.<br>
&gt; &gt; Worse, this occurrence without your solution would only happen if=
 some miners actually attack the blockchain.<br>
&gt; &gt; With your solution, persistent chainsplits can occur without mali=
ce, simply chance.<br>
&gt;<br>
&gt; How would this mechanism produce a chainsplit by chance?<br>
<br>
I already described it in the previous post.<br>
<br>
Purge attacks happen all the time, when two miners mine blocks at nearly th=
e same time, but with different sets of transactions in their blocks.<br>
And as I pointed out, any mechanism which uses non-block data (such as memp=
ool data) *will* lead to persistent chainsplits.<br>
<br>
&gt; =C2=A0<br>
&gt;<br>
&gt; &gt; And as in many things in life, the only winning move is not to pl=
ay.<br>
&gt; &gt; Just wait for more than a small number of confirmations (e.g. 6 i=
s generally considered safe), and the chance that a Purge attack on your tr=
ansactions succeeds is low enough that worse force majeur (a rogue asteroid=
 hitting your datacenter, for example) is more likely.<br>
&gt;<br>
&gt; I got to thinking about &quot;purge attacks&quot; and mitigations beca=
use I was red teaming how G20 states that have seized the major mining oper=
ations could most effectively destroy value and confidence in Bitcoin. This=
 scenario is _a lot_ more likely than=C2=A0rogue asteroids.<br>
&gt;<br>
&gt; What happens if the G20 decide to reorg deeper 6 - say 10, or even 20?=
<br>
&gt;<br>
&gt; If the Bitcoin continues to offer replace by fee I think this will be =
their first attack with seized majority hashrate;<br>
&gt;<br>
&gt; - mine offline<br>
&gt; - reach &gt; 10 deep empty block reorg as heaviest chain=C2=A0<br>
&gt; - announce it<br>
&gt; - semi-honest mine with a preference for RBF&#39;ed &quot;root&quot; t=
xns, ignoring any profitable child pays for parent.<br>
&gt; - repeat above, until some goal reached (eg. $ value of Bitcoin reachi=
ng x)<br>
&gt; - switch to &quot;DoS mode&quot; where you empty block reorg the chain=
 tip<br>
&gt;<br>
&gt; If we got rid of RBF, their only option would be DoS mode. Once it sto=
ps, honest mining could resume and the blocks will fill back up again with =
transactions out of the mempool preserved in the right order.#<br>
<br>
You ***cannot*** get rid of RBF.<br></blockquote><div><br></div><div>What i=
s the evidence for this claim? Is there a proof?</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
The incentives of miners mean they will actually want to implement RBF and =
ignore any &quot;convention&quot; of RBF-flagging.<br></blockquote><div><br=
></div><div>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.</div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
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), an=
d will accept &quot;full&quot; RBF i.e. ignore the RBF flag and always appl=
y RBF to all transactions regardless.<br>
Nothing in consensus prevents this, and this is why we always wait for conf=
irmation.<br>
<br></blockquote><div><br></div><div>The whole point of this sabotage attac=
k is that it demonstrates that confirmation is not a reasonable way of mana=
ging this risk. If the depth of the empty block reorg was 20, even if every=
one stuck to the arbitrary 6 confirmation rule, nearly every Bitcoin transa=
ction from the 14 blocks between `chaintip-6` and `chaintip-20` is at risk =
of being double spent as it lands back in the mempool.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regardless of however many blocks are attacked, always remember that in the=
 end, this is still a *censorship* attack: it is attempting to censor Bitco=
in completely.<br>
As such, this page applies: <a href=3D"https://github.com/libbitcoin/libbit=
coin-system/wiki/Censorship-Resistance-Property" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship=
-Resistance-Property</a></blockquote><div><br></div><div>Censorship of avai=
lability of the network? That&#39;s DoS ie. what a standard empty reorg att=
ack.</div><div><br></div><div>Purge attack is an extension of this that ext=
ends such an into the realm of sabotage, where the integrity of previously-=
adequately-confirmed transactions is compromised by allowing users to doubl=
e spend them.</div><div><br></div><div>Cheers,</div><div>M</div></div><div =
dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div></div></div></d=
iv></div>

--0000000000004fb14b059e3a64a7--