path: root/b9/0621343d2c6b79d7da6fd8204cb44c9d8898be

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A7CB3C0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 00:00:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 90D928734E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 00:00:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ngo+7NcWZMPO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 00:00:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 367438733F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 Feb 2020 00:00:04 +0000 (UTC)
Date: Sun, 09 Feb 2020 23:59:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1581292801;
 bh=uqLJAocTflV64A7DSvDjElMh5ZgETYVYO5aTw32xEkw=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=kr33PekGvseiR2GzbIK7dWwJGwzBQMRVWXkJt9ewulTvggpCDZ1YqPBKQzsEnC4R8
 pvrnpwleO7OmJBk131haVDEDftrCw2y6jszAKquZm/2aYCThaHbYf65JkVZuAAe9ny
 hjTUS6z3xZe9/fpFxGQ3dv/Ba/FILgItHRXj0w60=
To: Mike Kelly <mikekelly321@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <MQqr0u8z7KvEmdMtR7wez_tcwJIaKbfcBSJkv4DrVeg_NlgiX9R-ILWlvb596VLEh74NrIMC1l0Wh0XOz1pcnywMjAtJ_m60LezEU9rrU5E=@protonmail.com>
In-Reply-To: <CANqiZJYvtmuoDh7eqH+2xYTqC=hxMEBV-+9rD4w30yC7v4o31Q@mail.gmail.com>
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>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 00:00:06 -0000

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 incl=
uding transactions in their block that conflict with the eventually-consist=
ent state of consensus in the mempool.
> =C2=A0

What?

From the original post:

> TLDR
> * An attacker replaces the most recent blocks full of transactions with e=
mpty 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 broadcast=
ing transactions.

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.
Otherwise, newly-started nodes can be fooled into taking the "wrong" consen=
sus 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 d=
ata you provide with the block, you cannot use it safely without risking ch=
ainsplit.
> >
> > (and no, banning or even disincentivizing SPV mining will not work, dif=
ferent nodes have different views of the mempool and temporary chainsplits =
can occur by chance where one chainsplit has transactions that are not conf=
irmed in the other chainsplit, which again is just another short-term inadv=
ertent Purge attack on the network.)
> >
> > >
> > > > Purge attacks can still be defended against and does not require ma=
ss 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 transact=
ion that just offers to pay mining fees and transfers it back to me (i.e. c=
hild pays for parent) to convince miners to mine the purged transaction.
> > > > As the Purge attack is "just" a censorship attack (i.e. a censorshi=
p of all transactions in the block under attack), the increased mining fees=
 for the transactions being censored (i.e. offered via child-pays-for-paren=
t 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 t=
ransactions can be substantial enough that non-censoring miners can be conv=
inced to mine those transactions.
> > > > No coordination necessary, as is typical for all defenses against c=
ensorship (and the basis of the censorship-resistance of Bitcoin).
> > >
> > > The attack itself is better classified as a form of sabotage than cen=
sorship. 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 d=
emonstration that will damage the network=E2=80=99s future ability to offer=
 settlement assurances.
> > >
> > > Trying to use Child Pays For Parent to defend in a bidding war agains=
t 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, an=
y amount retrieved is profit. The defender, on the other hand, is always lo=
sing value. This is exactly the kind of conflict and discoordination the at=
tack 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 serv=
ice has been Sunk, and it should ignore the Sunk Cost here.
> >
> > From that point of view, the attacker and the defender are simply biddi=
ng up from the *same* value, i.e. the value of the UTXO that is being remov=
ed by the purge attack.
> > As the same value is under contest on both sides, they are equally matc=
hed and both censoring and non-censoring miners will get the same incentive=
, splitting up the network into two nearly equal halves, and then chance (l=
ucky block discovery) decides between which is the winner or the loser.
> >
> > The difference here is that the chainsplit in this case is in a metasta=
ble state, and once a string of lucky block discoveries occurs, it falls in=
to 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, si=
mply 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 th=
e 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 memp=
ool data) *will* lead to persistent chainsplits.

> =C2=A0
>
> > 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 gene=
rally considered safe), and the chance that a Purge attack on your transact=
ions succeeds is low enough that worse force majeur (a rogue asteroid hitti=
ng 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=C2=A0rogue 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 the=
ir first attack with seized majority hashrate;
>
> - mine offline
> - reach > 10 deep empty block reorg as heaviest chain=C2=A0
> - 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 tra=
nsactions 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), an=
d will accept "full" RBF i.e. ignore the RBF flag and always apply RBF to a=
ll transactions regardless.
Nothing in consensus prevents this, and this is why we always wait for conf=
irmation.


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.
As such, this page applies: https://github.com/libbitcoin/libbitcoin-system=
/wiki/Censorship-Resistance-Property


Regards,
ZmnSCPxj