path: root/61/28b61ba844f9581e5c0fcea41aecc9d99f71ce

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AE9E7C002F;
 Tue, 18 Jan 2022 17:43:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8F3154028B;
 Tue, 18 Jan 2022 17:43:24 +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 0D7q26KEd1qt; Tue, 18 Jan 2022 17:43:23 +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 A80B34014A;
 Tue, 18 Jan 2022 17:43:22 +0000 (UTC)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com
 [209.85.167.46]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20IHhJmV030769
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Tue, 18 Jan 2022 12:43:20 -0500
Received: by mail-lf1-f46.google.com with SMTP id e3so71036222lfc.9;
 Tue, 18 Jan 2022 09:43:20 -0800 (PST)
X-Gm-Message-State: AOAM530H6LReg4IjUqFxiLx5mPPg402Z+B6eiJBueq0jr4kBAcJA2PDO
 Qu0JdreSYMcZOFhGc7ojGMFdZC41th+G+VAINo4=
X-Google-Smtp-Source: ABdhPJwEZo7F1jwdghkzQBsdTbKm24jdfvkwVcCVZQmCPzQEiHXO6hAiA+LfBR9IXCrFWdscdYaaeQTG/pFKLWfko78=
X-Received: by 2002:a2e:8e81:: with SMTP id z1mr20714143ljk.57.1642527798966; 
 Tue, 18 Jan 2022 09:43:18 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com>
In-Reply-To: <CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 18 Jan 2022 09:43:07 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com>
Message-ID: <CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fdc27a05d5decd9e"
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: Tue, 18 Jan 2022 17:43:24 -0000

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

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

--000000000000fdc27a05d5decd9e
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">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:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">There&#39;s a potential mi=
ld bytes savings, but the bigger deal is that the API should be much less v=
ulnerable to pinning issues, fix dust leakage for eltoo like protocols, and=
 just generally allow protocol designs to be fully abstracted from paying f=
ees. You can&#39;t easily mathematically quantify=C2=A0API improvements=C2=
=A0like that.</div><div><div dir=3D"ltr" class=3D"gmail_signature" data-sma=
rtmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitte=
r.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twi=
tter.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, J=
an 18, 2022 at 8:13 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmai=
l.com">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;border=
-left-style: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=
,helvetica,sans-serif"></span></div><div><span style=3D"color:rgb(0,0,0);fo=
nt-family:arial,helvetica,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.l=
inuxfoundation.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"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;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,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I figured I would sha=
re some thoughts for conceptual review that have been bouncing around my he=
ad as an opportunity to clean up the fee paying semantics in bitcoin &quot;=
for good&quot;. The design space is very wide on the approach I&#39;ll shar=
e, 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)"><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)">Transaction fees are an integral part of b=
itcoin.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">However, due to quirks of Bitcoin&#39;s transaction des=
ign, fees are a part of the transactions that they occur in.</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)">Wh=
ile this works in a &quot;Bitcoin 1.0&quot; world, where all transactions a=
re simple on-chain transfers, real world use of Bitcoin requires support fo=
r things like Fee Bumping stuck transactions, DoS resistant Payment Channel=
s, and other long lived Smart Contracts that can&#39;t predict future fee r=
ates. 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 transa=
ction, but also the fees.</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)">Previously, I proposed a special type=
 of transaction called a &quot;Sponsor&quot; which has some special consens=
us=C2=A0+ mempool rules to allow arbitrarily appending fees to a transactio=
n 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)"><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)">As an alternative, we could est=
ablish an account system in Bitcoin as an &quot;extension block&quot;.</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>Here&#39;s how it might work:</b></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1. Define a specia=
l anyone can spend output type that is a &quot;fee account&quot; (e.g. segw=
it V2). Such outputs have a redeeming key and an amount associated with the=
m, but are overall anyone can spend.</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">2. All deposits to these outputs get stored in a separate UTXO database =
for fee accounts</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3. Fee accounts c=
an sign only two kinds of transaction: A: a fee amount and a TXID (or Outpo=
int?); 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:sm=
all;color:rgb(0,0,0)">4. These transactions are committed in an extension b=
lock merkle tree. While the actual signature must cover the TXID/Outpoint, =
the committed data need only cover the index in the block of the transactio=
n. The public key for account lookup can be recovered from the message=C2=
=A0+ signature.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5. In any block, a=
ny of the fee account deposits can be: released into fees if there is a cor=
responding tx; consolidated together to reduce the number of utxos (this ca=
n be just an OP_TRUE no metadata needed); or released into fees *and paid b=
ack* into the requested withdrawal key (encumbering a 100 block timeout). S=
ignatures must be unique in a block.</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">6. Mempool logic is updated to allow attaching of account fee spends to =
transactions, the mempool can restrict that an account is not allowed more =
spend more than it&#39;s balance.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><b>But aren&#39;t accounts =
&quot;bad&quot;?</b></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Yes, accounts are bad. But these accounts =
are not bad, because any funds withdrawn from the fee extension are fundame=
ntally locked for 100 blocks as a coinbase output, so there should be no is=
sues with any series of reorgs. Further, since there is no &quot;rich state=
&quot; for these accounts, the state updates can always be applied in a con=
flict-free way in any order.</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><b>Improving the privacy of this design:</b></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This d=
esign could likely be modified to implement something like Tornado.cash or =
something else so that the fee account paying can be unlinked from the tran=
saction being paid for, improving privacy at the expense of being a bit mor=
e expensive.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">Other operations could be added to allow a trustl=
ess mixing to be done by miners automatically where groups of accounts with=
 similar values are trustlessly =C2=A0split into a common denominator and c=
hange, and keys are derived via a verifiable stealth address like protocol =
(so fee balances can be discovered by tracing the updates posted). These up=
dates could also be produced by individuals rather than miners, and miners =
could simply honor them with better privacy. While a miner generating an up=
date would be able to deanonymize their mixes, if you have your account mix=
ed several times by independent miners that could potentially add sufficien=
t privacy.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">The LN can also be used with PTLCs to, in theory, ha=
ve another individual paid to sponsor a transaction on your behalf only if =
they reveal a valid sig from their fee paying account, although under this =
model it&#39;s hard to ensure that the owner doesn&#39;t pay a fee and then=
 &#39;cancel&#39; by withdrawing the rest. However, this could be partly so=
lved by using reputable fee accounts (reputation could be measured somewhat=
 decentralized-ly by longevity of the account and transactions paid for his=
torically).</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><b>Scalability</b></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This design=
 is fundamentally &#39;decent&#39; for scalability because adding fees to a=
 transaction does not require adding inputs or outputs and does not require=
 tracking substantial amounts of new state.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Paying someone else=
 to pay for you via the LN also helps make this more efficient if the withd=
rawal issues can be fixed.</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><b>Lightning:</b></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">This type of design works really well for channels because the addition o=
f fees to e.g. a channel state does not require any sort of pre-planning (e=
.g. anchors) or transaction flexibility (SIGHASH flags). This sort of desig=
n is naturally immune to pinning issues since you could offer to pay a fee =
for any TXID and the number of fee adding offers does not need to be restri=
cted in the same way the descendant transactions would need to be.</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)"><b>Without a fork?</b></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">This type of design could be done as=
 a federated network that bribes miners -- potentially even retroactively a=
fter a block is formed. That might be sufficient to prove the concept works=
 before a consensus upgrade is deployed, but such an approach does mean the=
re is a centralizing layer interfering with normal mining.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)">Happy new year!!</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jer=
emy</div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a =
href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a>=
<a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></d=
iv></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000fdc27a05d5decd9e--