From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ZmnSCPxj@protonmail.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 74835C0035 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Feb 2022 02:39:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 617FB408FC for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Feb 2022 02:39:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99YdYOE-FfmF for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Feb 2022 02:39:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp4.osuosl.org (Postfix) with ESMTPS id 68901408FB for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 20 Feb 2022 02:39:58 +0000 (UTC) Date: Sun, 20 Feb 2022 02:39:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645324795; bh=EtW9S6uDxVo/ugRrYtgZm5qgPalVGC5Bue4jEcetKGg=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=HGnlg/l8vfFIOck06xlZNRH8RdOuwoC704r8sMH1vHDAvPTWNaI0m4Zr6w4uo0cr6 ABq48KCS6PeJMYRzwR2sS6dIQhe8VStqAXKyJ69HwShXTyxrXeRVriYkze+uq5FfNT O1/0iBJ/ryuBwKiy5x7Fqgm6N2cjpVKfjRRMkFOUIr501ZdZ0oWh/Qmblb3qhzYRok hq/cGFLWVmZyto8O29+wdbDX97uRJV1YHDhRWY6ME2rz+tTxzt5b6FaBP247t3GgCt FlnwKT0utHtttGu/f7rwDK0SspgwsgSq0l62QKxV8NgZZsR0XwvxWpIQRhX7eL6PES 3X14CLk018Aow== To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <sU815XyMYVgcVVo1yHJSUgfiraHeug7GNMMPxu_PQhv_Zhld3XPa82DawQp3vOsWppvvBZkPEt4h95fwALOcMPIy-wOvMp3fYb_xzV92V-E=@protonmail.com> In-Reply-To: <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.com> 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> <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com> <YhC6yjoe3bAfBS+W@petertodd.org> <kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com> <YhFUiA9/YlY99Bok@petertodd.org> <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>, Jeremy <jlrubin@mit.edu> Subject: Re: [bitcoin-dev] [Lightning-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: Sun, 20 Feb 2022 02:39:59 -0000 Good morning Peter and Jeremy, > Good morning Peter and Jeremy, > > > On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote: > > > > > > Necromancing might be a reasonable name for attacks that work by ge= tting an > > > > out-of-date version of a tx mined. > > > > > > It's not an "attack"? There is no such thing as an out-of-date transa= ction, if > > > you signed and broadcasted it in the first place. You can't rely on t= he fact that > > > a replacement transaction would somehow invalidate a previous version= of it. > > > > Anyone on the internet can send you a packet; a secure system must be a= ble to > > receive any packet without being compromised. Yet we still call packet = floods > > as DoS attacks. And internet standards are careful to avoid making pack= et > > flooding cheaper than it currently is. > > The same principal applies here: in many situations transactions do bec= ome > > out of date, in the sense that you would rather a different transaction= be > > mined instead, and the out-of-date tx being mined is expensive and anno= ying. > > While you have to account for the possibility of any transaction you ha= ve > > signed being mined, Bitcoin standards should avoid making unwanted necr= omancy a > > cheap and easy attack. > > This seems to me to restrict the only multiparty feebumping method to be = some form of per-participant anchor outputs a la Lightning anchor commitmen= ts. > > Note that multiparty RBF is unreliable. > While the initial multiparty signing of a transaction may succeed, at a l= ater time with the transaction unconfirmed, one or more of the participants= may regret cooperating in the initial signing and decide not to cooperate = with the RBF. > Or for that matter, a participant may, through complete accident, go offl= ine. > > Anchor outputs can be keyed to only a specific participant, so feebumping= of particular transaction can only be done by participants who have been a= uthorized to feebump. > > Perhaps fee accounts can include some kind of proof-this-transaction-auth= orizes-this-fee-account? For example: * We reserve one Tapscript version for fee-account-authorization. * Validation of this tapscript version always fails. * If a transaction wants to authorize a fee account, it should have at leas= t one Taproot output. * This Taproot output must have tapleaf with the fee-account-authorizatio= n Tapscript version. * In order for a fee account to feebump a transaction, it must also present= the Taproot MAST path to the fee-account-authorization tapleaf of one outp= ut of that transaction. This gives similar functionality to anchor outputs, without requiring an ex= plicit output on the initial transaction, saving blockspace. In particular, once the number of participants grows, the number of anchor = outputs must grow linearly with the number of participants being authorized= to feebump. Only when the feerate turns out to be too low do we need to expose the auth= orization. Revelation of the fee-account-authorization is O(log N), and if only one pa= rticipant decides to feebump, then only a single O(log N) MAST treepath is = published. Regards, ZmnSCPxj