Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A70A1C002F; Thu, 20 Jan 2022 05:23:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 706AA4029B; Thu, 20 Jan 2022 05:23:34 +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 ZUHcIXC3Xn1d; Thu, 20 Jan 2022 05:23:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 303D54011C; Thu, 20 Jan 2022 05:23:31 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id cx27so23812500edb.1; Wed, 19 Jan 2022 21:23:30 -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=ymbDdVfxaFJoW0dVVoTwRbjgWczPlU9b8n/bA8s74Co=; b=qUM8zKJnGYTCUNlDarb0yJBzKpksHBrPiLv2fyMNoxh6xLdW+3fF6v0xfoqPQ/EhIo 3/IeoYlYYR+Vfd+yLO8Ya8MiEDdvjDqMiKelOuAOnkpcjhTu87IY9ircO/ASh2GgFINz NF5q1tqJrpKsRGMTmwPQY2XH9EJ7aUlnVothaPyW785ueeSDpLW85UNnFyzJV+KH9v7y frWgeDI9trVf9D32GMObnHBvS+2DREvxBsIhZu32zRHU5NxN3B1LCHXS2pu7DCJG3vjH 1RLVTT2owo6qkRc1WWk8E0sXsUDEd3TY9RtV9pYYAoKhSHdUhPZglFtAMmGUkE8ZMC9F d+og== 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=ymbDdVfxaFJoW0dVVoTwRbjgWczPlU9b8n/bA8s74Co=; b=3HX2MqAWq7Tbay2y3bMqHKqIYymElJKOH1Ahh5rDoOJ8PXcThFIQepULIm6+MsnhsS 78T2S9HEovg85TcgzOjR3mgQRgwZV1f/6/PswYYLzKa/QEMMSd157Awm/rR9tQI34lec qpgBu2/rIVcNetoX7NCe6Fu9DfyogdsKgn4PRoPoiCEWRAddVDRYGJPdTlbviJXQ41Zy FtMj2Xt9b92W8SODAiuLAMhGus9KNZcMiOp72F4Qnoxew0Sdg1/ZENOtdDroy8SUXxg+ OE2sl5Qgs+uG6TmDIjuLndnKdJpl4Cyj/iUxavjzVP0ViGu4eBdaDa+bNztyBWQCDWOz +Yjw== X-Gm-Message-State: AOAM530fVKTbkvZxsVjE/THzPvKPkyClh09DULzhwJhhIZ9K8GaHR1bt eaboNJj/cK0kU3iq2tx2dceC5n7aM7s8eg5Z4nqvSmmfHCs= X-Google-Smtp-Source: ABdhPJzp9uSRIusEKoQnAVaKKYFCzUc4LASlzwN098xIQW8sE9eVvL0ttGkec0gY16wSxSDVCCeSRcoReKpSv6QZFoQ= X-Received: by 2002:a17:906:4788:: with SMTP id cw8mr25239882ejc.176.1642656209026; Wed, 19 Jan 2022 21:23:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Wed, 19 Jan 2022 23:23:12 -0600 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000d3c1e405d5fcb3e3" X-Mailman-Approved-At: Thu, 20 Jan 2022 09:15:18 +0000 Cc: Bitcoin Protocol Discussion , lightning-dev 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, 20 Jan 2022 05:23:34 -0000 --000000000000d3c1e405d5fcb3e3 Content-Type: text/plain; charset="UTF-8" Thanks for the info. > you could "sponsor yourself" directly or through a cycle involving > 1 txn. Ah I see, because the sighash flags aren't used to create the TXID. I don't really see the problem with cycles tho. Could a cycle cause problems for anyone? Seems like it would be a harmless waste of bytes. The fee-sponsoring OP_VER looks good too tho. On Wed, Jan 19, 2022 at 2:08 PM Jeremy wrote: > SIGHASH_BUNDLE > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html > > By cycles I meant that if you commit to the sponsors by TXID from the > witness, you could "sponsor yourself" directly or through a cycle involving > > 1 txn. > > With OP_VER I was talking about the proposal I linked here > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html > which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is > in the output space, and uses TXIDs, it is cycle-free. > > > -- > @JeremyRubin > > > > On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud > wrote: > >> Hmm, I don't know anything about SIGHASH_BUNDLE. The only references >> online I can find are just mentions (mostly from you). What is >> SIGHASH_BUNDLE? >> >> > unless you're binding a WTXID >> >> That could work, but it would exclude cases where you have a transaction >> that has already been partially signed and someone wants to, say, only sign >> that transaction if some 3rd party signs a transaction paying part of the >> fee for it. Kind of a niche use case, but it would be nice to support it if >> possible. If the transaction hasn't been signed at all yet, a new >> transaction can just be created that includes the prospective fee-payer, >> and if the transaction is fully signed then it has a WTXID to use. >> >> > then you can have fee bumping cycles >> >> What kind of cycles do you mean? You're saying these cycles would make it >> less robust to reorgs? >> >> > OP_VER >> >> I assume you mean something other than pushing the version onto the stack >> ? >> Is that related to your fee account idea? >> >> >> On Wed, Jan 19, 2022 at 1:32 AM Jeremy wrote: >> >>> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE >>> like proposals. >>> >>> For what you're discussing, I previously proposed >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html >>> which is similar. >>> >>> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue >>> that unless you're binding a WTXID (which is maybe too specific?) then you >>> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that >>> you are acyclic. >>> >>> The difference between a fee account and this approach basically boils >>> down to the impact on e.g. reorg stability, where the deposit/withdraw >>> mechanism is a bit more "robust" for reorderings in reorgs than the in-band >>> transaction approach, although they are very similar. >>> >>> -- >>> @JeremyRubin >>> >>> >>> >>> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud >>> wrote: >>> >>>> > because you make transactions third party malleable it becomes >>>> possible to bundle and unbundle transactions. >>>> >>>> What I was suggesting doesn't make it possible to malleate someone >>>> else's transaction. I guess maybe my proposal of using a sighash flag >>>> might have been unclear. Imagine it as a script opcode that just says "this >>>> transaction must be mined with this other transaction" - the only >>>> difference being that you can use any output with any encumberance as an >>>> input for fee bumping. It doesn't prevent the original transaction from >>>> being mined on its own. So adding junk inputs would be no more of a problem >>>> than dust attacks already are. It would be used exactly like cpfp, except >>>> it doesn't spend the parent. >>>> >>>> I don't think what I was suggesting is as different from your proposal. >>>> All the problems of fee revenue optimization and feerate rules that you >>>> mentioned seem like they'd also exist for your proposal, or for cpfp. Let >>>> me know if I should clarify further. >>>> >>>> On Tue, Jan 18, 2022 at 8:51 PM Jeremy wrote: >>>> >>>>> The issue with sighash flags is that because you make transactions >>>>> third party malleable it becomes possible to bundle and unbundle >>>>> transactions. >>>>> >>>>> This means there are circumstances where an attacker could e.g. see >>>>> your txn, and then add a lot of junk change/inputs + 25 descendants and >>>>> strongly anchor your transaction to the bottom of the mempool. >>>>> >>>>> because of rbf rules requiring more fee and feerate, this means you >>>>> have to bump across the whole package and that can get really messy. >>>>> >>>>> more generally speaking, you could imagine a future where mempools >>>>> track many alternative things that might want to be in a transaction. >>>>> >>>>> suppose there are N inputs each with a weight and an amount of fee >>>>> being added and the sighash flags let me pick any subset of them. However, >>>>> for a txn to be standard it must be < 100k bytes and for it to be consensus >>>>> < 1mb. Now it is possible you have to solve a knapsack problem in order to >>>>> rationally bundle this transaction out of all possibilities. >>>>> >>>>> This problem can get even thornier, suppose that the inputs I'm adding >>>>> themselves are the outputs of another txn in the mempool, now i have to >>>>> track and propagate the feerates of that child back up to the parent txn >>>>> and track all these dependencies. >>>>> >>>>> perhaps with very careful engineering these issues can be tamed. >>>>> however it seems with sponsors or fee accounts, by separating the pays-for >>>>> from the participates-in concerns we can greatly simplify it to something >>>>> like: compute effective feerate for a txn, including all sponsors that pay >>>>> more than the feerate of the base txn. Mine that txn and it's subsidies >>>>> using the normal algo. If you run out of space, all subsidies are >>>>> same-sized so just take the ones that pay the highest amount up until the >>>>> added marginal feerate is less than the next eligible txn. >>>>> >>>>> >>>>> -- >>>>> @JeremyRubin >>>>> >>>>> >>>>> >>>>> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud >>>>> wrote: >>>>> >>>>>> I see, its not primarily to make it cheaper to append fees, but also >>>>>> allows appending fees in cases that aren't possible now. Is that right? I >>>>>> can certainly see the benefit of a more general way to add a fee to any >>>>>> transaction, regardless of whether you're related to that transaction or >>>>>> not. >>>>>> >>>>>> How would you compare the pros and cons of your account-based >>>>>> approach to something like a new sighash flag? Eg a sighash flag that says >>>>>> "I'm signing this transaction, but the signature is only valid if mined in >>>>>> the same block as transaction X (or maybe transactions LIST)". This could >>>>>> be named SIGHASH_EXTERNAL. Doing this would be a lot more similar to other >>>>>> bitcoin transactions, and no special account would need to be created. Any >>>>>> transaction could specify this. At least that's the first thought I would >>>>>> have in designing a way to arbitrarily bump fees. Have you compared your >>>>>> solution to something more familiar like that? >>>>>> >>>>>> On Tue, Jan 18, 2022 at 11:43 AM Jeremy wrote: >>>>>> >>>>>>> Can you clarify what you mean by "improve the situation"? >>>>>>> >>>>>>> There's a potential mild bytes savings, but the bigger deal is that >>>>>>> the API should be much less vulnerable to pinning issues, fix dust leakage >>>>>>> for eltoo like protocols, and just generally allow protocol designs to be >>>>>>> fully abstracted from paying fees. You can't easily mathematically >>>>>>> quantify API improvements like that. >>>>>>> -- >>>>>>> @JeremyRubin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud >>>>>>> wrote: >>>>>>> >>>>>>>> Do you have any back-of-the-napkin math on quantifying how much >>>>>>>> this would improve the situation vs existing methods (eg cpfp)? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev < >>>>>>>> bitcoin-dev@lists.linuxfoundation.org> 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". >>>>>>>>> >>>>>>>>> *Here's how it might work:* >>>>>>>>> >>>>>>>>> 1. Define a special anyone can spend output type that is a "fee >>>>>>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount >>>>>>>>> associated with them, but are overall anyone can spend. >>>>>>>>> 2. All deposits to these outputs get stored in a separate UTXO >>>>>>>>> database for fee accounts >>>>>>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee >>>>>>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and >>>>>>>>> an address >>>>>>>>> 4. These transactions are committed in an extension block merkle >>>>>>>>> tree. While the actual signature must cover the TXID/Outpoint, the >>>>>>>>> committed data need only cover the index in the block of the transaction. >>>>>>>>> The public key for account lookup can be recovered from the message + >>>>>>>>> signature. >>>>>>>>> 5. In any block, any of the fee account deposits can be: released >>>>>>>>> into fees if there is a corresponding tx; consolidated together to reduce >>>>>>>>> the number of utxos (this can be just an OP_TRUE no metadata needed); or >>>>>>>>> released into fees *and paid back* into the requested withdrawal key >>>>>>>>> (encumbering a 100 block timeout). Signatures must be unique in a block. >>>>>>>>> 6. Mempool logic is updated to allow attaching of account fee >>>>>>>>> spends to transactions, the mempool can restrict that an account is not >>>>>>>>> allowed more spend more than it's balance. >>>>>>>>> >>>>>>>>> *But aren't accounts "bad"?* >>>>>>>>> >>>>>>>>> Yes, accounts are bad. But these accounts are not bad, because any >>>>>>>>> funds withdrawn from the fee extension are fundamentally locked for 100 >>>>>>>>> blocks as a coinbase output, so there should be no issues with any series >>>>>>>>> of reorgs. Further, since there is no "rich state" for these accounts, the >>>>>>>>> state updates can always be applied in a conflict-free way in any order. >>>>>>>>> >>>>>>>>> >>>>>>>>> *Improving the privacy of this design:* >>>>>>>>> >>>>>>>>> This design could likely be modified to implement something like >>>>>>>>> Tornado.cash or something else so that the fee account paying can be >>>>>>>>> unlinked from the transaction being paid for, improving privacy at the >>>>>>>>> expense of being a bit more expensive. >>>>>>>>> >>>>>>>>> Other operations could be added to allow a trustless mixing to be >>>>>>>>> done by miners automatically where groups of accounts with similar values >>>>>>>>> are trustlessly split into a common denominator and change, and keys are >>>>>>>>> derived via a verifiable stealth address like protocol (so fee balances can >>>>>>>>> be discovered by tracing the updates posted). These updates could also be >>>>>>>>> produced by individuals rather than miners, and miners could simply honor >>>>>>>>> them with better privacy. While a miner generating an update would be able >>>>>>>>> to deanonymize their mixes, if you have your account mixed several times by >>>>>>>>> independent miners that could potentially add sufficient privacy. >>>>>>>>> >>>>>>>>> The LN can also be used with PTLCs to, in theory, have another >>>>>>>>> individual paid to sponsor a transaction on your behalf only if they reveal >>>>>>>>> a valid sig from their fee paying account, although under this model it's >>>>>>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by >>>>>>>>> withdrawing the rest. However, this could be partly solved by using >>>>>>>>> reputable fee accounts (reputation could be measured somewhat >>>>>>>>> decentralized-ly by longevity of the account and transactions paid for >>>>>>>>> historically). >>>>>>>>> >>>>>>>>> *Scalability* >>>>>>>>> >>>>>>>>> This design is fundamentally 'decent' for scalability because >>>>>>>>> adding fees to a transaction does not require adding inputs or outputs and >>>>>>>>> does not require tracking substantial amounts of new state. >>>>>>>>> >>>>>>>>> Paying someone else to pay for you via the LN also helps make this >>>>>>>>> more efficient if the withdrawal issues can be fixed. >>>>>>>>> >>>>>>>>> *Lightning:* >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> *Without a fork?* >>>>>>>>> >>>>>>>>> This type of design could be done as a federated network that >>>>>>>>> bribes miners -- potentially even retroactively after a block is formed. >>>>>>>>> That might be sufficient to prove the concept works before a consensus >>>>>>>>> upgrade is deployed, but such an approach does mean there is a centralizing >>>>>>>>> layer interfering with normal mining. >>>>>>>>> >>>>>>>>> >>>>>>>>> Happy new year!! >>>>>>>>> >>>>>>>>> Jeremy >>>>>>>>> >>>>>>>>> -- >>>>>>>>> @JeremyRubin >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> bitcoin-dev mailing list >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>>> >>>>>>>> --000000000000d3c1e405d5fcb3e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the info.

