summaryrefslogtreecommitdiff
path: root/8a
diff options
context:
space:
mode:
authorGreg Sanders <gsanders87@gmail.com>2022-10-18 09:52:46 -0400
committerbitcoindev <bitcoindev@gnusha.org>2022-10-18 13:53:02 +0000
commit366259708cb9ae66bed63ef9b02c69078853df04 (patch)
tree423029161b847bfe682aec5cf7fc88ccda149b1e /8a
parent1026c4ebe31061db4bbe6864c610333080c4e198 (diff)
downloadpi-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/af94297ffeeb8ba1110689bc75d4ee049853e8436
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 &quot;V3 Transaction&quot; 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&#39;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&#39;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&#39=
+;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 &quot;sibling eviction&quot;, where if the new child is paying=
+ &quot;enough&quot; 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&#39;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 &quot;veto power&quot; 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--
+