path: root/69/ed081825cdd5479457b903ad1130ecd4970e56

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 353BDC002F;
 Wed, 19 Jan 2022 02:37:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 113DC60E3F;
 Wed, 19 Jan 2022 02:37:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bWEp2hNOLduu; Wed, 19 Jan 2022 02:37:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4801160E3A;
 Wed, 19 Jan 2022 02:37:57 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id m11so4046511edi.13;
 Tue, 18 Jan 2022 18:37:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=dHX3KlIuWryBubUeivv/v+a5oWhNrsvqEalU3kp6+KQ=;
 b=EZNKxPQ617XJvMmRXU/H+CPTCCCcPVHLDQmIecxIU1M4XeAbEoSgb2xeJSYIk7hSim
 aecq1uTzlH/BX3LrG3YnLARmXNW2SBSH0K+vWy+KNBNWJtNKyoBqqCjoJGtTo1hde7tK
 gOA9e6CVqERsGd1y6sGHttOqw4e1buDg9TRUIgXPHuZjf0mvSgB/hEFBI1gqxYqPp9AM
 gt6KRNisGAnX1436kHIP9vKjxOD5op+5J0Ejb40wNYZgJaNNcSgGbfL99UW/9665bXs2
 PurW8VE3Xy9GEf/QAx+bWHNsrowGh2uHVMKF6QeuVZwGwREgJoZRPALdjE/alYqdm6NL
 lN7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=dHX3KlIuWryBubUeivv/v+a5oWhNrsvqEalU3kp6+KQ=;
 b=QV9JsDf1VRcrQB45R/+ykDAntUB8bRN0pYzIcWEGUUsvtzt0ftJicfN4tJkAE55Efm
 0qXpEc8igGQRIKi8bv+rQt58N/EzAcW7eqpd4X1+cScYKc4OV1dcOgxYanPFZoB+5AgH
 XUPzbrC1kU7kPJsZxEZRh7truLkAX3/fzAImrgGA/F7Mj83qeEBPteRnKBy0J521xMNl
 /voAYzQWHtiMNYSgwljm5eI9TYVk952rLOLmZosfJb20dMUV05OJ82BSJi27ChGfz+ad
 xhMEPLKt4aUMG6Jz+V2k0/6P6Ec1phc9SD8u3h8MpOEwfdSJK8ysNddOCjnP4wibHhwC
 Um7A==
X-Gm-Message-State: AOAM533y+aV0ttKZQo+nMHRo+FuQGS8bvoZrnwh3aTbD07i50gpI6CxX
 pZWOb9E1Qfta+G9NfPPymXs3miweZRjtupARq0WGbMeQzTY=
X-Google-Smtp-Source: ABdhPJwaVx65RD8JMVXtYUOp2acn8RIZ/MNAzxw0zHjTE8cgoRdNL7CY5z13AqH/iSZCY9U77RBfvLCGryzNMEZ2fUA=
X-Received: by 2002:a17:906:2bcf:: with SMTP id
 n15mr21861025ejg.184.1642559875464; 
 Tue, 18 Jan 2022 18:37:55 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com>
 <CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com>
In-Reply-To: <CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 20:37:39 -0600
Message-ID: <CAGpPWDaQAxEfyFs_g9p=PTUNAkSiQKwPiHJbBaLmzfNTjFeucA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000e6444205d5e645c2"
X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:26 +0000
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:37:59 -0000

--000000000000e6444205d5e645c2
Content-Type: text/plain; charset="UTF-8"

I see, its not primarily to make it cheaper to append fees, but also allows
appending fees in cases that aren't possible now. Is that right? I can
certainly see the benefit of a more general way to add a fee to any
transaction, regardless of whether you're related to that transaction or
not.

How would you compare the pros and cons of your account-based approach to
something like a new sighash flag? Eg a sighash flag that says "I'm signing
this transaction, but the signature is only valid if mined in the same
block as transaction X (or maybe transactions LIST)". This could be named
SIGHASH_EXTERNAL. Doing this would be a lot more similar to other bitcoin
transactions, and no special account would need to be created. Any
transaction could specify this. At least that's the first thought I would
have in designing a way to arbitrarily bump fees. Have you compared your
solution to something more familiar like that?

On Tue, Jan 18, 2022 at 11:43 AM Jeremy <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
>>>
>>

--000000000000e6444205d5e645c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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 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&#39;re related to that tr=
ansaction or not.=C2=A0<div><br></div><div>How would you compare the pros a=
nd cons of your account-based approach to something like a new sighash flag=
? Eg a sighash flag that says &quot;I&#39;m signing this transaction, but t=
he signature is only valid if mined in the same block as transaction=C2=A0X=
 (or maybe transactions LIST)&quot;. This could be named SIGHASH_EXTERNAL. =
