summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy <jlrubin@mit.edu>2022-01-18 09:43:07 -0800
committerbitcoindev <bitcoindev@gnusha.org>2022-01-18 17:43:24 +0000
commitbcbcc6f4d4104c2b6fc0f1fc63610182b8912db5 (patch)
tree3199305e24c241e1b2dbfeca6a4d5ad01dd05979
parentd0dbe407d467a6d155a4c0964387a223337e8b1b (diff)
downloadpi-bitcoindev-bcbcc6f4d4104c2b6fc0f1fc63610182b8912db5.tar.gz
pi-bitcoindev-bcbcc6f4d4104c2b6fc0f1fc63610182b8912db5.zip
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
-rw-r--r--61/28b61ba844f9581e5c0fcea41aecc9d99f71ce422
1 files changed, 422 insertions, 0 deletions
diff --git a/61/28b61ba844f9581e5c0fcea41aecc9d99f71ce b/61/28b61ba844f9581e5c0fcea41aecc9d99f71ce
new file mode 100644
index 000000000..7c4f7e358
--- /dev/null
+++ b/61/28b61ba844f9581e5c0fcea41aecc9d99f71ce
@@ -0,0 +1,422 @@
+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--
+