Return-Path: 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: In-Reply-To: From: Jeremy Rubin Date: Fri, 18 Feb 2022 16:38:27 -0800 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000643e2d05d8543839" Cc: Bitcoin Protocol Discussion , lightning-dev , Jeremy 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
>=C2=A0As I said, = it's a new kind of pinning attack, distinct from other types of=C2=A0pinning attack.

I think pinning is "for= mally defined" 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).

Something tha= t only increases possibility to make progress cannot be pinning.

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

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't hamper Bitcoin'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.

Necromancy in particular is someth= ing that isn'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.

In particular, for the use case you mentioned "Eg a third = party could mess up OpenTimestamps calendars at relatively low cost by dela= ying the mining of timestamp txs.", 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're RBF'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'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.

By the way, you= can already do out-of-band transaction fees to a very similar effect, goog= le "BTC transaction accelerator". If the attack were at all valua= ble to perform, it could happen today.
Lastly, if you do get "necromance= d" on an earlier RBF'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.

Best,=

J= eremy
--000000000000643e2d05d8543839--