path: root/7a/755c880de0783d7e5b540133bba7b28c64f87d

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 135B5C002F;
 Wed, 19 Jan 2022 16:52:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id EE8B8607F0;
 Wed, 19 Jan 2022 16:52:09 +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 9ig1Jsz4Pu3w; Wed, 19 Jan 2022 16:52:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 82A7A607EC;
 Wed, 19 Jan 2022 16:52:07 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id u18so891208edt.6;
 Wed, 19 Jan 2022 08:52:07 -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=IusVIW61tTGUB/DUCECozLE34mOnlyKAC0GrGZwwjwU=;
 b=NTwFidT6RYI3PQMD4P/OUYidwUiT6ktDefCRgrjWEW2RoV5zpvm1OSkxPY9ngjkVTv
 s+F69IiJKOj/lis2mluAWfjiTlppAnAiLtcM3Z2aPCxIskn+DvWNJWQYX4oANIOUY27M
 yyIiEG62vdi9+4wLza1PdUJIZet3di4m1bpO0THK+Q4rzfxPsf5ruEnh6K6xULApsyu/
 YN5ljXo0O5cI74SNgq+CA0weBdhLrc/Lpd/9k3y1CNHIzYbiiTc7MXpUNKyEaM7apsfG
 pIZfwsFe5R5JXmGY1YPcH2iNWYxSGBwdrXQMa2FaziywikcfCL53E46S0FNMGFPeOZUW
 GhvA==
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=IusVIW61tTGUB/DUCECozLE34mOnlyKAC0GrGZwwjwU=;
 b=XYWJz1auIA1irgO2CPHrIwoMJKVS40JQoV7f5fWIHhE7s3Fl6fOq24dLf3AAw3q+4w
 nhcDYyj/UAIhCQBg0GzsRl3YZh6fW+i+4bGqFK+G84FH24qLsvDe9dnzDzazowAyuMRd
 gbqm2G6uEXIzaiES6jyVauIi2pLVAedxaTJLcQyaXkrm0JCy56kYMVOD22Syy0zyCypp
 5zEhxrDDEReoqXDgK1moljLfmsszF9NWTy2HGPx2qZxiwepHgBK42DRlIY60G/wq9yv0
 vsFyu9pRL9pXoy82PSeZSMPSe2ZySiVJ9aE335b1ZIZS2lHVTIxqOo3JYoHececFJe7y
 7eyw==
X-Gm-Message-State: AOAM5332nXJzwVjKMs4l6GspZKqKe9ujMINzv2JoTVpURqJC2fFWuxNT
 q3yhARUvj/9AAPzKVcL1da9fBEnC0bUr1168SMHuOVmcXeI=
X-Google-Smtp-Source: ABdhPJyVLzEcG4ggiFRrzQJEqAzJwE+QJyE53CeZ50timc1o3JIEaH4n2FIj2h1VPSDD8q2BRexqs5vAn+w+PYdG6hc=
X-Received: by 2002:a17:906:2bcf:: with SMTP id
 n15mr24201694ejg.184.1642611125426; 
 Wed, 19 Jan 2022 08:52:05 -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>
In-Reply-To: <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 19 Jan 2022 10:51:48 -0600
Message-ID: <CAGpPWDbPptac9UPM45_eWnmgDgeoyc=KxuQs1x7_vk37uarsLA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000a2a30405d5f23406"
X-Mailman-Approved-At: Wed, 19 Jan 2022 17:04:01 +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 16:52:10 -0000

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

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
>>>>>>>
>>>>>>

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

<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">pushin=
g 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 Jeremy &lt;<a href=3D"=
mailto:jlrubin@mit.edu">jlrubin@mit.edu</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 class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif;colo=
r:rgb(34,34,34)">Ah my bad i misread what you were saying as being about SI=
GHASH_BUNDLE like proposals.</span></div><div class=3D"gmail_default" style=
=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">F=
or what you&#39;re discussing, I previously proposed=C2=A0<a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.htm=
l" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2020-September/018168.html</a> which is similar.</div><div class=3D"gmail=
_default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">The benefit of the OP_VER output is that SIGHASH_=
EXTERNAL has the issue that unless you&#39;re binding a WTXID (which is may=
be too specific?) then you can have fee bumping cycles. Doing OP_VER output=
 w/ TXID guarantees that you are acyclic.</div><div class=3D"gmail_default"=
 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 bas=
ically boils down to the impact on e.g. reorg stability, where the deposit/=
withdraw mechanism is a bit more &quot;robust&quot; for reorderings in reor=
gs than the in-band transaction approach, although they are very similar.</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"><span style=3D"font-family:Arial,He=
lvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif;col=
or: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">@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" clas=
s=3D"gmail_attr">On Tue, Jan 18, 2022 at 8:53 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:1px solid 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:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The i=
ssue with sighash flags is that because you make transactions third party m=
alleable it becomes possible to bundle and unbundle transactions.</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=
)">This means there are circumstances where an attacker could e.g. see your=
 txn, and then add a lot of junk change/inputs=C2=A0+ 25 descendants and st=