>=C2=A0you could &= quot;sponsor yourself" directly or through a cycle involving > 1 tx= n.

Ah I see, because the sighash flags aren't us= ed to create the TXID. I don't really see the problem with cycles tho. = Could a cycle cause problems for anyone? Seems like it would be a harmless = waste of bytes. The fee-sponsoring OP_VER looks good too tho.=C2=A0<= /div>

On Wed, Jan 19, 2022 at 2:08 PM Jeremy <jlrubin@mit.edu> wrote:
SIGHASH_BUNDLE=C2=A0https://lists.linux= foundation.org/pipermail/bitcoin-dev/2018-April/015862.html

By cycles I meant that if you commit to the sponsors by TXID from the wit= ness, you could "sponsor yourself" directly or through a cycle in= volving > 1 txn.

With OP_VER I was talking about the proposa= l I linked here=C2=A0https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html whic= h used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is in th= e output space, and uses TXIDs, it is cycle-free.




On Wed, Jan 19, 2= 022 at 8:52 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:
Hmm, I don't kn= ow anything about=C2=A0 SIGHASH_BUNDLE. The only references online I can find are just mentions (mo= stly from you). What is=C2=A0 SIGHASH_BUNDLE?

> unless you're binding a WTXID

That could work, but it would exclude cases where y= ou have a transaction that has already been partially signed and someone wa= nts to, say, only sign that transaction if some 3rd party signs a transacti= on paying part of the fee for it. Kind of a niche use case, but it would be= nice to support it if possible. If the transaction hasn't been signed = at all yet, a new transaction can just be created that includes the prospec= tive fee-payer, and if the transaction is fully signed then it has a WTXID = to use.

