Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 353BDC002F; Wed, 19 Jan 2022 02:37:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 113DC60E3F; Wed, 19 Jan 2022 02:37:59 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWEp2hNOLduu; Wed, 19 Jan 2022 02:37:57 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 4801160E3A; Wed, 19 Jan 2022 02:37:57 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id m11so4046511edi.13; Tue, 18 Jan 2022 18:37:57 -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=dHX3KlIuWryBubUeivv/v+a5oWhNrsvqEalU3kp6+KQ=; b=EZNKxPQ617XJvMmRXU/H+CPTCCCcPVHLDQmIecxIU1M4XeAbEoSgb2xeJSYIk7hSim aecq1uTzlH/BX3LrG3YnLARmXNW2SBSH0K+vWy+KNBNWJtNKyoBqqCjoJGtTo1hde7tK gOA9e6CVqERsGd1y6sGHttOqw4e1buDg9TRUIgXPHuZjf0mvSgB/hEFBI1gqxYqPp9AM gt6KRNisGAnX1436kHIP9vKjxOD5op+5J0Ejb40wNYZgJaNNcSgGbfL99UW/9665bXs2 PurW8VE3Xy9GEf/QAx+bWHNsrowGh2uHVMKF6QeuVZwGwREgJoZRPALdjE/alYqdm6NL lN7Q== 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=dHX3KlIuWryBubUeivv/v+a5oWhNrsvqEalU3kp6+KQ=; b=QV9JsDf1VRcrQB45R/+ykDAntUB8bRN0pYzIcWEGUUsvtzt0ftJicfN4tJkAE55Efm 0qXpEc8igGQRIKi8bv+rQt58N/EzAcW7eqpd4X1+cScYKc4OV1dcOgxYanPFZoB+5AgH XUPzbrC1kU7kPJsZxEZRh7truLkAX3/fzAImrgGA/F7Mj83qeEBPteRnKBy0J521xMNl /voAYzQWHtiMNYSgwljm5eI9TYVk952rLOLmZosfJb20dMUV05OJ82BSJi27ChGfz+ad xhMEPLKt4aUMG6Jz+V2k0/6P6Ec1phc9SD8u3h8MpOEwfdSJK8ysNddOCjnP4wibHhwC Um7A== X-Gm-Message-State: AOAM533y+aV0ttKZQo+nMHRo+FuQGS8bvoZrnwh3aTbD07i50gpI6CxX pZWOb9E1Qfta+G9NfPPymXs3miweZRjtupARq0WGbMeQzTY= X-Google-Smtp-Source: ABdhPJwaVx65RD8JMVXtYUOp2acn8RIZ/MNAzxw0zHjTE8cgoRdNL7CY5z13AqH/iSZCY9U77RBfvLCGryzNMEZ2fUA= X-Received: by 2002:a17:906:2bcf:: with SMTP id n15mr21861025ejg.184.1642559875464; Tue, 18 Jan 2022 18:37:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 18 Jan 2022 20:37:39 -0600 Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000e6444205d5e645c2" X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:26 +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 02:37:59 -0000 --000000000000e6444205d5e645c2 Content-Type: text/plain; charset="UTF-8" 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 >>> >> --000000000000e6444205d5e645c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 tr= ansaction or not.=C2=A0

How would you compare the pros a= nd 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 t= he signature is only valid if mined in the same block as transaction=C2=A0X= (or maybe transactions LIST)". This could be named SIGHASH_EXTERNAL. = Doing this would be a lot more similar to other bitcoin transactions, and n= o special account would need to be created. Any transaction could specify t= his. 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 <jlrubin@mit.edu> wrote:
Can you clarify what you mean by "improve the s= ituation"?

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 ea= sily mathematically quantify=C2=A0API improvements=C2=A0like that.


On Tue, Jan 18, 2= 022 at 8:13 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:
Do you have an= y back-of-the-napkin math on quantifying=C2=A0how much this would improve t= he situation vs existing methods (eg cpfp)?



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

I figured I would sh= are some thoughts for conceptual review that have been bouncing around my h= ead 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 sha= re, 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 de= sign, fees are a part of the transactions that they occur in.

W= hile this works in a "Bitcoin 1.0" world, where all transactions = are simple on-chain transfers, real world use of Bitcoin requires support f= or things like Fee Bumping stuck transactions, DoS resistant Payment Channe= ls, 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 trans= action, but also the fees.

Previously, I proposed a special typ= e of transaction called a "Sponsor" which has some special consen= sus=C2=A0+ mempool rules to allow arbitrarily appending fees to a transacti= on to bump it up in the mempool.
<= br>
As an alternative, we could es= tablish an account system in Bitcoin as an "extension block".

Here's how it might work:

1. Define a speci= al anyone can spend output type that is a "fee account" (e.g. seg= wit V2). Such outputs have a redeeming key and an amount associated with th= em, 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 Outp= oint?); 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 transacti= on. The public key for account lookup can be recovered from the message=C2= =A0+ signature.
5. In any block, a= ny of the fee account deposits can be: released into fees if there is a cor= responding tx; consolidated together to reduce the number of utxos (this ca= n be just an OP_TRUE no metadata needed); or released into fees *and paid b= ack* into the requested withdrawal key (encumbering a 100 block timeout). S= ignatures 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 fundame= ntally locked for 100 blocks as a coinbase output, so there should be no is= sues with any series of reorgs. Further, since there is no "rich state= " for these accounts, the state updates can always be applied in a con= flict-free way in any order.

<= /div>

Improving the privacy of this design:

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

Other operations could be added to allow a trustl= ess mixing to be done by miners automatically where groups of accounts with= similar values are trustlessly =C2=A0split into a common denominator and c= hange, and keys are derived via a verifiable stealth address like protocol = (so fee balances can be discovered by tracing the updates posted). These up= dates could also be produced by individuals rather than miners, and miners = could simply honor them with better privacy. While a miner generating an up= date would be able to deanonymize their mixes, if you have your account mix= ed several times by independent miners that could potentially add sufficien= t privacy.

The LN can also be used with PTLCs to, in theory, ha= ve 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 so= lved by using reputable fee accounts (reputation could be measured somewhat= decentralized-ly by longevity of the account and transactions paid for his= torically).

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 withd= rawal issues can be fixed.

Lightning:

This type of design works really well for channels because the addition o= f 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 desig= n 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 restri= cted 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 a= fter 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 the= re is a centralizing layer interfering with normal mining.

Happy new year!!

Jer= emy

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