path: root/84/13a6c34f133bf4a64a87a183eef0002c6d2e68

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 872CFC000B;
 Sat, 19 Feb 2022 00:38:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 6887481769;
 Sat, 19 Feb 2022 00:38:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Yc_VCkVOHEH7; Sat, 19 Feb 2022 00:38:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B9F4981425;
 Sat, 19 Feb 2022 00:38:40 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id e5so8354141lfr.9;
 Fri, 18 Feb 2022 16:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=7fFErMLPUa0c0gxXagbL5qwaTHAQ73SX9QNPzwC79vQ=;
 b=fNtplhpncULgvbh0DjL4a9JZ8fgSfn7dUebw3DrZkyhnvyEbAb/x5QDDlsKYcHH59w
 6xSoIPfn5jnztFupiiLG0EEEgL7CEvhMmOKhR0YekNFP2+NjW3/4ELxvTv6qv9OP3Ejs
 UyCrH5ju6Z8aaB3jBLptr1RPCLpZNVxNAIsC0gyV8ku31qN/wXirRYIO3mwoKeUDQmOC
 +8jQYFiVFILIspmdMICTjNgXl3xCcbeqaOZsM3iDo9Rh4oQhqOmlhycjmLd3HgrInwvu
 rNV1BdLXEZDZrNLQIJAuaGiK886ORqmWb5PqlEy7Pr47iPqPOqZKvDUFZRTqnY8q1t8o
 NNSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=7fFErMLPUa0c0gxXagbL5qwaTHAQ73SX9QNPzwC79vQ=;
 b=OL7SmTtXxDxu+CNUc8YTcsmyyYkUTYH0UF8b9shN+JTgXwIf+Mj2XeJmJNaneTVwlU
 RCJekS189Wlj7Ej0e4H4j9vo5E0K6UF3Tj54xDih1pEi+6wz3qMUCt7c0iMUr+R5Mtu2
 FB0muodLH0TLGIotyHQEZbF9FygsXw1MAER0A5kwXQeC9RvUafwcgcTKa0jpe+eSqvbv
 tR+TcYYQr8OylYSqpIsCj2bZcpgmRXTEbiWD3AQifSVivPEQELt7h7QPD8Jp2SEDN2rH
 PsKUcKNsF8HbMPsNISYol/uWlmgXhZH2bs81sIpU1+urnnnOPmfLsw1kM5MYfXEqsPwD
 hI2g==
X-Gm-Message-State: AOAM531kboFsTIwNexfc7AMrxMarBfTrLdo03ISsMZ3i0oMCn0jQO/OG
 KQC1tb3VWlwL4l3a4kMc+aUyGCRtbZ+omrZ0xWg=
X-Google-Smtp-Source: ABdhPJxK+equU/zk11jduEypaU9GEn5UhtbD9Gq2vcq66ZFTC710jCfnX8Kmj5KyrQyyUX/Dy0kfeMQFIQbjbknF9QY=
X-Received: by 2002:a05:6512:114c:b0:443:4d18:86c0 with SMTP id
 m12-20020a056512114c00b004434d1886c0mr7214191lfg.226.1645231118498; Fri, 18
 Feb 2022 16:38:38 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <YgS3sJvg6kG3WnVJ@petertodd.org>
 <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
 <YhAwr7+9mGJAe2/p@petertodd.org>
In-Reply-To: <YhAwr7+9mGJAe2/p@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Fri, 18 Feb 2022 16:38:27 -0800
Message-ID: <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000643e2d05d8543839"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Sat, 19 Feb 2022 00:38:45 -0000

--000000000000643e2d05d8543839
Content-Type: text/plain; charset="UTF-8"

> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.

I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).

Something that only increases possibility to make progress cannot be
pinning.

If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).

I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.

Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.

In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.

By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.

Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.

Best,

Jeremy

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">&gt;=C2=A0<span style=
=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">As I said, =
it&#39;s a new kind of pinning attack, distinct from other types of=C2=A0</=
span><span style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,=
34)">pinning attack.</span></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span =
style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></=
span></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><span style=3D"font-family:A=
rial,Helvetica,sans-serif;color:rgb(34,34,34)">I think pinning is &quot;for=
mally defined&quot; as sequences of transactions which prevent or make it l=
ess likely for you to=C2=A0make any progress (in terms of units of computat=
ion proceeding).</span></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span styl=
e=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span=
></div><div class=3D"gmail_default" style=3D"font-size:small">Something tha=
t only increases possibility to make progress cannot be pinning.</div><div =
class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"g=
mail_default" style=3D"font-size:small">If you want to call it something el=
se, with a negative connotation, maybe call it &quot;necromancing&quot; (br=
inging back txns that would otherwise be feerate/fee irrational).</div><div=
 class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">I would posit that we should be wh=
olly unconcerned with necromancing -- if your protocol is particularly vuln=
erable to a third party necromancing then your protocol is insecure and we =
shouldn&#39;t hamper Bitcoin&#39;s forward progress on secure applications =
to service already insecure ones. Lightning is particularly necromancy resi=
stant by design, but pinning vulnerable. This is also true with things like=
 coinjoins which are necromancy resistant but pinning vulnerable.</div><div=
 class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">Necromancy in particular is someth=
ing that isn&#39;t uniquely un-present in Bitcoin today, and things like pa=
ckage relay and elimination of pinning are inherently at odds with making n=
ecromancy either for CPFP use cases.</div><div class=3D"gmail_default" styl=
e=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-=
size:small">In particular, for the use case you mentioned &quot;Eg a third =
party could mess up OpenTimestamps calendars at relatively low cost by dela=
ying the mining of timestamp txs.&quot;, this is incorrect. A third party c=
an only accelerate the mining on the timestamp transactions, but they *can*=
 accelerate the mining of any such timestamp transaction. If you have a sin=
gle output chain that you&#39;re RBF&#39;ing per block,=C2=A0then at most t=
hey can cause you to shift the calendar commits forward one block. But agai=
n, they cannot pin you. If you want to shift it back one block earlier, jus=
t offer a higher fee for the later RBF&#39;d calendar. Thus the interferenc=
e is limited by how much you wish to pay to guarantee your commitment is in=
 this block as opposed to the next.</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default">By the way, you=
 can already do out-of-band transaction fees to a very similar effect, goog=
le &quot;BTC transaction accelerator&quot;. If the attack were at all valua=
ble to perform, it could happen today.</div><div class=3D"gmail_default"><b=
r></div><div class=3D"gmail_default">Lastly, if you do get &quot;necromance=
d&quot; on an earlier RBF&#39;d transaction by a third party for OTS, you s=
hould be relatively happy because it cost you less fees overall, since the =
undoing of your later RBF surely returned some satoshis to your wallet.</di=
v><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Best,=
</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">J=
eremy</div></div>

--000000000000643e2d05d8543839--