diff options
author | Jeremy <jlrubin@mit.edu> | 2022-01-18 09:43:07 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-18 17:43:24 +0000 |
commit | bcbcc6f4d4104c2b6fc0f1fc63610182b8912db5 (patch) | |
tree | 3199305e24c241e1b2dbfeca6a4d5ad01dd05979 | |
parent | d0dbe407d467a6d155a4c0964387a223337e8b1b (diff) | |
download | pi-bitcoindev-bcbcc6f4d4104c2b6fc0f1fc63610182b8912db5.tar.gz pi-bitcoindev-bcbcc6f4d4104c2b6fc0f1fc63610182b8912db5.zip |
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
-rw-r--r-- | 61/28b61ba844f9581e5c0fcea41aecc9d99f71ce | 422 |
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 "improve the situation"?</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'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'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 <<a href=3D"mailto:billy.tetrud@gmai= +l.com">billy.tetrud@gmail.com</a>> 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 <<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= +</a>> 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 "= +for good". The design space is very wide on the approach I'll shar= +e, so below is just a sketch of how it could work which I'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'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 "Bitcoin 1.0" 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't predict future fee r= +ates. 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 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 "Sponsor" 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 "extension block".</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'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 "fee account" (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'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't accounts = +"bad"?</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 "rich state= +" 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's hard to ensure that the owner doesn't pay a fee and then= + 'cancel' 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 '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.</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-- + |