Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 306EDC002F; Wed, 19 Jan 2022 20:08:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1786140947; Wed, 19 Jan 2022 20:08:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 IEydCMT4DPvM; Wed, 19 Jan 2022 20:08:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9979A40896; Wed, 19 Jan 2022 20:08:38 +0000 (UTC) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20JK8Zs8003431 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 19 Jan 2022 15:08:36 -0500 Received: by mail-lf1-f54.google.com with SMTP id x22so12661668lfd.10; Wed, 19 Jan 2022 12:08:36 -0800 (PST) X-Gm-Message-State: AOAM532B/AjvfLvsuqsrTjDeX7EOd9j2Lk2M5M84MH0dgS1BdBjlx0Px I7KYlAY5WEqthnQjJXKG/8/pfhEgWJLDAN0vqrQ= X-Google-Smtp-Source: ABdhPJzrnSM3hvpWnPYv2Z7DAij3dnIlSHl2Cp1Yw7ZJ8TxEfzg2gXVzqh7eHGSvZ8Qx5hBM+BFgs0QnvS8glZnuHk0= X-Received: by 2002:a05:6512:33ce:: with SMTP id d14mr26836459lfg.516.1642622914877; Wed, 19 Jan 2022 12:08:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Wed, 19 Jan 2022 12:08:23 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000575dd205d5f4f313" X-Mailman-Approved-At: Wed, 19 Jan 2022 20:12:17 +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: Wed, 19 Jan 2022 20:08:41 -0000 --000000000000575dd205d5f4f313 Content-Type: text/plain; charset="UTF-8" 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 >>>>>>>> >>>>>>> --000000000000575dd205d5f4f313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SIGHASH_BUNDLE=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Apr= il/015862.html

By cycles I meant that if you commit to the sponso= rs by TXID from the witness, you could "sponsor yourself" directl= y or through a cycle involving > 1 txn.

With OP_VER I was talking = about the proposal I linked here=C2=A0https://lists.lin= uxfoundation.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.




=
On Wed, Jan 19, 2022 at 8:52 AM Billy= Tetrud <billy.tetrud@gmail.co= m> wrote:
Hmm, I don'= t know 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 what you were saying as being about= SIGHASH_BUNDLE like proposals.

For what you're discussing, I previously proposed=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin= -dev/2020-September/018168.html which is similar.

The benefit of the OP_VER output is that SIGHA= SH_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 out= put 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 depo= sit/withdraw mechanism is a bit more "robust" for reorderings in = reorgs than the in-band transaction approach, although they are very simila= r.

--

On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <billy.tetrud@gmail.c= om> 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 issue with sighash flags is that b= ecause you make transactions third party malleable it becomes possible to b= undle and unbundle transactions.
<= br>
This means there are circumsta= nces where an attacker could e.g. see your txn, and then add a lot of junk = change/inputs=C2=A0+ 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 i= magine a future where mempools track many alternative things that might wan= t 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.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">This problem can get even thornier, supp= ose that the inputs I'm adding themselves are the outputs of another tx= n in the mempool, now i have to track and propagate the feerates of that ch= ild 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: com= pute 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 th= e normal algo. If you run out of space, all subsidies are same-sized so jus= t take the ones that pay the highest amount up until the added marginal fee= rate is less than the next eligible txn.




On Tue, Jan 18, 2022 at 6:= 38 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:
I see, its not primarily to make it cheaper to append fees, b= ut also allows appending fees in cases that aren't possible now. Is tha= t 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 trans= action or not.=C2=A0

How would you compare the pros and = cons of your account-based approach to something like a new sighash flag? E= g a sighash flag that says "I'm signing this transaction, but the = signature is only valid if mined in the same block as transaction=C2=A0X (o= r maybe transactions LIST)". This could be named SIGHASH_EXTERNAL. Doi= ng this would be a lot more similar to other bitcoin transactions, and no s= pecial 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 fa= miliar like that?

On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin@mit.edu> 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 mathematical= ly quantify=C2=A0API improvements=C2=A0like that.


On Tue, Jan 18, 2022 at 8:13 AM Bi= lly Tetrud <= billy.tetrud@gmail.com> wrote:
Do you 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 som= e thoughts for conceptual review that have been bouncing around my head as = an opportunity to clean up the fee paying semantics in bitcoin "for go= od". 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 imp= roved greatly.

Transaction fees are an integral part of bitcoin= .

However, due to quirks of Bitcoin's transaction design, f= ees are a part of the transactions that they occur in.

While th= is works in a "Bitcoin 1.0" world, where all transactions are sim= ple on-chain transfers, real world use of Bitcoin requires support for thin= gs 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 diffic= ult as you can't merely express the logic you want for the transaction,= but also the fees.

Previously, I proposed a special type of tr= ansaction called a "Sponsor" which has some special consensus=C2= =A0+ mempool rules to allow arbitrarily appending fees to a transaction to = bump it up in the mempool.

As an alternative, we could establis= h an account system in Bitcoin as an "extension block".

Here's how it might work:

1. Define a special any= one 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, bu= t are overall anyone can spend.
2.= All deposits to these outputs get stored in a separate UTXO database for f= ee accounts
3. Fee accounts can si= gn only two kinds of transaction: A: a fee amount and a TXID (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 c= ommitted data need only cover the index in the block of the transaction. Th= e public key for account lookup can be recovered from the message=C2=A0+ si= gnature.
5. In any block, any of t= he fee account deposits can be: released into fees if there is a correspond= ing tx; consolidated together to reduce the number of utxos (this can be ju= st an OP_TRUE no metadata needed); or released into fees *and paid back* in= to the requested withdrawal key (encumbering a 100 block timeout). Signatur= es must be unique in a block.
6. M= empool logic is updated to allow attaching of account fee spends to transac= tions, the mempool can restrict that an account is not allowed more spend m= ore 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 wi= th any series of reorgs. Further, since there is no "rich state" = for these accounts, the state updates can always be applied in a conflict-f= ree way in any order.


Improving the privacy of this design:

This design c= ould likely be modified to implement something like Tornado.cash or somethi= ng 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 expen= sive.

Other operations could be added to allow a trustless mixi= ng to be done by miners automatically where groups of accounts with similar= values are trustlessly =C2=A0split into a common denominator and change, a= nd keys are derived via a verifiable stealth address like protocol (so fee = balances can be discovered by tracing the updates posted). These updates co= uld also be produced by individuals rather than miners, and miners could si= mply honor them with better privacy. While a miner generating an update wou= ld be able to deanonymize their mixes, if you have your account mixed sever= al times by independent miners that could potentially add sufficient privac= y.

The LN can also be used with PTLCs to, in theory, have anoth= er individual paid to sponsor a transaction on your behalf only if they rev= eal 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 'ca= ncel' by withdrawing the rest. However, this could be partly solved by = using reputable fee accounts (reputation could be measured somewhat decentr= alized-ly by longevity of the account and transactions paid for historicall= y).

Scalability

This design is funda= mentally 'decent' for scalability because adding fees to a transact= ion 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 is= sues can be fixed.

Lightning:

This ty= pe 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. ancho= rs) or transaction flexibility (SIGHASH flags). This sort of design is natu= rally immune to pinning issues since you could offer to pay a fee for any T= XID and the number of fee adding offers does not need to be restricted in t= he same way the descendant transactions would need to be.

= Without a fork?

This type of design could be done as a fede= rated 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.


<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">Happy new year!!

Jeremy
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000575dd205d5f4f313--