path: root/ea/abdbddc6f6958a8b03abd033df947039679d62

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6CD24C002F;
 Wed, 19 Jan 2022 07:32:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3CF098199D;
 Wed, 19 Jan 2022 07:32:54 +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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 78eMxSWm9oVj; Wed, 19 Jan 2022 07:32:52 +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 smtp1.osuosl.org (Postfix) with ESMTPS id AA7F48161D;
 Wed, 19 Jan 2022 07:32:51 +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 20J7Wmwq003089
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Wed, 19 Jan 2022 02:32:49 -0500
Received: by mail-lf1-f47.google.com with SMTP id br17so5723139lfb.6;
 Tue, 18 Jan 2022 23:32:49 -0800 (PST)
X-Gm-Message-State: AOAM531DZA2JYI15l2cAIdaXCemMAHJlDgEJVE5JOS6kNboCIrvKQAhD
 kY6xcA0yPQt+f2mHUwh1BkBpuGU4Qn55ZnHfYU4=
X-Google-Smtp-Source: ABdhPJwsUnJOs0PQL1xxnkzKyBeXxl+nSuaBSWR1tB+H2SoI6vpi5Oekx846Bg6ZmYD3BxxUQSEDsrZw2eEcS2o7YIw=
X-Received: by 2002:a05:651c:904:: with SMTP id
 e4mr23696564ljq.198.1642577567773; 
 Tue, 18 Jan 2022 23:32:47 -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>
 <CAD5xwhjUkey+VD=u+69+5eirLCCoLgDgAR_4d20hwHo-eyZr6w@mail.gmail.com>
 <CAGpPWDYxCGkpbiiHFgFrY3=oCwRBY7c_vLQfQg3a_Dwx7pEUTA@mail.gmail.com>
In-Reply-To: <CAGpPWDYxCGkpbiiHFgFrY3=oCwRBY7c_vLQfQg3a_Dwx7pEUTA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 18 Jan 2022 23:32:36 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
Message-ID: <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007179f805d5ea64ed"
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 07:32:54 -0000

--0000000000007179f805d5ea64ed
Content-Type: text/plain; charset="UTF-8"

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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <billy.tetrud@gmail.com> 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 <jlrubin@mit.edu> 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 <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
>>>>>>
>>>>>

--0000000000007179f805d5ea64ed
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"><span style=3D"font-famil=
y:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">Ah my bad i misread what =
you were saying as being about SIGHASH_BUNDLE like proposals.</span></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000"><span style=3D"font-family:Arial,Helvetica,=
sans-serif;color:rgb(34,34,34)"><br></span></div><div class=3D"gmail_defaul=
t" style=3D"font-size:small">For what you&#39;re discussing, I previously p=
roposed=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2020-September/018168.html">https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2020-September/018168.html</a> which is similar.</div><div cl=
ass=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gma=
il_default" style=3D"font-size:small">The benefit of the OP_VER output is t=
hat SIGHASH_EXTERNAL has the issue that unless you&#39;re binding a WTXID (=
which is maybe too specific?) then you can have fee bumping cycles. Doing O=
P_VER output w/ TXID guarantees that you are acyclic.</div><div class=3D"gm=
ail_default" style=3D"font-size:small"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-size:small">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 &quot;robust&quot; for reorder=
ings in reorgs than the in-band transaction approach, although they are ver=
y similar.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><span style=3D"font-family=
:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><span style=3D"font-family:Arial,Helvetica,sans-ser=
if;color:rgb(34,34,34)">--</span><br></div><div><div dir=3D"ltr" class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud &lt;<a href=3D"mailto=
:billy.tetrud@gmail.com">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">&gt;=C2=A0

<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">bec=
ause you make transactions third party malleable it becomes possible to bun=
dle and unbundle transactions.</span><div><span style=3D"color:rgb(0,0,0);f=
ont-family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">What I was sugges=
ting doesn&#39;t make it possible to malleate someone else&#39;s transactio=
n.=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,=
sans-serif">I guess maybe my proposal of using a sighash flag might have be=
en unclear. Imagine it as a script opcode that just says &quot;this transac=
tion=C2=A0must be mined with this other transaction&quot; - 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&#39;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&#39;t spend the parent.=C2=A0</span></div><div><span style=3D"c=
olor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><d=
iv><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">=
I don&#39;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&#39;d also exist for your proposal, or for cpfp. Let=
 me know if I should clarify further.=C2=A0</span></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 202=
