path: root/c8/f08fa7a0ec48adde6e265c1c71a66f9de76a13

Return-Path: <mikekelly321@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E13EEC0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 10:15:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 9473F1FD21
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 10:15:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pwXE32itTmur
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 10:15:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com
 [209.85.219.67])
 by silver.osuosl.org (Postfix) with ESMTPS id 6EB1A2049F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 10:15:30 +0000 (UTC)
Received: by mail-qv1-f67.google.com with SMTP id s7so1806688qvn.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 Feb 2020 02:15:30 -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=nLItXWIACQFmNuunq3cIK6AM86wQVv1dlumLoMn45PA=;
 b=ol60NzyRnsQpbas3JidfYV0WNyLQrSCzs13IngEghQtL4PEkwG+ezed18zjqCTrF8b
 OUZz5dsIMk25DHL0h8oJZ2c4vygBi5zr0zr3gmfMRn19Dg/B2dzh85BR015VHd7Irma2
 ltZqUbhW6LRDm/uqxwAY5Cailg1DS6tPnDnbYHdUCWqdVR4VPtou8mlh54yXMPxKBrg4
 AYEL9lprZyFIcQA+Qu8sBW8xTR9y4kpE+0/iEeysR1fDpAF3HHQQcJ1UkxWoZK43lVlq
 0yTKe673szXHnUBNWf8U5By1gyMdmBnJoR7+X+IQNCsy0scSc5GOCZxvI/hIgFAEeJeV
 MafQ==
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=nLItXWIACQFmNuunq3cIK6AM86wQVv1dlumLoMn45PA=;
 b=OuCo84ZgaB2RQb55DnAbEz/xvrpIjszUeYYOKvl7UvufMEfF/Rrt9fKawXvOGWFDsG
 z4ypowTAR4uZAIIlFUAk5og3JIBWzDjmaGJq2lPowjsO8UzteAlL7AbR47bduuDJh/WY
 MJABHFdczskZ0fKnEdaHc4+tQ6R9V5PAk1wcEypb5RxOMdrVlGZxtAxvL2hTPXH8EDrj
 Cgz+gHM2sdQ9XjUsxsixX5cDHcktrlTzaYV/tHU+oY/4H06uqVx7GI7GKlxXLEMt2DZA
 IrstVdQXhvZ1500IOrw2gXTdu9ryf+f75Jxhuz0y/3SX4Bv+dTzhShvtg5mMCpyPFAng
 ReAQ==
X-Gm-Message-State: APjAAAUfOOQVDirCHeE+AEOqvAoEfOhVzM+VTBH46Sy6NJIhH5CAIa+H
 ARJOa+i08Ia0mbsoVYduK5Av/lXjsMALPJRjfVc=
X-Google-Smtp-Source: APXvYqwFcq73AOV54Z8nSascAJXxQ/KqotVzDdpeMT839HYehymoecliZdK40h8MkBzE8zN7RZuJR1+vtbmv6O0vxE4=
X-Received: by 2002:ad4:514e:: with SMTP id g14mr5773449qvq.196.1581243329280; 
 Sun, 09 Feb 2020 02:15:29 -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>
In-Reply-To: <u0lEEiLwMX1seNC4Wz7nfizIB2zaj4HfINI9rnh0ZBPJkW02uMw-6HCWemKpz5xr8MYxkTQWpCa4ucnM5Qj82qBlgW5BnlUBd5Pv2f_Ho6A=@protonmail.com>
From: Mike Kelly <mikekelly321@gmail.com>
Date: Sun, 9 Feb 2020 10:15:18 +0000
Message-ID: <CANqiZJYvtmuoDh7eqH+2xYTqC=hxMEBV-+9rD4w30yC7v4o31Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f1ff12059e21e634"
X-Mailman-Approved-At: Sun, 09 Feb 2020 14:02:08 +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: Sun, 09 Feb 2020 10:15:34 -0000

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

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 mempoo=
l
> > > > * 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 neve=
r
> attested to in the blockchain.
> >
> > Yes, it intentionally violates that rule. It=E2=80=99s unclear to me ri=
ght 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 innocen=
t
> of wrongdoing and will support the "purged" chainsplit, whereas those nea=
r
> 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 dat=
a
> 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 transactio=
n
> that just offers to pay mining fees and transfers it back to me (i.e. chi=
ld
> 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-pare=
nt
> in this case) is an economic counterattack on the censoring miner (i.e. i=
t
> 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, a=
ny amount
> retrieved is profit. The defender, on the other hand, is always losing
> value. This is exactly the kind of conflict and discoordination the attac=
k
> 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 remove=
d
> by the purge attack.
> As the same value is under contest on both sides, they are equally matche=
d
> 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 metastabl=
e
> 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

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

<div dir=3D"ltr"><div>Hi ZmnSCPxj,=C2=A0</div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 9, 2020 at 12:00 AM Zmn=
SCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.co=
m</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Good morning M,<br>
<br>
&gt; &gt; &gt; Nodes reject announced blocks that:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; * include transactions that are in contest with any in their=
 mempool<br>
&gt; &gt; &gt; * include transactions that are in contest with any in the c=
ontest pool<br>
&gt; &gt;<br>
&gt; &gt; Is this intended to be a consensus rule, i.e. nodes will never ac=
cept such a block?<br>
&gt; &gt;<br>
&gt; &gt; Because if so, this fails the principle of Blockchain Self-Contai=
nment, i.e. consensus rules can only check what is in the blockchain.<br>
&gt; &gt; The mempool (and contest pool) is not in the blockchain as it is =
never attested to in the blockchain.<br>
&gt;<br>
&gt; Yes, it intentionally violates that rule. It=E2=80=99s unclear to me r=
ight now what the consequence/cost of doing so in this specific way would b=
e. Are you able to explain?<br>
<br>
Violation of this principle can cause persistent chainsplits where you indu=
ce one set of nodes to see one view of reality while another set of nodes s=
ee another view.<br>
For instance, suppose two innocent miners happen to find blocks at nearly t=
he same time.<br>
Unfortunately for them, one miner happened to be using &quot;SPV&quot; mini=
ng i.e. mining empty blocks.<br>
<br>
From the point of view of arbitrary nodes, this is indistinguishable from a=
 one-block purge attack as described.<br>
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 &quot;purged&quot; chainsplit, whereas tho=
se near the other miner will consider that block bad and will support the o=
ther &quot;unpurged&quot; chainsplit.<br>
This is an even worse consequence than any purge attack, and could happen c=
ompletely by chance with no malice involved.<br>
<br></blockquote><div><br></div><div>I don&#39;t see how the scenario you o=
utline here has anything to do with the mechanism I proposed. An empty bloc=
k doesn&#39;t contain any transactions (by definition) so it wont contest a=
ny transactions in any given node&#39;s mempool. The aim isn&#39;t to preve=
nt empty nodes, it&#39;s to discourage miners from including transactions i=
n their block that conflict with the eventually-consistent state of consens=
us in the mempool.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
Always avoid violating that principle in any consensus code.<br>
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 chains=
plit.<br>
<br>
(and no, banning or even disincentivizing SPV mining will not work, differe=
nt nodes have different views of the mempool and temporary chainsplits can =
occur by chance where one chainsplit has transactions that are not confirme=
d in the other chainsplit, which again is just another short-term inadverte=
nt Purge attack on the network.)<br>
<br>
<br>
&gt;<br>
&gt; &gt; Purge attacks can still be defended against and does not require =
mass cooperation.<br>
&gt; &gt; If there is a transaction that is economically beneficial to me, =
it does so by paying some Bitcoins to me.<br>
&gt; &gt; If it pays Bitcoins to me, I can spend those Bitcoins in a transa=
ction 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.<=
br>
&gt; &gt; As the Purge attack is &quot;just&quot; 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-pa=
ys-for-parent in this case) is an economic counterattack on the censoring m=
iner (i.e. it forgoes the mining fees).<br>
&gt;<br>
&gt; &gt; With enough self-interested users, the fee offered to confirm the=
 transactions can be substantial enough that non-censoring miners can be co=