> then you can have fee bumping cycles<= /div>

What kind of cycles do you mean? You're saying= these cycles would make it less robust to reorgs?

> OP_VER

I assume you mean something other tha= n pushing the version onto the stack? Is that related to your= fee account idea?


On Wed, Jan 19, 2022 at 1:32 AM Jere= my <jlrubin@mit.edu= > wrote:
=
Ah my bad i misread wh= at you were saying as being about SIGHASH_BUNDLE like proposals.

For what you're discussing, I previo= usly proposed=C2=A0https://lists.linu= xfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html which = is similar.
The benefit o= f the OP_VER output is that SIGHASH_EXTERNAL has the issue that unless you&= #39;re binding a WTXID (which is maybe too specific?) then you can have fee= bumping cycles. Doing OP_VER output w/ TXID guarantees that you are acycli= c.

The difference between= a fee account and this approach basically boils down to the impact on e.g.= reorg stability, where the deposit/withdraw mechanism is a bit more "= robust" for reorderings in reorgs than the in-band transaction approac= h, although they are very similar.

--
<= div>


On Tue, Jan 18, 2022= at 8:53 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:
>=C2=A0 bec= ause you make transactions third party malleable it becomes possible to bun= dle and unbundle transactions.

What I was sugges= ting doesn't make it possible to malleate someone else's transactio= n.=C2=A0I guess maybe my proposal of using a sighash flag might have be= en unclear. Imagine it as a script opcode that just says "this transac= tion=C2=A0must be mined with this other transaction" - the only differ= ence being that you can use any output with any encumberance=C2=A0as an inp= ut for fee=C2=A0bumping. It doesn't prevent the original transaction fr= om being mined on its own. So adding junk inputs would be no more of a prob= lem than dust attacks already are. It would be used exactly like cpfp, exce= pt it doesn't spend the parent.=C2=A0

