diff options
| author | Jeremy <jlrubin@mit.edu> | 2022-01-18 18:51:42 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-19 02:52:00 +0000 |
| commit | 35fd4b4558d5f212f269e7e7e11da2be3f864e8e (patch) | |
| tree | ff69c59a32e641b0b3f4f70de54bb38c9cd996c9 | |
| parent | 7a002407a5d05fe86dcb5b56a56e99db4fa9f42e (diff) | |
| download | pi-bitcoindev-35fd4b4558d5f212f269e7e7e11da2be3f864e8e.tar.gz pi-bitcoindev-35fd4b4558d5f212f269e7e7e11da2be3f864e8e.zip | |
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
| -rw-r--r-- | 75/b6dd90bad21f3763b5eaeea13c3f2653065ab1 | 562 |
1 files changed, 562 insertions, 0 deletions
diff --git a/75/b6dd90bad21f3763b5eaeea13c3f2653065ab1 b/75/b6dd90bad21f3763b5eaeea13c3f2653065ab1 new file mode 100644 index 000000000..ec11344de --- /dev/null +++ b/75/b6dd90bad21f3763b5eaeea13c3f2653065ab1 @@ -0,0 +1,562 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 5AFC8C002F; + Wed, 19 Jan 2022 02:52:00 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 36194401D8; + Wed, 19 Jan 2022 02:52:00 +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 e2oUZKaSV_eK; Wed, 19 Jan 2022 02:51:58 +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 12E1F401D6; + Wed, 19 Jan 2022 02:51:57 +0000 (UTC) +Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com + [209.85.167.47]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20J2psoO000622 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); + Tue, 18 Jan 2022 21:51:56 -0500 +Received: by mail-lf1-f47.google.com with SMTP id e3so3284378lfc.9; + Tue, 18 Jan 2022 18:51:55 -0800 (PST) +X-Gm-Message-State: AOAM531T01vkN4Dfv1BhTD+wmxP/jgMVBQ1XqcKbpS8Kj3ieF9fbSUEn + IF8R311vcHcBm2z1jRK4+E84KXnaDijzMJbIKDc= +X-Google-Smtp-Source: ABdhPJyhIRw3KqIv9HYMrD7kRLSdO0B0rS7Y9I2KMNw6E2Ez5+1AkFiKq5f1KZpTW3nqaHj8Q4lMqiBCzZLBGVrtVYs= +X-Received: by 2002:a05:651c:1794:: with SMTP id + bn20mr23441643ljb.323.1642560714523; + Tue, 18 Jan 2022 18:51:54 -0800 (PST) +MIME-Version: 1.0 +References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com> + <CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com> + <CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com> + <CAGpPWDaQAxEfyFs_g9p=PTUNAkSiQKwPiHJbBaLmzfNTjFeucA@mail.gmail.com> +In-Reply-To: <CAGpPWDaQAxEfyFs_g9p=PTUNAkSiQKwPiHJbBaLmzfNTjFeucA@mail.gmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Tue, 18 Jan 2022 18:51:42 -0800 +X-Gmail-Original-Message-ID: <CAD5xwhjUkey+VD=u+69+5eirLCCoLgDgAR_4d20hwHo-eyZr6w@mail.gmail.com> +Message-ID: <CAD5xwhjUkey+VD=u+69+5eirLCCoLgDgAR_4d20hwHo-eyZr6w@mail.gmail.com> +To: Billy Tetrud <billy.tetrud@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000e94b0105d5e6774e" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev <lightning-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 19 Jan 2022 02:52:00 -0000 + +--000000000000e94b0105d5e6774e +Content-Type: text/plain; charset="UTF-8" + +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 <https://twitter.com/JeremyRubin> +<https://twitter.com/JeremyRubin> + + +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, 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 <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 mathematically quantify API +>> improvements like that. +>> -- +>> @JeremyRubin <https://twitter.com/JeremyRubin> +>> <https://twitter.com/JeremyRubin> +>> +>> +>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud@gmail.com> +>> 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 <https://twitter.com/JeremyRubin> +>>>> <https://twitter.com/JeremyRubin> +>>>> _______________________________________________ +>>>> bitcoin-dev mailing list +>>>> bitcoin-dev@lists.linuxfoundation.org +>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>>> +>>> + +--000000000000e94b0105d5e6774e +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000">The issue with sighash fl= +ags is that because you make transactions third party malleable it becomes = +possible to bundle and unbundle transactions.</div><div class=3D"gmail_defa= +ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,= +helvetica,sans-serif;font-size:small;color:#000000">This means there are ci= +rcumstances where an attacker could e.g. see your txn, and then add a lot o= +f junk change/inputs=C2=A0+ 25 descendants and strongly anchor your transac= +tion to the bottom of the mempool.</div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><= +br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,= +sans-serif;font-size:small;color:#000000">because of rbf rules requiring mo= +re fee and feerate, this means you have to bump across the whole package an= +d that can get really messy.</div><div class=3D"gmail_default" style=3D"fon= +t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></di= +v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se= +rif;font-size:small;color:#000000">more generally speaking, you could imagi= +ne a future where mempools track many alternative things that might want to= + be in a transaction.</div><div class=3D"gmail_default" style=3D"font-famil= +y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:#000000">suppose there are N inputs each with a weight a= +nd an amount of fee being added and the sighash flags let me pick any subse= +t 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 kn= +apsack problem in order to rationally bundle this transaction out of all po= +ssibilities.</div><div class=3D"gmail_default" style=3D"font-family:arial,h= +elvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"= +gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= +all;color:#000000">This problem can get even thornier, suppose that the inp= +uts 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 t= +he parent txn and track all these dependencies.</div><div class=3D"gmail_de= +fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo= +r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria= +l,helvetica,sans-serif;font-size:small;color:#000000">perhaps with very car= +eful engineering these issues can be tamed. however it seems with sponsors = +or fee accounts, by separating the pays-for from the participates-in concer= +ns 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 bas= +e txn. Mine that txn and it's subsidies using the normal algo. If you r= +un out of space, all subsidies are same-sized so just take the ones that pa= +y the highest amount up until the added marginal feerate is less than the n= +ext eligible txn.</div><div class=3D"gmail_default" style=3D"font-family:ar= +ial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div clas= +s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= +ze:small;color:#000000"><br></div><div><div dir=3D"ltr" class=3D"gmail_sign= +ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D= +"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href= +=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></di= +v><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= +attr">On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <<a href=3D"mailto:bi= +lly.tetrud@gmail.com">billy.tetrud@gmail.com</a>> wrote:<br></div><block= +quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w= +idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding= +-left:1ex"><div dir=3D"ltr">I see, its not primarily to make it cheaper to = +append fees, but also allows appending fees in cases that aren't possib= +le now. Is that right? I can certainly see the benefit of a more general wa= +y to add a fee to any transaction, regardless of whether you're related= + to that transaction or not.=C2=A0<div><br></div><div>How would you compare= + the pros and cons of your account-based approach to something like a new s= +ighash flag? Eg a sighash flag that says "I'm signing this transac= +tion, but the signature is only valid if mined in the same block as transac= +tion=C2=A0X (or maybe transactions LIST)". This could be named SIGHASH= +_EXTERNAL. Doing this would be a lot more similar to other bitcoin transact= +ions, and no special account would need to be created. Any transaction coul= +d specify this. At least that's the first thought I would have in desig= +ning a way to arbitrarily bump fees. Have you compared your solution to som= +ething more familiar like that?</div></div><br><div class=3D"gmail_quote"><= +div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 2022 at 11:43 AM Jerem= +y <<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu<= +/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= +px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-= +color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)">Can you clarify what you mean by "improve the situa= +tion"?</div><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)">There's a potential mild bytes savings, but t= +he bigger deal is that the API should be much less vulnerable to pinning is= +sues, fix dust leakage for eltoo like protocols, and just generally allow p= +rotocol designs to be fully abstracted from paying fees. You can't easi= +ly mathematically quantify=C2=A0API improvements=C2=A0like that.</div><div>= +<div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jere= +myRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/J= +eremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div clas= +s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 202= +2 at 8:13 AM Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" tar= +get=3D"_blank">billy.tetrud@gmail.com</a>> wrote:<br></div><blockquote c= +lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= +x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1= +ex"><div dir=3D"ltr"><div>Do you have any back-of-the-napkin math on quanti= +fying=C2=A0how much this would improve the situation vs existing methods (e= +g cpfp)?</div><div><br></div><div><span style=3D"color:rgb(0,0,0);font-fami= +ly:arial,helvetica,sans-serif"></span></div><div><span style=3D"color:rgb(0= +,0,0);font-family:arial,helvetica,sans-serif"><br></span></div></div><br><d= +iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan = +1, 2022 at 2:04 PM Jeremy via bitcoin-dev <<a href=3D"mailto:bitcoin-dev= +@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda= +tion.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= +"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor= +der-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)">Happy new years devs,</div><div class=3D"gmail_= +default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= +lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I figured I w= +ould share some thoughts for conceptual review that have been bouncing arou= +nd my head as an opportunity to clean up the fee paying semantics in bitcoi= +n "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 sur= +e could be improved greatly.</div><div class=3D"gmail_default" style=3D"fon= +t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br><= +/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans= +-serif;font-size:small;color:rgb(0,0,0)">Transaction fees are an integral p= +art of bitcoin.</div><div class=3D"gmail_default" style=3D"font-family:aria= +l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)">However, due to quirks of Bitcoin's transac= +tion design, fees are a part of the transactions that they occur in.</div><= +div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= +;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)">While this works in a "Bitcoin 1.0" world, where all transa= +ctions are simple on-chain transfers, real world use of Bitcoin requires su= +pport for things like Fee Bumping stuck transactions, DoS resistant Payment= + Channels, and other long lived Smart Contracts that can't predict futu= +re fee rates. Having the fees paid in band makes writing these contracts mu= +ch more difficult as you can't merely express the logic you want for th= +e transaction, but also the fees.</div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)">Previously, I proposed a sp= +ecial type of transaction called a "Sponsor" which has some speci= +al consensus=C2=A0+ mempool rules to allow arbitrarily appending fees to a = +transaction to bump it up in the mempool.</div><div class=3D"gmail_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,h= +elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">As an alternative, we= + could establish an account system in Bitcoin as an "extension block&q= +uot;.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic= +a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmai= +l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;= +color:rgb(0,0,0)"><b>Here's how it might work:</b></div><div class=3D"g= +mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma= +ll;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-f= +amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1. Defin= +e 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 associate= +d with them, but are overall anyone can spend.</div><div class=3D"gmail_def= +ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color= +:rgb(0,0,0)">2. All deposits to these outputs get stored in a separate UTXO= + database for fee accounts</div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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</div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)">4. These transactions are committed in an e= +xtension 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 me= +ssage=C2=A0+ signature.</div><div class=3D"gmail_default" style=3D"font-fam= +ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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 *an= +d paid back* into the requested withdrawal key (encumbering a 100 block tim= +eout). Signatures must be unique in a block.</div><div class=3D"gmail_defau= +lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= +gb(0,0,0)">6. Mempool logic is updated to allow attaching of account fee sp= +ends to transactions, the mempool can restrict that an account is not allow= +ed more spend more than it's balance.</div><div class=3D"gmail_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,h= +elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>But aren't acc= +ounts "bad"?</b></div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)">Yes, accounts are bad. But these acc= +ounts are not bad, because any funds withdrawn from the fee extension are f= +undamentally 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.</div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)"><b>Improving the privacy of this design:</b></div><div c= +lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font= +-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +">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.</div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di= +v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= +ont-size:small;color:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"font-family:ar= +ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c= +lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font= +-size:small;color:rgb(0,0,0)">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).</div><div class=3D"gmail_default" style=3D"font-family:a= +rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)"><b>Scalability</b></div><div class=3D"gmail_= +default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= +lor:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" style=3D"font= +-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Paying someone= + else to pay for you via the LN also helps make this more efficient if the = +withdrawal issues can be fixed.</div><div class=3D"gmail_default" style=3D"= +font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b= +r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s= +ans-serif;font-size:small;color:rgb(0,0,0)"><b>Lightning:</b></div><div cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)">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.</div= +><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(= +0,0,0)"><b>Without a fork?</b></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br= +></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa= +ns-serif;font-size:small;color:rgb(0,0,0)">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.</div><div cl= +ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-= +size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,sans-serif;font-size:small;color:rgb(0,0,0)">Happy new year!!</div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +">Jeremy</div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"ltr">--<b= +r><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubi= +n</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></di= +v></div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> +</blockquote></div> +</blockquote></div> + +--000000000000e94b0105d5e6774e-- + |