2 at 8:51 PM Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank=
">jlrubin@mit.edu</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 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"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">The issue with sighash flags is that b=
ecause you make transactions third party malleable it becomes possible to b=
undle and unbundle transactions.</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,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)">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.</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,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">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.</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)">more generally speaking, you could i=
magine a future where mempools track many alternative things that might wan=
t to be in a transaction.</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">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 &lt; 100k=
 bytes and for it to be consensus &lt; 1mb. Now it is possible you have to =
solve a knapsack problem in order to rationally bundle this transaction out=
 of all possibilities.</div><div class=3D"gmail_default" style=3D"font-fami=
ly: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 problem can get even thornier, supp=
ose that the inputs I&#39;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.</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)=
">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&#39;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.</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,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><div di=
r=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin=
" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRu=
bin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 2022 at 6:=
38 PM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"=
_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">I see, its not primarily to make it cheaper to append fees, b=
ut also allows appending fees in cases that aren&#39;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&#39;re related to that trans=
action 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 sighash flag? E=
g a sighash flag that says &quot;I&#39;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)&quot;. 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&#39;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?</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 Jeremy &lt;<a href=
=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 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"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)">Can you clarify what you mean by &quot;improve the situation&quot;?</=
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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">There&#39;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&#39;t easily mathematical=
ly quantify=C2=A0API improvements=C2=A0like that.</div><div><div dir=3D"ltr=
"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=
=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" tar=
get=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 2022 at 8:13 AM Bi=
lly Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">=
billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-s=
tyle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>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><=
div><br></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"></span></div><div><span style=3D"color:rgb(0,0,0);font-fami=
ly:arial,helvetica,sans-serif"><br></span></div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 1, 2022 at 2:04=
 PM Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 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"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size: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;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)">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 &quot;for go=
od&quot;. The design space is very wide on the approach I&#39;ll share, so =
below is just a sketch of how it could work which I&#39;m sure could be imp=
roved greatly.</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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">Transaction fees are an integral part of bitcoin=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">However, due to quirks of Bitcoin&#39;s transaction design, f=
ees are a part of the transactions that they occur in.</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)">While th=
is works in a &quot;Bitcoin 1.0&quot; 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&#39;t predict future fee rates. =
Having the fees paid in band makes writing these contracts much more diffic=
ult as you can&#39;t merely express the logic you want for the 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,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">Previously, I proposed a special type of tr=
ansaction called a &quot;Sponsor&quot; which has some special 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></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">As an alternative, we could establis=
h an account system in Bitcoin as an &quot;extension block&quot;.</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><b>Here&#39;s how it might work:</b></div><div class=3D"gmail_default" s=
tyle=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,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">1. Define a special any=
one can spend output type that is a &quot;fee account&quot; (e.g. segwit V2=
). Such outputs have a redeeming key and an amount associated with them, bu=
t are overall anyone can spend.</div><div class=3D"gmail_default" 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 f=
ee accounts</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;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></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><b>But aren&#39;t accounts &quot;bad=
&quot;?</b></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)">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 &quot;rich state&quot; =
for these accounts, the state updates can always be applied in a conflict-f=
ree way in any order.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d=
iv 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" st=
yle=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 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)">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.</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)">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.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">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=
&#39;s hard to ensure that the owner doesn&#39;t pay a fee and then &#39;ca=
ncel&#39; 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).</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,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><b>Scalability</b></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color: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 design is funda=
mentally &#39;decent&#39; 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.</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)">Paying someone else to pay =
for you via the LN also helps make this more efficient if the withdrawal is=
sues can be fixed.</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>Lightning:</b></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or: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 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.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-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"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;fo=
nt-size:small;color:rgb(0,0,0)">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><div class=3D"gmai=
l_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-fami=
ly: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)">Happy new year!!</div><div class=3D"gmai=
l_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-fami=
ly: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">--<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></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>
</blockquote></div>
</blockquote></div>

--0000000000007179f805d5ea64ed--