Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8188CC002F; Tue, 18 Jan 2022 16:12:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5AD0C81AF5; Tue, 18 Jan 2022 16:12:58 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpzulxUMJBMM; Tue, 18 Jan 2022 16:12:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by smtp1.osuosl.org (Postfix) with ESMTPS id B838381AC4; Tue, 18 Jan 2022 16:12:56 +0000 (UTC) Received: by mail-ed1-x52c.google.com with SMTP id m11so5299090edi.13; Tue, 18 Jan 2022 08:12:56 -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=B/TgrxInF+5YQbcaOtIL0ToEg5UZXIJ8FpXqKZIXtrY=; b=No2to62gNosauyqu/J9Zdvkcv8gi/m9NykQa5mS9kM5swqynGxBkd1WQcPQe4XcUTX /v85zDnRACdL7+lw9AWKNRVNAt2NI24/GN9N7F6B6nqTMLF+MU+/u8RzYOwxDBgIx0Js BX1I6UXYJcYlSMQUDQU+YtHpJcNfwbJ91qdEX6Fxf9QgHyepp2ESDTIdlAk41An6gOfL qa5JvO1ZaLQWyX9hGKJ5Da17hH6lGeeJlf5bt87NNP8UFZMHaLgdRH9Wdzc38JvhbtBT XB2xRJvVzt+DTYkOZZQj6/sP6szpaqqifVTDlpwBTU3RD7zQuSpchFMCOIU8V7m/Z9/v VFuQ== 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=B/TgrxInF+5YQbcaOtIL0ToEg5UZXIJ8FpXqKZIXtrY=; b=J9MRSZcfv6NOW+Wp2b05cM+ZiTG3JWM80fzEC/RbxzZVoeg9rimk/ngf/XNWB6zjmc qr2pOdACH1qDo3cAuSCuCZedpFqU23Uz3vPlr9HX3aW1WIVh8WREg2DxF/ohEv4oELxd zRwLECqCDUfiaPpiQy+KfhtapyzQW+6XNOxGYaBqLgOwWjwvmEJJNg2TC3rIdBQxV6oN FC2e80sK7dGoAgTrAuT50SsQre1U9Aa5MIf1OtsqEInOnK+wNOmmGxLBni3S8fM32LBB uxM7ihp1gruSeKf4qOKnKFeEumS1JC8C2uBcG7UW1mdilICQ7+8SOp0TqYRQH7+Q1ivG vc9A== X-Gm-Message-State: AOAM532w1mVsb15i6RVvTfPy5nFU/Wf+GLluTsXHDpZOAYoJDCanWTBi Zkcrko7/d1tBjDr8l78Rt6WO7rywYw4S2htXDPk= X-Google-Smtp-Source: ABdhPJx2wbc3tfMeA+A0ARkbY08LvSYLOklIk4jpsmbBvstxl1LJDpv1r9XA3POuihB4m0PBubhwg1tZdn7ecBb1HvE= X-Received: by 2002:a17:906:dc95:: with SMTP id cs21mr11838774ejc.709.1642522374715; Tue, 18 Jan 2022 08:12:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 18 Jan 2022 10:12:36 -0600 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ae41ba05d5dd8a8c" X-Mailman-Approved-At: Tue, 18 Jan 2022 16:25:13 +0000 Cc: 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: Tue, 18 Jan 2022 16:12:58 -0000 --000000000000ae41ba05d5dd8a8c Content-Type: text/plain; charset="UTF-8" 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 > --000000000000ae41ba05d5dd8a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have any back-of-the-napkin math on quantifyin= g=C2=A0how much this would improve the situation vs existing methods (eg cp= fp)?



On Sat, Jan 1, 2= 022 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 bo= uncing around my head as an opportunity to clean up the fee paying semantic= s in bitcoin "for good". The design space is very wide on the app= roach 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= 9;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 resist= ant Payment Channels, and other long lived Smart Contracts that can't p= redict future fee rates. Having the fees paid in band makes writing these c= ontracts much more difficult as you can't merely express the logic you = want for the transaction, but also the fees.

Previously, I prop= osed a special type of transaction called a "Sponsor" which has s= ome special consensus=C2=A0+ mempool rules to allow arbitrarily appending f= ees to a transaction to bump it up in the mempool.

As an altern= ative, we could establish an account system in Bitcoin as an "extensio= n block".

Here's how it might work:

1. Define a special anyone can spend output type that is a "fee acco= unt" (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 sep= arate 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=C2=A0address=
4. These transactions are committ= ed 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 blo= ck of the transaction. The public key for account lookup can be recovered f= rom the message=C2=A0+ signature.
5. In any block, any of the fee account deposits can be: released into fe= es if there is a corresponding tx; consolidated together to reduce the numb= er of utxos (this can be just an OP_TRUE no metadata needed); or released i= nto fees *and paid back* into the requested withdrawal key (encumbering a 1= 00 block timeout). Signatures must be unique in a block.
6. Mempool logic is updated to allow attaching of ac= count fee spends to transactions, the mempool can restrict that an account = is not allowed more spend more than it's balance.

But ar= en't accounts "bad"?

Yes, accounts are bad. B= ut these accounts are not bad, because any funds withdrawn from the fee ext= ension are fundamentally locked for 100 blocks as a coinbase output, so the= re should be no issues with any series of reorgs. Further, since there is n= o "rich state" for these accounts, the state updates can always b= e applied in a conflict-free way in any order.


Improving the privacy of this design:<= /div>

This design could likely be modified to implement something lik= e Tornado.cash or something else so that the fee account paying can be unli= nked 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 =C2=A0split into a common = denominator and change, and keys are derived via a verifiable stealth addre= ss like protocol (so fee balances can be discovered by tracing the updates = posted). These updates could also be produced by individuals rather than mi= ners, 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 potentia= lly add sufficient privacy.

The LN can also be used with PTLCs = to, in theory, have another individual paid to sponsor a transaction on you= r behalf only if they reveal a valid sig from their fee paying account, alt= hough under this model it's hard to ensure that the owner doesn't p= ay a fee and then 'cancel' by withdrawing the rest. However, this c= ould be partly solved by using reputable fee accounts (reputation could be = measured somewhat decentralized-ly by longevity of the account and transact= ions paid for historically).

<= /div>
Scalability

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

Pay= ing someone else to pay for you via the LN also helps make this more effici= ent 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). Thi= s sort of design is naturally immune to pinning issues since you could offe= r to pay a fee for any TXID and the number of fee adding offers does not ne= ed to be restricted in the same way the descendant transactions would need = to be.

Without a fork?

This type of design c= ould be done as a federated network that bribes miners -- potentially even = retroactively after a block is formed. That might be sufficient to prove th= e concept works before a consensus upgrade is deployed, but such an approac= h 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
--000000000000ae41ba05d5dd8a8c--