path: root/75/b6dd90bad21f3763b5eaeea13c3f2653065ab1

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 &lt; 100k bytes and=
 for it to be consensus &lt; 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&#39;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&#39;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 &lt;<a href=3D"mailto:bi=
lly.tetrud@gmail.com">billy.tetrud@gmail.com</a>&gt; 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&#39;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&#39;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 &quot;I&#39;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)&quot;. 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&#39;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 &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: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 &quot;improve the situa=
tion&quot;?</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&#39;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&#39;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 &lt;<a href=3D"mailto:billy.tetrud@gmail.com" tar=
get=3D"_blank">billy.tetrud@gmail.com</a>&gt; 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 &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.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;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 &quot;for good&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 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&#39;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 &quot;Bitcoin 1.0&quot; 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&#39;t predict futu=
re fee rates. Having the fees paid in band makes writing these contracts mu=
ch more difficult as you can&#39;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 &quot;Sponsor&quot; 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 &quot;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&#39;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 &quot;fee account&quot; =
(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&#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></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&#39;t acc=
ounts &quot;bad&quot;?</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 &quot;rich=
 state&quot; 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&#39;s hard to ensure that the owner doesn&#39;t pay a fee a=
nd then &#39;cancel&#39; 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 &#39;decent&#39; 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--