nvinced to mine those transactions.<br>
&gt; &gt; No coordination necessary, as is typical for all defenses against=
 censorship (and the basis of the censorship-resistance of Bitcoin).<br>
&gt;<br>
&gt; The attack itself is better classified as a form of sabotage than cens=
orship. The goal is to demonstrate the ongoing mutability of transactions b=
eyond any inherent heuristic for =E2=80=9Cfinality=E2=80=9D. iow it is a de=
monstration that will damage the network=E2=80=99s future ability to offer =
settlement assurances.<br>
&gt;<br>
&gt; 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 always los=
ing value. This is exactly the kind of conflict and discoordination the att=
ack is intended to induce.<br>
<br>
Your defender, in this attack, should avoid the Sunk Cost Fallacy here.<br>
If the defender has been so foolish as to provide a product or service base=
d 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.<br>
<br>
From that point of view, the attacker and the defender are simply bidding u=
p from the *same* value, i.e. the value of the UTXO that is being removed b=
y the purge attack.<br>
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, sp=
litting up the network into two nearly equal halves, and then chance (lucky=
 block discovery) decides between which is the winner or the loser.<br>
<br>
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.<br>
Your solution risks *persistent* *stable* chainsplits.<br>
Worse, this occurrence without your solution would only happen if some mine=
rs actually attack the blockchain.<br>
With your solution, persistent chainsplits can occur without malice, simply=
 chance.<br></blockquote><div><br></div><div>How would this mechanism produ=
ce a chainsplit by chance?</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<br>
And as in many things in life, the only winning move is not to play.<br>
Just wait for more than a small number of confirmations (e.g. 6 is generall=
y considered safe), and the chance that a Purge attack on your transactions=
 succeeds is low enough that worse force majeur (a rogue asteroid hitting y=
our datacenter, for example) is more likely.<br><br></blockquote><div><br><=
/div><div>I got to thinking about &quot;purge attacks&quot; 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=C2=A0rogue asteroids.</div><div>=
<br></div><div>What happens if the G20 decide to reorg deeper 6 - say 10, o=
r even 20?</div><div><br></div><div>If the Bitcoin continues to offer repla=
ce by fee I think this will be their first attack with seized majority hash=
rate;</div><div><br></div><div>- mine offline</div><div>- reach &gt; 10 dee=
p empty block reorg as heaviest chain=C2=A0</div><div>- announce it</div><d=
iv>- semi-honest mine with a preference for RBF&#39;ed &quot;root&quot; txn=
s, ignoring any profitable child pays for parent.</div><div>- repeat above,=
 until some goal reached (eg. $ value of Bitcoin reaching x)</div><div>- sw=
itch to &quot;DoS mode&quot; where you empty block reorg the chain tip</div=
><div><br></div><div>If we got rid of RBF, their only option would be DoS m=
ode. Once it stops, honest mining could resume and the blocks will fill bac=
k up again with transactions out of the mempool preserved in the right orde=
r.#</div><div><br></div><div>Hope that makes sense.</div><div><br></div><di=
v>Best,</div><div>Mike</div><div></div></div><div dir=3D"ltr" class=3D"gmai=
l_signature"><div dir=3D"ltr"></div></div></div>

--000000000000f1ff12059e21e634--