rongly anchor your transaction to the bottom of the mempool.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze: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)">be=
cause of rbf rules requiring more fee and feerate, this means you have to b=
ump 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-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)">mor=
e generally speaking, you could imagine 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-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)">sup=
pose 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 t=
o be standard it must be &lt; 100k bytes and for it to be consensus &lt; 1m=
b. Now it is possible you have to solve a knapsack problem in order to rati=
onally bundle this transaction out of all possibilities.</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 p=
roblem can get even thornier, suppose that the inputs I&#39;m adding themse=
lves 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 a=
ll these dependencies.</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)">perhaps with very careful engineering th=
ese 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 s=
implify it to something like: compute effective feerate for a txn, includin=
g all sponsors that pay more than the feerate of the base txn. Mine that tx=
n and it&#39;s subsidies using the normal algo. If you run out of space, al=
l subsidies are same-sized so just take the ones that pay the highest amoun=
t up until the added marginal feerate 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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud &lt;<a href=3D"mailto=
:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">I see, its not primarily to make it cheaper to append fees, but al=
so allows appending fees in cases that aren&#39;t possible now. Is that rig=
ht? I can certainly see the benefit of a more general way to add a fee to a=
ny transaction, regardless of whether you&#39;re related to that transactio=
n 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? Eg a s=
ighash flag that says &quot;I&#39;m signing this transaction, but the signa=
ture is only valid if mined in the same block as transaction=C2=A0X (or may=
be transactions LIST)&quot;. This could be named SIGHASH_EXTERNAL. Doing th=
is would be a lot more similar to other bitcoin transactions, and no specia=
l 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 arbit=
rarily bump fees. Have you compared your solution to something more familia=
r like that?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Jan 18, 2022 at 11:43 AM Jeremy &lt;<a href=3D"ma=
ilto: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;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Can you clarify what you mean by &quot;imp=
rove the situation&quot;?</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)">There&#39;s a potential mild bytes sa=
vings, but the bigger deal is that the API should be much less vulnerable t=
o pinning issues, fix dust leakage for eltoo like protocols, and just gener=
ally allow protocol designs to be fully abstracted from paying fees. You ca=
n&#39;t easily mathematically quantify=C2=A0API improvements=C2=A0like that=
.</div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://t=
witter.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:13 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gm=
ail.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-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Do y=
ou 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,helvetica,sans-serif"=
></span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"><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-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-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;fon=
t-size:small;color:rgb(0,0,0)">Happy new years devs,</div><div class=3D"gma=
il_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-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I figured =
I would share some thoughts for conceptual review that have been bouncing a=
round my head as an opportunity to clean up the fee paying semantics in bit=
coin &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 =
sure could be improved greatly.</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)">Transaction fees are an integra=
l part of bitcoin.</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)">However, due to quirks of Bitcoin&#39;s tran=
saction design, fees are a part of the transactions that they occur in.</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)">While this works in a &quot;Bitcoin 1.0&quot; world, where all tra=
nsactions are simple on-chain transfers, real world use of Bitcoin requires=
 support for things like Fee Bumping stuck transactions, DoS resistant Paym=
ent Channels, and other long lived Smart Contracts that can&#39;t predict f=
uture 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 transaction, but also the fees.</div><div class=3D"gmail_default" styl=
e=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,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Previously, I proposed a s=
pecial type of transaction called a &quot;Sponsor&quot; which has some spec=
ial 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,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">As an alternative, w=
e could establish an account system in Bitcoin as an &quot;extension block&=
quot;.</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>Here&#39;s how it might work:</b></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;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)">1. Defi=
ne 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 associat=
ed with them, but are overall anyone can spend.</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">2. All deposits to these outputs get stored in a separate UTX=
O 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 TXI=
D (or Outpoint?); B: a withdraw amount, a fee, and an=C2=A0address</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;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=
 transaction. The public key for account lookup can be recovered from the m=
essage=C2=A0+ signature.</div><div class=3D"gmail_default" style=3D"font-fa=
mily: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 *a=
nd paid back* into the requested withdrawal key (encumbering a 100 block ti=
meout). Signatures must be unique in a block.</div><div class=3D"gmail_defa=
ult" style=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 s=
pends to transactions, the mempool can restrict that an account is not allo=
wed 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,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>But aren&#39;t ac=
counts &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><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">Yes, accounts are bad. But these ac=
counts are not bad, because any funds withdrawn from the fee extension are =
fundamentally locked for 100 blocks as a coinbase output, so there should b=
e no issues with any series of reorgs. Further, since there is no &quot;ric=
h state&quot; for these accounts, the state updates can always be applied i=
n 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>
</blockquote></div>
</blockquote></div>
</blockquote></div>

--000000000000a2a30405d5f23406--