diff options
author | Greg Sanders <gsanders87@gmail.com> | 2022-10-18 09:52:46 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-18 13:53:02 +0000 |
commit | 366259708cb9ae66bed63ef9b02c69078853df04 (patch) | |
tree | 423029161b847bfe682aec5cf7fc88ccda149b1e /8a | |
parent | 1026c4ebe31061db4bbe6864c610333080c4e198 (diff) | |
download | pi-bitcoindev-366259708cb9ae66bed63ef9b02c69078853df04.tar.gz pi-bitcoindev-366259708cb9ae66bed63ef9b02c69078853df04.zip |
[bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning
Diffstat (limited to '8a')
-rw-r--r-- | 8a/af94297ffeeb8ba1110689bc75d4ee049853e8 | 436 |
1 files changed, 436 insertions, 0 deletions
diff --git a/8a/af94297ffeeb8ba1110689bc75d4ee049853e8 b/8a/af94297ffeeb8ba1110689bc75d4ee049853e8 new file mode 100644 index 000000000..5e8c54290 --- /dev/null +++ b/8a/af94297ffeeb8ba1110689bc75d4ee049853e8 @@ -0,0 +1,436 @@ +Return-Path: <gsanders87@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C07DAC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Oct 2022 13:53:02 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 85162419B8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Oct 2022 13:53:02 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 85162419B8 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=EWZ9OZc8 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.838 +X-Spam-Level: +X-Spam-Status: No, score=-1.838 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] + 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 HoJMe-R6fTrE + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Oct 2022 13:53:00 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 58EE9419D0 +Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com + [IPv6:2a00:1450:4864:20::62c]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 58EE9419D0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Oct 2022 13:53:00 +0000 (UTC) +Received: by mail-ej1-x62c.google.com with SMTP id bj12so32260790ejb.13 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Oct 2022 06:53:00 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=to:subject:message-id:date:from:mime-version:from:to:cc:subject + :date:message-id:reply-to; + bh=Mp91NSPetyQ46VU1JZHTQk5It5LsomFEFoJpeXwgyl8=; + b=EWZ9OZc84+s73SO5ZuI9oZwVca31IKQNXtt6YzL5KV6zkYUb753mPcuBYeKDzUS3Ls + Z8DUXclvkmti4oImt9WxASht7Ri+KAAkCATy59YTdkVcE7IkCg6vHmHge3Gwr0t4kxwI + Ec0d8is0meVzBSL5eB6VvMozRqx2PFJIJt5hOvE/8WcSYuhZbWzzVYpfaNgf0bz5kSig + XfL2+QUxk4SZxE7KTK7x7d996I2HAZMHDVoiveHFV9iiehXelmYPYemmwifOMzfjbFVJ + fex+atP5DZ/QzGpMFFMgBYt9aBxRD9jBK2rxaDFTgRBfGDbLFp/cmTrUT2l6nLY0a1PZ + Aeeg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=to:subject:message-id:date:from:mime-version:x-gm-message-state + :from:to:cc:subject:date:message-id:reply-to; + bh=Mp91NSPetyQ46VU1JZHTQk5It5LsomFEFoJpeXwgyl8=; + b=dqTJhWPBApC8J1uzrknhlXsijuBhXJ9tjcPNOBcpukgCVnpHh3NCJ4S1AM2hmqrFt3 + 5sbxvNkj1QvvTbMVUJUWzr2wyyopkSwult6Af/P1PvRFZTETo/t53sdL0Z45Q17dPCKZ + hWt5eLrD9B14hDsMc97fqWQ6VgtTdpAaLMgB9HArAufGw2gAYSAeDnvxb+NM+WH76WzC + d4k5SzlY14XsjlegrUsXGcBj5DZv5l+m+OedMlW9o0nX9Z4Jg/bOa85QB7b/WOuKY1fd + +iU6ZhpJuziOQYkhUrw9weVOs9gPE6m6YEukxfSujOgGbStCqmzAKCdz9UROjf7Qp0k3 + ESZQ== +X-Gm-Message-State: ACrzQf1416kmGwytTbd4gTCkM7d0wlUYY/cJ46nMfcHo9MmHC1lXAVVS + 9NcD3/ErmrYUgN/WWHxVrcln4LRwJZCfaUutKnDLWsmzYI8= +X-Google-Smtp-Source: AMsMyM6gK0cpEhhORdP5Iinsyk+jDqrdyuuZjMGXhobJY4pZeTJ38bziQAX3bcn9NOH624IX2skwNmN4kTBUs71mzUA= +X-Received: by 2002:a17:907:2e19:b0:78e:11cc:3bc5 with SMTP id + ig25-20020a1709072e1900b0078e11cc3bc5mr2519015ejc.543.1666101178018; Tue, 18 + Oct 2022 06:52:58 -0700 (PDT) +MIME-Version: 1.0 +From: Greg Sanders <gsanders87@gmail.com> +Date: Tue, 18 Oct 2022 09:52:46 -0400 +Message-ID: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000e02fc405eb4f6857" +Subject: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against + package limit pinning +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 Oct 2022 13:53:02 -0000 + +--000000000000e02fc405eb4f6857 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hello Everyone, + +Following up on the "V3 Transaction" discussion here +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0209= +37.html +, I would like to elaborate a bit further on some potential follow-on work +that would make pinning severely constrained in many setups]. + +V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks under +some constraints[0]. This means that when a replacement is to be made and +propagated, it costs the expected amount of fees to do so. This is a great +start. What's left in this subset of pinning is *package limit* pinning. In +other words, a fee-paying transaction cannot enter the mempool due to the +existing mempool package it is being added to already being too large in +count or vsize. + +Zooming into the V3 simplified scenario for sake of discussion, though this +problem exists in general today: + +V3 transactions restrict the package limit of a V3 package to one parent +and one child. If the parent transaction includes two outputs which can be +immediately spent by separate parties, this allows one party to disallow a +spend from the other. In Gloria's proposal for ln-penalty, this is worked +around by reducing the number of anchors per commitment transaction to 1, +and each version of the commitment transaction has a unique party's key on +it. The honest participant can spend their version with their anchor and +package RBF the other commitment transaction safely. + +What if there's only one version of the commitment transaction, such as in +other protocols like duplex payment channels, eltoo? What about multi party +payments? + +In the package RBF proposal, if the parent transaction is identical to an +existing transaction in the mempool, the parent will be detected and +removed from the package proposal. You are then left with a single V3 child +transaction, which is then proposed for entry into the mempool. In the case +of another parent output already being spent, this is simply rejected, +regardless of feerate of the new child. + +I have two proposed solutions, of which I strongly prefer the latter: + +1) Expand a carveout for "sibling eviction", where if the new child is +paying "enough" to bump spends from the same parent, it knocks its sibling +out of the mempool and takes the one child slot. This would solve it, but +is a new eviction paradigm that would need to be carefully worked through. + +2) Ephemeral Anchors (my real policy-only proposal) + +Ephemeral Anchors is a term which means an output is watermarked as an +output that MUST be spent in a V3 package. We mark this anchor by being the +bare script `OP_TRUE` and of course make these outputs standard to relay +and spend with empty witness data. + +Also as a simplifying assumption, we require the parent transaction with +such an output to be 0-fee. This makes mempool reasoning simpler in case +the child-spend is somehow evicted, guaranteeing the parent will be as well= +. + +Implications: + +a) If the ephemeral anchor MUST be spent, we can allow *any* value, even +dust, even 0, without worrying about bloating the utxo set. We relax this +policy for maximum smart contract flexibility and specification simplicity.= +. + +b) Since this anchor MUST be spent, any spending of other outputs in the +same parent transaction MUST directly double-spend prior spends of the +ephemeral anchor. This causes the 1 block CSV timelock on outputs to be +removed in these situations. This greatly magnifies composability of smart +contracts, as now we can do things like safely splice directly into new +channels, into statechains, your custodial wallet account, your cold +wallet, wherever, without requiring other wallets to support arbitrary +scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript +compatible to begin with... + +c) *Anyone* can bump the transaction, without any transaction key material. +This is essentially achieving Jeremy's Transaction Sponsors ( +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/0181= +68.html) +proposal without consensus changes. As long as someone gets a fully signed +parent, they can execute a bump with minimal wallet tooling. If a +transaction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D, do not= + include the output. + +d) Lightning Carve-out( +https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/0022= +40.html) +is superseded by this logic, as we are not restricted to two immediately +spendable output scenarios. In its place, robust multi-party fee bumping is +possible. + +e) This also benefits more traditional wallet scenarios, as change outputs +can no longer be pinned, and RBF/CPFP becomes robust. Payees in simple +spends cannot pin you. Batched payouts become a lot less painful. This was +one of the motivating use cases that created the term =E2=80=9Cpinning=E2= +=80=9D in the +first place( +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/01571= +7.html), +even if LN/L2 discussion has largely overtaken it due to HTLC theft risks. + +Open Question(s): + + + 1. + + If we allow non-zero value in ephemeral outputs, does this open up a MEV + we are worried about? Wallets should toss all the value directly to fees= +, + and add their own additional fees on top, otherwise miners have incentiv= +e + to make the smallest utxo burn transaction to claim those funds. They ju= +st + confirmed your parent transaction anyways, so do we care? + 2. + + SIGHASH_GROUP like constructs would allow uncommitted ephemeral anchors + to be added at spend time, depending on spending requirements. + SIGHASH_SINGLE already allows this. + + + + +Hopefully this gives people something to consider as we move forward in +thinking about mempool design within the constraints we have today. + + +Greg + +0: With V3 transactions where you have "veto power" over all the inputs in +that transaction. Therefore something like ANYONECANPAY is still broken. We +need a more complex solution, which I=E2=80=99m punting for the sake of pro= +gress. + +--000000000000e02fc405eb4f6857 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><span id=3D"gmail-docs-internal-guid-2d3e64aa-7fff-66f1-ed= +3d-c94d5a1f62c6"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma= +rgin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(= +0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian= +t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Hello Eve= +ryone,</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p= +t;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:= +rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-va= +riant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Follo= +wing up on the "V3 Transaction" discussion here <a href=3D"https:= +//lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.htm= +l">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0= +20937.html</a> , I would like to elaborate a bit further on some potential = +follow-on work that would make pinning severely constrained in many setups]= +.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;mar= +gin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0= +,0,0);background-color:transparent;font-variant-numeric:normal;font-variant= +-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">V3 transac= +tions may solve bip125 rule#3 and rule#5 pinning attacks under some constra= +ints[0]. This means that when a replacement is to be made and propagated, i= +t costs the expected amount of fees to do so. This is a great start. What&#= +39;s left in this subset of pinning is *package limit* pinning. In other wo= +rds, a fee-paying transaction cannot enter the mempool due to the existing = +mempool package it is being added to already being too large in count or vs= +ize.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;= +margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rg= +b(0,0,0);background-color:transparent;font-variant-numeric:normal;font-vari= +ant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Zooming= + into the V3 simplified scenario for sake of discussion, though this proble= +m exists in general today:</span></p><br><p dir=3D"ltr" style=3D"line-heigh= +t:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font= +-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-nu= +meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= +pace:pre-wrap">V3 transactions restrict the package limit of a V3 package t= +o one parent and one child. If the parent transaction includes two outputs = +which can be immediately spent by separate parties, this allows one party t= +o disallow a spend from the other. In Gloria's proposal for ln-penalty,= + this is worked around by reducing the number of anchors per commitment tra= +nsaction to 1, and each version of the commitment transaction has a unique = +party's key on it. The honest participant can spend their version with = +their anchor and package RBF the other commitment transaction safely.</span= +></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot= +tom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);b= +ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a= +sian:normal;vertical-align:baseline;white-space:pre-wrap">What if there'= +;s only one version of the commitment transaction, such as in other protoco= +ls like duplex payment channels, eltoo? What about multi party payments?</s= +pan></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-= +bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0= +);background-color:transparent;font-variant-numeric:normal;font-variant-eas= +t-asian:normal;vertical-align:baseline;white-space:pre-wrap">In the package= + RBF proposal, if the parent transaction is identical to an existing transa= +ction in the mempool, the parent will be detected and removed from the pack= +age proposal. You are then left with a single V3 child transaction, which i= +s then proposed for entry into the mempool. In the case of another parent o= +utput already being spent, this is simply rejected, regardless of feerate o= +f the new child.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;mar= +gin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Ar= +ial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:norm= +al;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w= +rap">I have two proposed solutions, of which I strongly prefer the latter:<= +/span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi= +n-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0= +,0);background-color:transparent;font-variant-numeric:normal;font-variant-e= +ast-asian:normal;vertical-align:baseline;white-space:pre-wrap">1) Expand a = +carveout for "sibling eviction", where if the new child is paying= + "enough" to bump spends from the same parent, it knocks its sibl= +ing out of the mempool and takes the one child slot. This would solve it, b= +ut is a new eviction paradigm that would need to be carefully worked throug= +h.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma= +rgin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(= +0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian= +t-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">2) Epheme= +ral Anchors (my real policy-only proposal)</span></p><br><p dir=3D"ltr" sty= +le=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"fon= +t-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent= +;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= +baseline;white-space:pre-wrap">Ephemeral Anchors is a term which means an o= +utput is watermarked as an output that MUST be spent in a V3 package. We ma= +rk this anchor by being the bare script `OP_TRUE` and of course make these = +outputs standard to relay and spend with empty witness data.</span></p><br>= +<p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">= +<span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background= +-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm= +al;vertical-align:baseline;white-space:pre-wrap">Also as a simplifying assu= +mption, we require the parent transaction with such an output to be 0-fee. = +This makes mempool reasoning simpler in case the child-spend is somehow evi= +cted, guaranteeing the parent will be as well.</span></p><br><p dir=3D"ltr"= + style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D= +"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transpa= +rent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-al= +ign:baseline;white-space:pre-wrap">Implications:</span></p><br><p dir=3D"lt= +r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style= +=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:tran= +sparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical= +-align:baseline;white-space:pre-wrap">a) If the ephemeral anchor MUST be sp= +ent, we can allow *any* value, even dust, even 0, without worrying about bl= +oating the utxo set. We relax this policy for maximum smart contract flexib= +ility and specification simplicity..</span></p><br><p dir=3D"ltr" style=3D"= +line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size= +:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-= +variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseli= +ne;white-space:pre-wrap">b) Since this anchor MUST be spent, any spending o= +f other outputs in the same parent transaction MUST directly double-spend p= +rior spends of the ephemeral anchor. This causes the 1 block CSV timelock o= +n outputs to be removed in these situations. This greatly magnifies composa= +bility of smart contracts, as now we can do things like safely splice direc= +tly into new channels, into statechains, your custodial wallet account, you= +r cold wallet, wherever, without requiring other wallets to support arbitra= +ry scripts. Also it hurts that 1 CSV time locked scripts may not be miniscr= +ipt compatible to begin with...</span></p><br><p dir=3D"ltr" style=3D"line-= +height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt= +;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-varia= +nt-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;wh= +ite-space:pre-wrap">c) *Anyone* can bump the transaction, without any trans= +action key material. This is essentially achieving Jeremy's Transaction= + Sponsors (</span><a href=3D"https://lists.linuxfoundation.org/pipermail/bi= +tcoin-dev/2020-September/018168.html" style=3D"text-decoration-line:none"><= +span style=3D"font-size:11pt;font-family:Arial;background-color:transparent= +;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration= +-line:underline;vertical-align:baseline;white-space:pre-wrap">https://lists= +.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html</span= +></a><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);backg= +round-color:transparent;font-variant-numeric:normal;font-variant-east-asian= +:normal;vertical-align:baseline;white-space:pre-wrap">) proposal without co= +nsensus changes. As long as someone gets a fully signed parent, they can ex= +ecute a bump with minimal wallet tooling. If a transaction author doesn=E2= +=80=99t want a =E2=80=9Csponsor=E2=80=9D, do not include the output.</span>= +</p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bott= +om:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);ba= +ckground-color:transparent;font-variant-numeric:normal;font-variant-east-as= +ian:normal;vertical-align:baseline;white-space:pre-wrap">d) Lightning Carve= +-out(</span><a href=3D"https://lists.linuxfoundation.org/pipermail/lightnin= +g-dev/2019-October/002240.html" style=3D"text-decoration-line:none"><span s= +tyle=3D"font-size:11pt;font-family:Arial;background-color:transparent;font-= +variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:= +underline;vertical-align:baseline;white-space:pre-wrap">https://lists.linux= +foundation.org/pipermail/lightning-dev/2019-October/002240.html</span></a><= +span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= +color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= +l;vertical-align:baseline;white-space:pre-wrap">)=C2=A0 is superseded by th= +is logic, as we are not restricted to two immediately spendable output scen= +arios. In its place, robust multi-party fee bumping is possible.</span></p>= +<br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0= +pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);backgr= +ound-color:transparent;font-variant-numeric:normal;font-variant-east-asian:= +normal;vertical-align:baseline;white-space:pre-wrap">e) This also benefits = +more traditional wallet scenarios, as change outputs can no longer be pinne= +d, and RBF/CPFP becomes robust. Payees in simple spends cannot pin you. Bat= +ched payouts become a lot less painful. This was one of the motivating use = +cases that created the term =E2=80=9Cpinning=E2=80=9D in the first place(</= +span><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +8-February/015717.html" style=3D"text-decoration-line:none"><span style=3D"= +font-size:11pt;font-family:Arial;background-color:transparent;font-variant-= +numeric:normal;font-variant-east-asian:normal;text-decoration-line:underlin= +e;vertical-align:baseline;white-space:pre-wrap">https://lists.linuxfoundati= +on.org/pipermail/bitcoin-dev/2018-February/015717.html</span></a><span styl= +e=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:tra= +nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertica= +l-align:baseline;white-space:pre-wrap">), even if LN/L2 discussion has larg= +ely overtaken it due to HTLC theft risks.</span></p><br><p dir=3D"ltr" styl= +e=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= +-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;= +font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:b= +aseline;white-space:pre-wrap">Open Question(s):</span></p><br><ol style=3D"= +margin-top:0px;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:= +decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:= +transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vert= +ical-align:baseline;white-space:pre"><p dir=3D"ltr" style=3D"line-height:1.= +38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"f= +ont-size:11pt;background-color:transparent;font-variant-numeric:normal;font= +-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">If= + we allow non-zero value in ephemeral outputs, does this open up a MEV we a= +re worried about? Wallets should toss all the value directly to fees, and a= +dd their own additional fees on top, otherwise miners have incentive to mak= +e the smallest utxo burn transaction to claim those funds. They just confir= +med your parent transaction anyways, so do we care?</span></p></li><li dir= +=3D"ltr" style=3D"list-style-type:decimal;font-size:11pt;font-family:Arial;= +color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;f= +ont-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p d= +ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role= +=3D"presentation"><span style=3D"font-size:11pt;background-color:transparen= +t;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align= +:baseline;white-space:pre-wrap">SIGHASH_GROUP like constructs would allow u= +ncommitted ephemeral anchors to be added at spend time, depending on spendi= +ng requirements. SIGHASH_SINGLE already allows this.</span></p></li></ol><b= +r><br><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo= +ttom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);= +background-color:transparent;font-variant-numeric:normal;font-variant-east-= +asian:normal;vertical-align:baseline;white-space:pre-wrap">Hopefully this g= +ives people something to consider as we move forward in thinking about memp= +ool design within the constraints we have today.</span></p><br><br><p dir= +=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span = +style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color= +:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;ver= +tical-align:baseline;white-space:pre-wrap">Greg</span></p><br><p dir=3D"ltr= +" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style= +=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:tran= +sparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical= +-align:baseline;white-space:pre-wrap">0: With V3 transactions where you hav= +e "veto power" over all the inputs in that transaction. Therefore= + something like ANYONECANPAY is still broken. We need a more complex soluti= +on, which I=E2=80=99m punting for the sake of progress.</span></p></span><b= +r class=3D"gmail-Apple-interchange-newline"></div> + +--000000000000e02fc405eb4f6857-- + |