path: root/41/b725d17f04c3621251d781af567411c66fdaa8

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8188CC002F;
 Tue, 18 Jan 2022 16:12:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5AD0C81AF5;
 Tue, 18 Jan 2022 16:12:58 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id UpzulxUMJBMM; Tue, 18 Jan 2022 16:12:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [IPv6:2a00:1450:4864:20::52c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B838381AC4;
 Tue, 18 Jan 2022 16:12:56 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id m11so5299090edi.13;
 Tue, 18 Jan 2022 08:12:56 -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=B/TgrxInF+5YQbcaOtIL0ToEg5UZXIJ8FpXqKZIXtrY=;
 b=No2to62gNosauyqu/J9Zdvkcv8gi/m9NykQa5mS9kM5swqynGxBkd1WQcPQe4XcUTX
 /v85zDnRACdL7+lw9AWKNRVNAt2NI24/GN9N7F6B6nqTMLF+MU+/u8RzYOwxDBgIx0Js
 BX1I6UXYJcYlSMQUDQU+YtHpJcNfwbJ91qdEX6Fxf9QgHyepp2ESDTIdlAk41An6gOfL
 qa5JvO1ZaLQWyX9hGKJ5Da17hH6lGeeJlf5bt87NNP8UFZMHaLgdRH9Wdzc38JvhbtBT
 XB2xRJvVzt+DTYkOZZQj6/sP6szpaqqifVTDlpwBTU3RD7zQuSpchFMCOIU8V7m/Z9/v
 VFuQ==
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=B/TgrxInF+5YQbcaOtIL0ToEg5UZXIJ8FpXqKZIXtrY=;
 b=J9MRSZcfv6NOW+Wp2b05cM+ZiTG3JWM80fzEC/RbxzZVoeg9rimk/ngf/XNWB6zjmc
 qr2pOdACH1qDo3cAuSCuCZedpFqU23Uz3vPlr9HX3aW1WIVh8WREg2DxF/ohEv4oELxd
 zRwLECqCDUfiaPpiQy+KfhtapyzQW+6XNOxGYaBqLgOwWjwvmEJJNg2TC3rIdBQxV6oN
 FC2e80sK7dGoAgTrAuT50SsQre1U9Aa5MIf1OtsqEInOnK+wNOmmGxLBni3S8fM32LBB
 uxM7ihp1gruSeKf4qOKnKFeEumS1JC8C2uBcG7UW1mdilICQ7+8SOp0TqYRQH7+Q1ivG
 vc9A==
X-Gm-Message-State: AOAM532w1mVsb15i6RVvTfPy5nFU/Wf+GLluTsXHDpZOAYoJDCanWTBi
 Zkcrko7/d1tBjDr8l78Rt6WO7rywYw4S2htXDPk=
X-Google-Smtp-Source: ABdhPJx2wbc3tfMeA+A0ARkbY08LvSYLOklIk4jpsmbBvstxl1LJDpv1r9XA3POuihB4m0PBubhwg1tZdn7ecBb1HvE=
X-Received: by 2002:a17:906:dc95:: with SMTP id
 cs21mr11838774ejc.709.1642522374715; 
 Tue, 18 Jan 2022 08:12:54 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
In-Reply-To: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 10:12:36 -0600
Message-ID: <CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ae41ba05d5dd8a8c"
X-Mailman-Approved-At: Tue, 18 Jan 2022 16:25:13 +0000
Cc: 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: Tue, 18 Jan 2022 16:12:58 -0000

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

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
>

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

<div dir=3D"ltr"><div>Do you have any back-of-the-napkin math on quantifyin=
g=C2=A0how much this would improve the situation vs existing methods (eg cp=
fp)?</div><div><br></div><div><span style=3D"color:rgb(0,0,0);font-family:a=
rial,helvetica,sans-serif"></span></div><div><span style=3D"color:rgb(0,0,0=
);font-family:arial,helvetica,sans-serif"><br></span></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 1, 2=
022 at 2:04 PM Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">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:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">Happy new years devs,</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)">I =
figured I would share some thoughts for conceptual review that have been bo=
uncing around my head as an opportunity to clean up the fee paying semantic=
s in bitcoin &quot;for good&quot;. The design space is very wide on the app=
roach 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" 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)">Transaction fees are an=
 integral part of bitcoin.</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)">However, due to quirks of Bitcoin&#3=