= I don't think what I was suggesting is as different from your proposal.= All the problems of fee revenue optimization and feerate rules that you me= ntioned seem like they'd also exist for your proposal, or for cpfp. Let= me know if I should clarify further.=C2=A0

On Tue, Jan 18, 202= 2 at 8:51 PM Jeremy <jlrubin@mit.edu> wrote:
The i= ssue with sighash flags is that because you make transactions third party m= alleable it becomes possible to bundle and unbundle transactions.

This means there are circumstances where an attacker could e.g. see your= txn, and then add a lot of junk change/inputs=C2=A0+ 25 descendants and st= rongly anchor your transaction to the bottom of the mempool.

be= cause of rbf rules requiring more fee and feerate, this means you have to b= ump across the whole package and that can get really messy.

mor= e generally speaking, you could imagine a future where mempools track many = alternative things that might want to be in a transaction.

sup= pose there are N inputs each with a weight and an amount of fee being added= and the sighash flags let me pick any subset of them. However, for a txn t= o be standard it must be < 100k bytes and for it to be consensus < 1m= b. Now it is possible you have to solve a knapsack problem in order to rati= onally bundle this transaction out of all possibilities.

This p= roblem can get even thornier, suppose that the inputs I'm adding themse= lves are the outputs of another txn in the mempool, now i have to track and= propagate the feerates of that child back up to the parent txn and track a= ll these dependencies.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">perhaps with very careful engineering th= ese issues can be tamed. however it seems with sponsors or fee accounts, by= separating the pays-for from the participates-in concerns we can greatly s= implify it to something like: compute effective feerate for a txn, includin= g all sponsors that pay more than the feerate of the base txn. Mine that tx= n and it's subsidies using the normal algo. If you run out of space, al= l subsidies are same-sized so just take the ones that pay the highest amoun= t up until the added marginal feerate is less than the next eligible txn.