Doing this would be a lot more similar to other bitcoin transactions, and n=
o special account would need to be created. Any transaction could specify t=
his. At least that&#39;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?</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 hr=
ef=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">Can you clarify what you mean by &quot;improve the s=
ituation&quot;?</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)">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 ea=
sily mathematically quantify=C2=A0API improvements=C2=A0like that.</div><di=
v><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Je=
remyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com=
/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 2=
022 at 8:13 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" t=
arget=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:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Do you have an=
y back-of-the-napkin math on quantifying=C2=A0how much this would improve t=
he situation vs existing methods (eg cpfp)?</div><div><br></div><div><span =
style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></span></=
div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-s=
erif"><br></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;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,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I figured I would sh=
are some thoughts for conceptual review that have been bouncing around my h=
ead as an opportunity to clean up the fee paying semantics in bitcoin &quot=
;for good&quot;. The design space is very wide on the approach I&#39;ll sha=
re, so below is just a sketch of how it could work which I&#39;m sure could=
 be improved greatly.</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)">Transaction fees are an integral part of =
bitcoin.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">However, due to quirks of Bitcoin&#39;s transaction de=
sign, fees are a part of the transactions that they occur in.</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize: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)">W=
hile this works in a &quot;Bitcoin 1.0&quot; world, where all transactions =
are simple on-chain transfers, real world use of Bitcoin requires support f=
or things like Fee Bumping stuck transactions, DoS resistant Payment Channe=
ls, and other long lived Smart Contracts that can&#39;t predict future fee =
rates. Having the fees paid in band makes writing these contracts much more=
 difficult as you can&#39;t merely express the logic you want for the trans=
action, 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></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">Previously, I proposed a special typ=
e of transaction called a &quot;Sponsor&quot; which has some special consen=
sus=C2=A0+ mempool rules to allow arbitrarily appending fees to a transacti=
on to bump it up in the mempool.</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)">As an alternative, we could es=
tablish an account system in Bitcoin as an &quot;extension block&quot;.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;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>Here&#39;s how it might work:</b></div><div class=3D"gmail_defa=
ult" 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:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1. Define a speci=
al anyone can spend output type that is a &quot;fee account&quot; (e.g. seg=
wit V2). Such outputs have a redeeming key and an amount associated with th=
em, but are overall anyone can spend.</div><div class=3D"gmail_default" sty=
le=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:ar=
ial,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 Outp=
oint?); 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:s=
mall;color: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 committed data need only cover the index in the block of the transacti=
on. The public key for account lookup can be recovered from the message=C2=
=A0+ signature.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5. In any block, a=
ny of the fee account deposits can be: released into fees if there is a cor=
responding tx; consolidated together to reduce the number of utxos (this ca=
n be just an OP_TRUE no metadata needed); or released into fees *and paid b=
ack* into the requested withdrawal key (encumbering a 100 block timeout). S=
ignatures must be unique in a block.</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">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&#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,helveti=
ca,sans-serif;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,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)">Yes, accounts are bad. But these accounts =
are not bad, because any funds withdrawn from the fee extension are fundame=
ntally locked for 100 blocks as a coinbase output, so there should be no is=
sues with any series of reorgs. Further, since there is no &quot;rich state=
&quot; for these accounts, the state updates can always be applied in a con=
flict-free way in any order.</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)"><br></div><div class=3D"gmail_defa=
ult" 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 class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;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 d=
esign could likely be modified to implement something like Tornado.cash or =
something else so that the fee account paying can be unlinked from the tran=
saction being paid for, improving privacy at the expense of being a bit mor=
e expensive.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,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)">Other operations could be added to allow a trustl=
ess mixing to be done by miners automatically where groups of accounts with=
 similar values are trustlessly =C2=A0split into a common denominator and c=
hange, and keys are derived via a verifiable stealth address like protocol =
(so fee balances can be discovered by tracing the updates posted). These up=
dates could also be produced by individuals rather than miners, and miners =
could simply honor them with better privacy. While a miner generating an up=
date would be able to deanonymize their mixes, if you have your account mix=
ed several times by independent miners that could potentially add sufficien=
t privacy.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,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:s=
mall;color:rgb(0,0,0)">The LN can also be used with PTLCs to, in theory, ha=
ve another individual paid to sponsor a transaction on your behalf only if =
they reveal a valid sig from their fee paying account, although under this =
model it&#39;s hard to ensure that the owner doesn&#39;t pay a fee and then=
 &#39;cancel&#39; by withdrawing the rest. However, this could be partly so=
lved by using reputable fee accounts (reputation could be measured somewhat=
 decentralized-ly by longevity of the account and transactions paid for his=
torically).</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)"><b>Scalability</b></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This design=
 is fundamentally &#39;decent&#39; 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.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(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 withd=
rawal 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)"><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>Lightning:</b></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;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 type of design works really well for channels because the addition o=
f fees to e.g. a channel state does not require any sort of pre-planning (e=
.g. anchors) or transaction flexibility (SIGHASH flags). This sort of desig=
n is naturally immune to pinning issues since you could offer to pay a fee =
for any TXID and the number of fee adding offers does not need to be restri=
cted in the same way the descendant transactions would need to be.</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=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"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)">This type of design could be done as=
 a federated network that bribes miners -- potentially even retroactively a=
fter a block is formed. That might be sufficient to prove the concept works=
 before a consensus upgrade is deployed, but such an approach does mean the=
re is a centralizing layer interfering with normal mining.</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)"><br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-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;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)">Jer=
emy</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></d=
iv></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>

--000000000000e6444205d5e645c2--