9;s transaction design, fees are a part of the transactions that they occur=
 in.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">While this works in a &quot;Bitcoin 1.0&quot; world, where=
 all transactions are simple on-chain transfers, real world use of Bitcoin =
requires support for things like Fee Bumping stuck transactions, DoS resist=
ant Payment Channels, and other long lived Smart Contracts that can&#39;t p=
redict future fee rates. Having the fees paid in band makes writing these c=
ontracts 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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Previously, I prop=
osed a special type of transaction called a &quot;Sponsor&quot; which has s=
ome special consensus=C2=A0+ mempool rules to allow arbitrarily appending f=
ees 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;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">As an altern=
ative, we could establish an account system in Bitcoin as an &quot;extensio=
n block&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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"><b>Here&#39;s how it might work:</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)=
">1. Define a special anyone can spend output type that is a &quot;fee acco=
unt&quot; (e.g. segwit V2). Such outputs have a redeeming key and an amount=
 associated with them, but are overall anyone can spend.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">2. All deposits to these outputs get stored in a sep=
arate UTXO database for fee accounts</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">3. Fee accounts can sign only two kinds of transaction: A: a fee amount =
and a TXID (or Outpoint?); B: a withdraw amount, a fee, and an=C2=A0address=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">4. These transactions are committ=
ed 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 blo=
ck of the transaction. The public key for account lookup can be recovered f=
rom the message=C2=A0+ signature.</div><div class=3D"gmail_default" style=
=3D"font-family: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 fe=
es if there is a corresponding tx; consolidated together to reduce the numb=
er of utxos (this can be just an OP_TRUE no metadata needed); or released i=
nto fees *and paid back* into the requested withdrawal key (encumbering a 1=
00 block timeout). Signatures must be unique in a block.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">6. Mempool logic is updated to allow attaching of ac=
count fee spends to transactions, the mempool can restrict that an account =
is not allowed more spend more than it&#39;s balance.</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>But ar=
en&#39;t accounts &quot;bad&quot;?</b></div><div class=3D"gmail_default" st=
yle=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,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)">Yes, accounts are bad. B=
ut these accounts are not bad, because any funds withdrawn from the fee ext=
ension are fundamentally locked for 100 blocks as a coinbase output, so the=
re should be no issues with any series of reorgs. Further, since there is n=
o &quot;rich state&quot; for these accounts, the state updates can always b=
e applied in a conflict-free way in any order.</div><div class=3D"gmail_def=
ault" 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: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)"><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;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">This design could likely be modified to implement something lik=
e Tornado.cash or something else so that the fee account paying can be unli=
nked 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"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)">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 =C2=A0split into a common =
denominator and change, and keys are derived via a verifiable stealth addre=
ss like protocol (so fee balances can be discovered by tracing the updates =
posted). These updates could also be produced by individuals rather than mi=
ners, 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 potentia=
lly add sufficient privacy.</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)">The LN can also be used with PTLCs =
to, in theory, have another individual paid to sponsor a transaction on you=
r behalf only if they reveal a valid sig from their fee paying account, alt=
hough under this model it&#39;s hard to ensure that the owner doesn&#39;t p=
ay a fee and then &#39;cancel&#39; by withdrawing the rest. However, this c=
ould be partly solved by using reputable fee accounts (reputation could be =
measured somewhat decentralized-ly by longevity of the account and transact=
ions paid for historically).</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)"><b>Scalability</b></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">This design is fundamentally &#39;decent&#39; for scalability because a=
dding fees to a transaction does not require adding inputs or outputs and d=
oes not require tracking substantial amounts of new state.</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)">Pay=
ing someone else to pay for you via the LN also helps make this more effici=
ent 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)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>Lightning:</b></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><br></b></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">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). Thi=
s sort of design is naturally immune to pinning issues since you could offe=
r to pay a fee for any TXID and the number of fee adding offers does not ne=
ed to be restricted in the same way the descendant transactions would need =
to be.</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>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,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This type of design c=
ould be done as a federated network that bribes miners -- potentially even =
retroactively after a block is formed. That might be sufficient to prove th=
e concept works before a consensus upgrade is deployed, but such an approac=
h does mean there is a centralizing layer interfering with normal mining.</=
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 class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,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;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)">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">@J=
eremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"=
></a></div></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>

--000000000000ae41ba05d5dd8a8c--