<= /div>

On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud@gmail.com> w= rote:
I see, its not primarily to make it cheaper to append fees, but al= so allows appending fees in cases that aren't possible now. Is that rig= ht? I can certainly see the benefit of a more general way to add a fee to a= ny transaction, regardless of whether you're related to that transactio= n or not.=C2=A0

How would you compare the pros and cons = of your account-based approach to something like a new sighash flag? Eg a s= ighash flag that says "I'm signing this transaction, but the signa= ture is only valid if mined in the same block as transaction=C2=A0X (or may= be transactions LIST)". This could be named SIGHASH_EXTERNAL. Doing th= is would be a lot more similar to other bitcoin transactions, and no specia= l account would need to be created. Any transaction could specify this. At = least that's the first thought I would have in designing a way to arbit= rarily bump fees. Have you compared your solution to something more familia= r like that?

On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin@mit.edu> wrote:
<= /div>
Can you clarify what you mean by "imp= rove the situation"?

There's a potential mild bytes sa= vings, but the bigger deal is that the API should be much less vulnerable t= o pinning issues, fix dust leakage for eltoo like protocols, and just gener= ally allow protocol designs to be fully abstracted from paying fees. You ca= n't easily mathematically quantify=C2=A0API improvements=C2=A0like that= .

<= br>
On Tue,= Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Do y= ou have any back-of-the-napkin math on quantifying=C2=A0how much this would= improve the situation vs existing methods (eg cpfp)?

<= div>


