Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 20C42C000B; Thu, 10 Feb 2022 08:09:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E5D7440465; Thu, 10 Feb 2022 08:09:14 +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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5FPiGPk8WQn; Thu, 10 Feb 2022 08:09:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by smtp2.osuosl.org (Postfix) with ESMTPS id 038D340127; Thu, 10 Feb 2022 08:09:12 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id 13so8881339lfp.7; Thu, 10 Feb 2022 00:09:12 -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=gHa/1ROYLNoTB+IyAJBEPt2gQ+sKNt8Ckf4U4TUSIsc=; b=ISnLBcbMrUl2HZC75rrpQXB8I6sLpUhmu8dvhjQCD4Lo6QiuOOkPyCFuQJN+wbXOHB btnox6HhV4ieH+GasvGy6u0t7qhlVGUZxo1qjeRo5xGR12FIdt73Akgna2y3z+L+Qn93 Zn67lNnkqtkqZyYDdESEP89TebP8fIC7oP7aKVon9JxFu7JI9UOGj9Y6fbK58+AodgnH BXaUrT7VBugOaO0iXLRT9DunVW0vDg0ttUn/yX/JbECRybCr4E0AY7JX6WaZq1QrL6V6 xMjNU0JC/y1HULU7LsRye4RMTLByy/1asKX7QEcc0qLSzS56X1f8A3DtaX0CvUWLc+7o /8jQ== 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=gHa/1ROYLNoTB+IyAJBEPt2gQ+sKNt8Ckf4U4TUSIsc=; b=Ij2q1M4ok6Km8pvynrhUz4uXwjHgDp00mH6MQkniGJsLtXvhKW/oR98cMqJut++eo4 Q2VnxKO6Uxz5qUO4Rml2f1LLq0lgwfE+GjnXd+ukJ4TKhvH/Srjyj3U8Q8RwlxDR8QZO dd6yxXoITMCq2VeRi2BIVeRJHYJfqvNmJcm9qA2htlUvE4zDgnTN/j/PRUtVgBvbNNZP nhO9wgwP1cmIcHSea/QiAzn/T6z2Hpk7LgZ7YhIvQz6TzRusNcvDbWO8LnrNLVG1hExi Gi1Q5ifYvXIkQYNy9liaPA3Nq52Ih34iwVzNwv+FFQAbQ1A7bZ2yeY5FCZvQZ1w2kj50 xDUQ== X-Gm-Message-State: AOAM5333stiGDjPvrQXyijncgwNIY4zuSs1O+u1WM1jSSo2bW1e8F0SO zN/uy79R7DqTaAvjAb+ifsxsXKNdh86+M7WqmIM= X-Google-Smtp-Source: ABdhPJzgaHWgufgBP1eRcnf3kaoNK06yx5VAA/TOXeKX9dknjCDDwXLtIL5qHooTxgQ4sN5EajxPNQuM11yVtONld4o= X-Received: by 2002:a05:6512:3e1a:: with SMTP id i26mr4426430lfv.175.1644480550514; Thu, 10 Feb 2022 00:09:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Thu, 10 Feb 2022 00:08:59 -0800 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000db2e105d7a577e4" Cc: 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: Thu, 10 Feb 2022 08:09:15 -0000 --0000000000000db2e105d7a577e4 Content-Type: text/plain; charset="UTF-8" That's not really pinning; painning usually refers to pinning something to the bottom of the mempool whereas these mechanisms make it easier to guarantee that progress can be made on confirming the transactions you're interested in. Often times in these protocols "the call is coming inside the house". It's not a third party adding fees we are scared of, it's a direct party to the protocol! Sponsors or fee accounts would enable you to ensure the protocol you're working on makes forward progress. For things like Eltoo the internal ratchet makes this work well. Protocols which depend on in mempool replacements before confirmation already must be happy (should they be secure) with any prior state being mined. If a third party pays the fee you might even be happier since the execution wasn't on your dime. Cheers, Jeremy On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote: > > Happy new years devs, > > > > I figured I would share some thoughts for conceptual review that have > been > > bouncing around my head as an opportunity to clean up the fee paying > > semantics in bitcoin "for good". The design space is very wide on the > > approach I'll share, so below is just a sketch of how it could work which > > I'm sure could be improved greatly. > > > > Transaction fees are an integral part of bitcoin. > > > > However, due to quirks of Bitcoin's transaction design, fees are a part > of > > the transactions that they occur in. > > > > While this works in a "Bitcoin 1.0" world, where all transactions are > > simple on-chain transfers, real world use of Bitcoin requires support for > > things like Fee Bumping stuck transactions, DoS resistant Payment > Channels, > > and other long lived Smart Contracts that can't predict future fee rates. > > Having the fees paid in band makes writing these contracts much more > > difficult as you can't merely express the logic you want for the > > transaction, but also the fees. > > > > Previously, I proposed a special type of transaction called a "Sponsor" > > which has some special consensus + mempool rules to allow arbitrarily > > appending fees to a transaction to bump it up in the mempool. > > > > As an alternative, we could establish an account system in Bitcoin as an > > "extension block". > > > > > This type of design works really well for channels because the addition > of > > fees to e.g. a channel state does not require any sort of pre-planning > > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of > > design is naturally immune to pinning issues since you could offer to > pay a > > fee for any TXID and the number of fee adding offers does not need to be > > restricted in the same way the descendant transactions would need to be. > > So it's important to recognize that fee accounts introduce their own kind > of > transaction pinning attacks: third parties would be able to attach > arbitrary > fees to any transaction without permission. This isn't necessarily a good > thing: I don't want third parties to be able to grief my transaction > engines by > getting obsolete transactions confirmed in liu of the replacments I > actually > want confirmed. Eg a third party could mess up OpenTimestamps calendars at > relatively low cost by delaying the mining of timestamp txs. > > Of course, there's an obvious way to fix this: allow transactions to > designate > a pubkey allowed to add further transaction fees if required. Which Bitcoin > already has in two forms: Replace-by-Fee and Child Pays for Parent. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000000db2e105d7a577e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's not really pinning; painning usually refers to= pinning something to the bottom of the mempool whereas these mechanisms ma= ke it easier to guarantee that progress can be made on confirming the trans= actions you're interested in.

Often times in these protocols "the call is coming inside the hous= e". It's not a third party adding fees we are scared of, it's = a direct party to the protocol!

Sponsors or fee accounts would enable you to ensure the protocol = you're working on makes forward progress. For things like Eltoo the int= ernal ratchet makes this work well.

Protocols which depend on in mempool replacements before confir= mation already must be happy (should they be secure) with any prior state b= eing mined. If a third party pays the fee you might even be happier since t= he execution wasn't on your dime.=C2=A0

Cheers,

Jeremy

On Wed, Feb 9, 2022, 10:59 PM Peter Todd via bitcoin-dev &l= t;bitcoin-dev@list= s.linuxfoundation.org> wrote:
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000000db2e105d7a577e4--