path: root/a5/de0bb950f97150a9fb7eb482acfbdf49ce3321

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 306EDC002F;
 Wed, 19 Jan 2022 20:08:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 1786140947;
 Wed, 19 Jan 2022 20:08:41 +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 IEydCMT4DPvM; Wed, 19 Jan 2022 20:08:39 +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 9979A40896;
 Wed, 19 Jan 2022 20:08:38 +0000 (UTC)
Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com
 [209.85.167.54]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20JK8Zs8003431
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Wed, 19 Jan 2022 15:08:36 -0500
Received: by mail-lf1-f54.google.com with SMTP id x22so12661668lfd.10;
 Wed, 19 Jan 2022 12:08:36 -0800 (PST)
X-Gm-Message-State: AOAM532B/AjvfLvsuqsrTjDeX7EOd9j2Lk2M5M84MH0dgS1BdBjlx0Px
 I7KYlAY5WEqthnQjJXKG/8/pfhEgWJLDAN0vqrQ=
X-Google-Smtp-Source: ABdhPJzrnSM3hvpWnPYv2Z7DAij3dnIlSHl2Cp1Yw7ZJ8TxEfzg2gXVzqh7eHGSvZ8Qx5hBM+BFgs0QnvS8glZnuHk0=
X-Received: by 2002:a05:6512:33ce:: with SMTP id
 d14mr26836459lfg.516.1642622914877; 
 Wed, 19 Jan 2022 12:08:34 -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>
 <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
 <CAGpPWDbPptac9UPM45_eWnmgDgeoyc=KxuQs1x7_vk37uarsLA@mail.gmail.com>
In-Reply-To: <CAGpPWDbPptac9UPM45_eWnmgDgeoyc=KxuQs1x7_vk37uarsLA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 19 Jan 2022 12:08:23 -0800
X-Gmail-Original-Message-ID: <CAD5xwhgtpQNZbk1VfWs+P51FOYR4ibgucVBWVt_Z++vLwN7Fdw@mail.gmail.com>
Message-ID: <CAD5xwhgtpQNZbk1VfWs+P51FOYR4ibgucVBWVt_Z++vLwN7Fdw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000575dd205d5f4f313"
X-Mailman-Approved-At: Wed, 19 Jan 2022 20:12:17 +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 20:08:41 -0000

--000000000000575dd205d5f4f313
Content-Type: text/plain; charset="UTF-8"

SIGHASH_BUNDLE
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html

By cycles I meant that if you commit to the sponsors by TXID from the
witness, you could "sponsor yourself" directly or through a cycle involving
> 1 txn.

With OP_VER I was talking about the proposal I linked here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
in the output space, and uses TXIDs, it is cycle-free.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> Hmm, I don't know anything about  SIGHASH_BUNDLE. The only references
> online I can find are just mentions (mostly from you). What is
> SIGHASH_BUNDLE?
>
> > unless you're binding a WTXID
>
> That could work, but it would exclude cases where you have a transaction
> that has already been partially signed and someone wants to, say, only sign
> that transaction if some 3rd party signs a transaction paying part of the
> fee for it. Kind of a niche use case, but it would be nice to support it if
> possible. If the transaction hasn't been signed at all yet, a new
> transaction can just be created that includes the prospective fee-payer,
> and if the transaction is fully signed then it has a WTXID to use.
>
> > then you can have fee bumping cycles
>
> What kind of cycles do you mean? You're saying these cycles would make it
> less robust to reorgs?
>
> > OP_VER
>
> I assume you mean something other than pushing the version onto the stack
> <https://bitcoin.stackexchange.com/questions/97258/given-op-ver-was-never-used-is-disabled-and-not-considered-useful-can-its-meani>?
> Is that related to your fee account idea?
>
>
> On Wed, Jan 19, 2022 at 1:32 AM Jeremy <jlrubin@mit.edu> wrote:
>
>> 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
>>>>>>>>
>>>>>>>

--000000000000575dd205d5f4f313
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">SIGHASH_BUNDLE=C2=A0<a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/01=
5862.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Apr=
il/015862.html</a></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">By cycles I meant that if you commit to the sponso=
rs by TXID from the witness, you could &quot;sponsor yourself&quot; directl=
y or through a cycle involving &gt; 1 txn.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">With OP_VER I was talking =
about the proposal I linked here=C2=A0<a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2020-September/018168.html">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html</a> which=
 used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is in the=
 output space, and uses TXIDs, it is cycle-free.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div><div =
dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><d=
iv 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></div><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 19, 2022 at 8:52 AM Billy=
 Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.co=
m</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-lef=
t-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hmm, I don&#39;=
t know anything about=C2=A0

SIGHASH_BUNDLE. The only references online I can find are just mentions (mo=
stly from you). What is=C2=A0

SIGHASH_BUNDLE?<div><br></div><div>&gt; unless you&#39;re binding a WTXID</=
div><div><br></div><div>That could work, but it would exclude cases where y=
ou have a transaction that has already been partially signed and someone wa=
nts to, say, only sign that transaction if some 3rd party signs a transacti=
on paying part of the fee for it. Kind of a niche use case, but it would be=
 nice to support it if possible. If the transaction hasn&#39;t been signed =
at all yet, a new transaction can just be created that includes the prospec=
tive fee-payer, and if the transaction is fully signed then it has a WTXID =
to use.</div><div><br></div><div>&gt; then you can have fee bumping cycles<=
/div><div><br></div><div>What kind of cycles do you mean? You&#39;re saying=
 these cycles would make it less robust to reorgs?</div><div><br></div><div=
>&gt; OP_VER</div><div><br></div><div>I assume you mean something other tha=
n <a href=3D"https://bitcoin.stackexchange.com/questions/97258/given-op-ver=
-was-never-used-is-disabled-and-not-considered-useful-can-its-meani" target=
=3D"_blank">pushing the version onto the stack</a>? Is that related to your=
 fee account idea?</div><div><br></div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 19, 2022 at 1:32 AM Jere=
my &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"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif;c=
olor: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" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,=
34)"><br></span></div><div class=3D"gmail_default" style=3D"font-size:small=
">For what you&#39;re discussing, I previously proposed=C2=A0<a href=3D"htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.=
html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2020-September/018168.html</a> which is similar.</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 benefit of the OP_VER output is that SIGHA=
SH_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 OP_VER out=
put w/ TXID guarantees that you are acyclic.</div><div class=3D"gmail_defau=
lt" style=3D"font-size:small"><br></div><div class=3D"gmail_default" 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 depo=
sit/withdraw mechanism is a bit more &quot;robust&quot; for reorderings in =
reorgs than the in-band transaction approach, although they are very simila=
r.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><span style=3D"font-family:Aria=
l,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif=
;color:rgb(34,34,34)">--</span><br></div><div><div dir=3D"ltr"><div dir=3D"=
ltr"><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyR=
ubin</a><a href=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"gmail_attr">On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud &lt;<a hr=
ef=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-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>
</blockquote></div>
</blockquote></div>

--000000000000575dd205d5f4f313--