On Sat, Jan 1, 2022 at 2:04 PM Jeremy via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Happy new years devs,

I figured = I would share some thoughts for conceptual review that have been bouncing a= round my head as an opportunity to clean up the fee paying semantics in bit= coin "for good". The design space is very wide on the approach I&= #39;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 integra= l part of bitcoin.

However, due to quirks of Bitcoin's tran= saction design, fees are a part of the transactions that they occur in.

While this works in a "Bitcoin 1.0" world, where all tra= nsactions are simple on-chain transfers, real world use of Bitcoin requires= support for things like Fee Bumping stuck transactions, DoS resistant Paym= ent Channels, and other long lived Smart Contracts that can't predict f= uture 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 s= pecial type of transaction called a "Sponsor" which has some spec= ial consensus=C2=A0+ mempool rules to allow arbitrarily appending fees to a= transaction to bump it up in the mempool.

As an alternative, w= e could establish an account system in Bitcoin as an "extension block&= quot;.

Here's how it might work:

1. Defi= ne a special anyone can spend output type that is a "fee account"= (e.g. segwit V2). Such outputs have a redeeming key and an amount associat= ed with them, but are overall anyone can spend.
2. All deposits to these outputs get stored in a separate UTX= O database for fee accounts
3. Fee= accounts can sign only two kinds of transaction: A: a fee amount and a TXI= D (or Outpoint?); B: a withdraw amount, a fee, and an=C2=A0address
4. These transactions are committed in an = extension block merkle tree. While the actual signature must cover the TXID= /Outpoint, the committed data need only cover the index in the block of the= transaction. The public key for account lookup can be recovered from the m= essage=C2=A0+ signature.
5. In any= block, any of the fee account deposits can be: released into fees if there= is a corresponding tx; consolidated together to reduce the number of utxos= (this can be just an OP_TRUE no metadata needed); or released into fees *a= nd paid back* into the requested withdrawal key (encumbering a 100 block ti= meout). Signatures must be unique in a block.
6. Mempool logic is updated to allow attaching of account fee s= pends to transactions, the mempool can restrict that an account is not allo= wed more spend more than it's balance.

But aren't ac= counts "bad"?

Yes, accounts are bad. But these ac= counts are not bad, because any funds withdrawn from the fee extension are = fundamentally locked for 100 blocks as a coinbase output, so there should b= e no issues with any series of reorgs. Further, since there is no "ric= h state" for these accounts, the state updates can always be applied i= n a conflict-free way in any order.


Improving the privacy of this design:

This design could likely be modified to implement something like Tornado.= cash or something else so that the fee account paying can be unlinked from = the transaction being paid for, improving privacy at the expense of being a= bit more expensive.

Other operations could be added to allow a= trustless mixing to be done by miners automatically where groups of accoun= ts with similar values are trustlessly =C2=A0split into a common denominato= r and change, and keys are derived via a verifiable stealth address like pr= otocol (so fee balances can be discovered by tracing the updates posted). T= hese updates could also be produced by individuals rather than miners, and = miners could simply honor them with better privacy. While a miner generatin= g an update would be able to deanonymize their mixes, if you have your acco= unt mixed several times by independent miners that could potentially add su= fficient privacy.

The LN can also be used with PTLCs to, in the= ory, have another individual paid to sponsor a transaction on your behalf o= nly if they reveal a valid sig from their fee paying account, although unde= r this model it's hard to ensure that the owner doesn't pay a fee a= nd then 'cancel' by withdrawing the rest. However, this could be pa= rtly solved by using reputable fee accounts (reputation could be measured s= omewhat decentralized-ly by longevity of the account and transactions paid = for historically).

Scalability

This d= esign is fundamentally 'decent' for scalability because adding fees= to a transaction does not require adding inputs or outputs and does not re= quire tracking substantial amounts of new state.

Paying someone= else to pay for you via the LN also helps make this more efficient if the = withdrawal issues can be fixed.
Lightning:

This type of design works really well for channels because the additi= on of fees to e.g. a channel state does not require any sort of pre-plannin= g (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of d= esign 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 re= stricted in the same way the descendant transactions would need to be.

Without a fork?
This type of design could be don= e as a federated network that bribes miners -- potentially even retroactive= ly after a block is formed. That might be sufficient to prove the concept w= orks before a consensus upgrade is deployed, but such an approach does mean= there is a centralizing layer interfering with normal mining.


Happy new year!!

Jeremy

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000d3c1e405d5fcb3e3--