path: root/4b/2fdd9a03343fa2f80b8cbc57c33b0a981de89f

Return-Path: <linuxfoundation@arik.io>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 311FEC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:40:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C77AE823CF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:40:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C77AE823CF
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key, unprotected) header.d=arik.io header.i=@arik.io
 header.a=rsa-sha256 header.s=fm1 header.b=o26NkmBB; 
 dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=J6Okiycg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.893
X-Spam-Level: 
X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id g2q_oJbVnJNL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:40:57 +0000 (UTC)
X-Greylist: delayed 00:06:58 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D267281A64
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com
 [64.147.123.25])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D267281A64
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 15:40:56 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 4F008320092E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 11:33:53 -0400 (EDT)
Received: from imap42 ([10.202.2.92])
 by compute2.internal (MEProxy); Tue, 18 Oct 2022 11:33:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arik.io; h=cc
 :content-type:date:date:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to; s=fm1; t=1666107232; x=1666193632; bh=a5TVldxbiS
 9Cojd+PbC0uevVTcuG4+KKf8fLnySMbh0=; b=o26NkmBBSoNp6ZR/MK4s/jqJ0r
 RobI9x6Pi01pKYHHRYxbRKE1Xb/nzmHP1v5r4+HJpqwUDNVghYR/gZ43v+BSYI0X
 6eSo6nxcI2ArtDnQ0AEwOFl8w/PHleC4eyOaLvGVCRIQBQh5ohwaJmvC1xuVFh0y
 TGCU0YA1jKMX84f0Q3n3iRKjWEnZUqWsCAf84ZnARcyhcUy/4sYB4sLMNVQzPwqk
 w4DM+sdmyuu1gytAyxKBjFItJJhGq0+514D9H40oMUte86fOjNWQaM5ghn2yQwoE
 3qtcGE6AOUEB8z62nhUfPuR2rYyiy8hQvhoKdmHvS5zQT40sPrgwQOY+TOiQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:date:feedback-id
 :feedback-id:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1666107232; x=1666193632; bh=a5TVldxbiS9Cojd+PbC0uevVTcuG
 4+KKf8fLnySMbh0=; b=J6OkiycggLWi1I5LlD3v8OO1+iP3BHC7KYixTHIyNcDN
 qwPyDemAOzO7bICsB4ZRR+OC3ugWRZXz+j1eFrUubzkrdcgmDT1RQJSkeM72GwmU
 EpbcQRNFv43oPxbQxzZB96Z/zIGKKVxcmjzaUlM5PmD5Uhy3ZMU3CWyFK5/TJYoM
 KAzhonkXmIK0p2KyNXMxh+/cDdMzCoZBl/JsyjeTLegv/ReLw+f9EQSvY0JrboKL
 vyQVnGgRE79y6c3ZpH4E6elqHjK1KyncpAaY3JVK4gOrEzb95oeb2Bu3o67r12+U
 tQc9d1bfsjWw8dqgsP2yg9G57knnICrwMj4wO7kdbw==
X-ME-Sender: <xms:YMdOYxj8gou6GZ_1rL2BaqhjAyUZqicR_xBBjD7fnmweik34Cn1uhA>
 <xme:YMdOY2ACWZNs6V22vK4Ttwkgs4BN6ocYaO1e9r5KOYWUjZPRMPqgULMp7eiRJ7efi
 E2yEzm26tZ06HkukVQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelvddgieduucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd
 erreerreejnecuhfhrohhmpedftehrihhkucfuohhsmhgrnhdfuceolhhinhhugihfohhu
 nhgurghtihhonhesrghrihhkrdhioheqnecuggftrfgrthhtvghrnhepheeiueduuddtff
 eiffegfeeiffehtedtledtgfeihfelhfetudffkeehheefhfdunecuffhomhgrihhnpehl
 ihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc
 frrghrrghmpehmrghilhhfrhhomheplhhinhhugihfohhunhgurghtihhonhesrghrihhk
 rdhioh
X-ME-Proxy: <xmx:YMdOYxGb6By3bQlvYR-AnaYa0jB9GUXsqagw9sUG2VcZdclpZerERw>
 <xmx:YMdOY2S46kAFDdHn2ll6rwFOC1OBc4vl7AHVCgmgmbWvENpbFV9Qig>
 <xmx:YMdOY-weDnZ7ubG3MV5s5ZZi53WK7XDjJEYhs7c7zdT88u_gdxwOvQ>
 <xmx:YMdOY9_RPTogBTRpEsHcRW_cQc-ldbSXvED9_WnoHBbvxZ9qM6e9Aw>
Feedback-ID: i2359471f:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id BE817BC0083; Tue, 18 Oct 2022 11:33:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad
Mime-Version: 1.0
Message-Id: <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>
In-Reply-To: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com>
References: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com>
Date: Tue, 18 Oct 2022 08:33:32 -0700
From: "Arik Sosman" <linuxfoundation@arik.io>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=777b826cc2484de1bc0722d4ad4851e5
X-Mailman-Approved-At: Tue, 18 Oct 2022 15:46:58 +0000
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF
 againstpackage 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 15:40:59 -0000

--777b826cc2484de1bc0722d4ad4851e5
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Greg,

Thank you very much for sharing your proposal!

I think there's one thing about the second part of your proposal that I'=
m missing. Specifically, assuming the scenario of a v3 transaction with =
three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transa=
ction spends A and OP_TRUE, does that effectively mark output B as unspe=
ndable once the child gets confirmed? If so, isn't the implication there=
fore that to safely spend a transaction with an ephemeral anchor, all ou=
tputs must be spent? Thanks!

Best,
Arik

On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
> Hello Everyone,
>=20
>=20
> Following up on the "V3 Transaction" discussion here https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html , I wo=
uld like to elaborate a bit further on some potential follow-on work tha=
t would make pinning severely constrained in many setups].
>=20
>=20
> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks und=
er 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 mempo=
ol due to the existing mempool package it is being added to already bein=
g too large in count or vsize.
>=20
>=20
> Zooming into the V3 simplified scenario for sake of discussion, though=
 this problem exists in general today:
>=20
>=20
> V3 transactions restrict the package limit of a V3 package to one pare=
nt and one child. If the parent transaction includes two outputs which c=
an be immediately spent by separate parties, this allows one party to di=
sallow a spend from the other. In Gloria's proposal for ln-penalty, this=
 is worked around by reducing the number of anchors per commitment trans=
action 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.
>=20
>=20
> What if there's only one version of the commitment transaction, such a=
s in other protocols like duplex payment channels, eltoo? What about mul=
ti party payments?
>=20
>=20
> 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 c=
hild transaction, which is then proposed for entry into the mempool. In =
the case of another parent output already being spent, this is simply re=
jected, regardless of feerate of the new child.
>=20
>=20
> I have two proposed solutions, of which I strongly prefer the latter:
>=20
>=20
> 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=
, but is a new eviction paradigm that would need to be carefully worked =
through.
>=20
>=20
> 2) Ephemeral Anchors (my real policy-only proposal)
>=20
>=20
> 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.
>=20
>=20
> Also as a simplifying assumption, we require the parent transaction wi=
th such an output to be 0-fee. This makes mempool reasoning simpler in c=
ase the child-spend is somehow evicted, guaranteeing the parent will be =
as well.
>=20
>=20
> Implications:
>=20
>=20
> a) If the ephemeral anchor MUST be spent, we can allow *any* value, ev=
en dust, even 0, without worrying about bloating the utxo set. We relax =
this policy for maximum smart contract flexibility and specification sim=
plicity..
>=20
>=20
> b) Since this anchor MUST be spent, any spending of other outputs in t=
he same parent transaction MUST directly double-spend prior spends of th=
e ephemeral anchor. This causes the 1 block CSV timelock on outputs to b=
e removed in these situations. This greatly magnifies composability of s=
mart contracts, as now we can do things like safely splice directly into=
 new channels, into statechains, your custodial wallet account, your col=
d wallet, wherever, without requiring other wallets to support arbitrary=
 scripts. Also it hurts that 1 CSV time locked scripts may not be minisc=
ript compatible to begin with...
>=20
>=20
> c) *Anyone* can bump the transaction, without any transaction key mate=
rial. This is essentially achieving Jeremy's Transaction Sponsors (https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168=
.html) proposal without consensus changes. As long as someone gets a ful=
ly signed parent, they can execute a bump with minimal wallet tooling. I=
f a transaction author doesn=E2=80=99t want a =E2=80=9Csponsor=E2=80=9D,=
 do not include the output.
>=20
>=20
> d) Lightning Carve-out(https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2019-October/002240.html)  is superseded by this logic, as we=
 are not restricted to two immediately spendable output scenarios. In it=
s place, robust multi-party fee bumping is possible.
>=20
>=20
> e) This also benefits more traditional wallet scenarios, as change out=
puts can no longer be pinned, and RBF/CPFP becomes robust. Payees in sim=
ple spends cannot pin you. Batched payouts become a lot less painful. Th=
is was one of the motivating use cases that created the term =E2=80=9Cpi=
nning=E2=80=9D in the first place(https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2018-February/015717.html), even if LN/L2 discussion h=
as largely overtaken it due to HTLC theft risks.
>=20
>=20
> Open Question(s):
>=20
>=20
>  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=
 incentive to make the smallest utxo burn transaction to claim those fun=
ds. They just confirmed your parent transaction anyways, so do we care?
>=20
>  2. SIGHASH_GROUP like constructs would allow uncommitted ephemeral an=
chors to be added at spend time, depending on spending requirements. SIG=
HASH_SINGLE already allows this.
>=20
>=20
>=20
>=20
> Hopefully this gives people something to consider as we move forward i=
n thinking about mempool design within the constraints we have today.
>=20
>=20
>=20
> Greg
>=20
>=20
> 0: With V3 transactions where you have "veto power" over all the input=
s in that transaction. Therefore something like ANYONECANPAY is still br=
oken. We need a more complex solution, which I=E2=80=99m punting for the=
 sake of progress.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20

--777b826cc2484de1bc0722d4ad4851e5
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Greg,<br></d=
iv><div><br></div><div>Thank you very much for sharing your proposal!</d=
iv><div><br></div><div>I think there's one thing about the second part o=
f your proposal that I'm missing. Specifically, assuming the scenario of=
 a v3 transaction with three outputs, A, B, and the ephemeral anchor OP_=
TRUE. If a child transaction spends A and OP_TRUE, does that effectively=
 mark output B as unspendable once the child gets confirmed? If so, isn'=
t the implication therefore that to safely spend a transaction with an e=
phemeral anchor, all outputs must be spent? Thanks!<br></div><div><br></=
div><div>Best,<br></div><div>Arik</div><div><br></div><div>On Tue, Oct 1=
8, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:<br></div><block=
quote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><span id=3D"qt=
-gmail-docs-internal-guid-2d3e64aa-7fff-66f1-ed3d-c94d5a1f62c6"><p dir=3D=
"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span=
 style=3D"color:rgb(0, 0, 0);background-color:transparent;font-variant-n=
umeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whi=
te-space:pre-wrap;"><span class=3D"font" style=3D"font-family:Arial;"><s=
pan class=3D"size" style=3D"font-size:11pt;">Hello Everyone,</span></spa=
n></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38=
;margin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);ba=
ckground-color:transparent;font-variant-numeric:normal;font-variant-east=
-asian:normal;vertical-align:baseline;white-space:pre-wrap;"><span class=
=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D"fon=
t-size:11pt;">Following up on the "V3 Transaction" discussion here <a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septe=
mber/020937.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2022-September/020937.html</a> , I would like to elaborate a bit furth=
er on some potential follow-on work that would make pinning severely con=
strained in many setups].</span></span></span><br></p><div><br></div><p =
dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"=
><span style=3D"color:rgb(0, 0, 0);background-color:transparent;font-var=
iant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseli=
ne;white-space:pre-wrap;"><span class=3D"font" style=3D"font-family:Aria=
l;"><span class=3D"size" style=3D"font-size:11pt;">V3 transactions may s=
olve 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 cos=
ts the expected amount of fees to do so. This is a great start. What's l=
eft 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.</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D=
"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"colo=
r:rgb(0, 0, 0);background-color:transparent;font-variant-numeric:normal;=
font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w=
rap;"><span class=3D"font" style=3D"font-family:Arial;"><span class=3D"s=
ize" style=3D"font-size:11pt;">Zooming into the V3 simplified scenario f=
or sake of discussion, though this problem exists in general today:</spa=
n></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-heig=
ht:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0=
, 0);background-color:transparent;font-variant-numeric:normal;font-varia=
nt-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;"><spa=
n class=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=
=3D"font-size:11pt;">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 all=
ows one party to disallow a spend from the other. In Gloria's proposal f=
or ln-penalty, this is worked around by reducing the number of anchors p=
er commitment transaction to 1, and each version of the commitment trans=
action has a unique party's key on it. The honest participant can spend =
their version with their anchor and package RBF the other commitment tra=
nsaction safely.</span></span></span><br></p><div><br></div><p dir=3D"lt=
r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span st=
yle=3D"color:rgb(0, 0, 0);background-color:transparent;font-variant-nume=
ric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-=
space:pre-wrap;"><span class=3D"font" style=3D"font-family:Arial;"><span=
 class=3D"size" style=3D"font-size:11pt;">What if there's only one versi=
on of the commitment transaction, such as in other protocols like duplex=
 payment channels, eltoo? What about multi party payments?</span></span>=
</span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;m=
argin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);back=
ground-color:transparent;font-variant-numeric:normal;font-variant-east-a=
sian:normal;vertical-align:baseline;white-space:pre-wrap;"><span class=3D=
"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D"font-s=
ize:11pt;">In the package RBF proposal, if the parent transaction is ide=
ntical to an existing transaction in the mempool, the parent will be det=
ected and removed from the package proposal. You are then left with a si=
ngle V3 child transaction, which is then proposed for entry into the mem=
pool. In the case of another parent output already being spent, this is =
simply rejected, regardless of feerate of the new child.</span></span></=
span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;mar=
gin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);backgr=
ound-color:transparent;font-variant-numeric:normal;font-variant-east-asi=
an:normal;vertical-align:baseline;white-space:pre-wrap;"><span class=3D"=
font" style=3D"font-family:Arial;"><span class=3D"size" style=3D"font-si=
ze:11pt;">I have two proposed solutions, of which I strongly prefer the =
latter:</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D=
"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"colo=
r:rgb(0, 0, 0);background-color:transparent;font-variant-numeric:normal;=
font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w=
rap;"><span class=3D"font" style=3D"font-family:Arial;"><span class=3D"s=
ize" style=3D"font-size:11pt;">1) Expand a carveout for "sibling evictio=
n", where if the new child is paying "enough" to bump spends from the sa=
me parent, it knocks its sibling out of the mempool and takes the one ch=
ild slot. This would solve it, but is a new eviction paradigm that would=
 need to be carefully worked through.</span></span></span><br></p><div><=
br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-=
bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:transpar=
ent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-=
align:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"font=
-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;">2) Epheme=
ral Anchors (my real policy-only proposal)</span></span></span><br></p><=
div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:tra=
nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;vert=
ical-align:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D=
"font-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;">Ephe=
meral Anchors is a term which means an output is watermarked as an outpu=
t that MUST be spent in a V3 package. We mark this anchor by being the b=
are script `OP_TRUE` and of course make these outputs standard to relay =
and spend with empty witness data.</span></span></span><br></p><div><br>=
</div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:transparent=
;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-ali=
gn:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"font-fa=
mily:Arial;"><span class=3D"size" style=3D"font-size:11pt;">Also as a si=
mplifying assumption, we require the parent transaction with such an out=
put to be 0-fee. This makes mempool reasoning simpler in case the child-=
spend is somehow evicted, guaranteeing the parent will be as well.</span=
></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-heigh=
t:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"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;"><span=
 class=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D=
"font-size:11pt;">Implications:</span></span></span><br></p><div><br></d=
iv><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom=
:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:transparent;fo=
nt-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:=
baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"font-famil=
y:Arial;"><span class=3D"size" style=3D"font-size:11pt;">a) If the ephem=
eral 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 m=
aximum smart contract flexibility and specification simplicity..</span><=
/span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:=
1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0=
);background-color:transparent;font-variant-numeric:normal;font-variant-=
east-asian:normal;vertical-align:baseline;white-space:pre-wrap;"><span c=
lass=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D=
"font-size:11pt;">b) Since this anchor MUST be spent, any spending of ot=
her outputs in the same parent transaction MUST directly double-spend pr=
ior spends of the ephemeral anchor. This causes the 1 block CSV timelock=
 on outputs to be removed in these situations. This greatly magnifies co=
mposability of smart contracts, as now we can do things like safely spli=
ce directly into new channels, into statechains, your custodial wallet a=
ccount, your cold wallet, wherever, without requiring other wallets to s=
upport arbitrary scripts. Also it hurts that 1 CSV time locked scripts m=
ay not be miniscript compatible to begin with...</span></span></span><br=
></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-col=
or:transparent;font-variant-numeric:normal;font-variant-east-asian:norma=
l;vertical-align:baseline;white-space:pre-wrap;"><span class=3D"font" st=
yle=3D"font-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;=
">c) *Anyone* can bump the transaction, without any transaction key mate=
rial. This is essentially achieving Jeremy's Transaction Sponsors (</spa=
n></span></span><a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2020-September/018168.html" style=3D"text-decoration-line:non=
e;"><span style=3D"background-color:transparent;font-variant-numeric:nor=
mal;font-variant-east-asian:normal;text-decoration-line:underline;vertic=
al-align:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"f=
ont-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.=
html</span></span></span></a><span style=3D"color:rgb(0, 0, 0);backgroun=
d-color:transparent;font-variant-numeric:normal;font-variant-east-asian:=
normal;vertical-align:baseline;white-space:pre-wrap;"><span class=3D"fon=
t" style=3D"font-family:Arial;"><span class=3D"size" style=3D"font-size:=
11pt;">) proposal without consensus changes. As long as someone gets a f=
ully 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.</span></span></span><br></p><div><br></div>=
<p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0p=
t;"><span style=3D"color:rgb(0, 0, 0);background-color:transparent;font-=
variant-numeric:normal;font-variant-east-asian:normal;vertical-align:bas=
eline;white-space:pre-wrap;"><span class=3D"font" style=3D"font-family:A=
rial;"><span class=3D"size" style=3D"font-size:11pt;">d) Lightning Carve=
-out(</span></span></span><a href=3D"https://lists.linuxfoundation.org/p=
ipermail/lightning-dev/2019-October/002240.html" style=3D"text-decoratio=
n-line:none;"><span style=3D"background-color:transparent;font-variant-n=
umeric:normal;font-variant-east-asian:normal;text-decoration-line:underl=
ine;vertical-align:baseline;white-space:pre-wrap;"><span class=3D"font" =
style=3D"font-family:Arial;"><span class=3D"size" style=3D"font-size:11p=
t;">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Octob=
er/002240.html</span></span></span></a><span style=3D"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;"><span cl=
ass=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D"=
font-size:11pt;">)&nbsp; is superseded by this logic, as we are not rest=
ricted to two immediately spendable output scenarios. In its place, robu=
st multi-party fee bumping is possible.</span></span></span><br></p><div=
><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:transp=
arent;font-variant-numeric:normal;font-variant-east-asian:normal;vertica=
l-align:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"fo=
nt-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;">e) This=
 also benefits more traditional wallet scenarios, as change outputs can =
no longer be pinned, and RBF/CPFP becomes robust. Payees in simple spend=
s cannot pin you. Batched payouts become a lot less painful. This was on=
e of the motivating use cases that created the term =E2=80=9Cpinning=E2=80=
=9D in the first place(</span></span></span><a href=3D"https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html" style=3D=
"text-decoration-line:none;"><span style=3D"background-color:transparent=
;font-variant-numeric:normal;font-variant-east-asian:normal;text-decorat=
ion-line:underline;vertical-align:baseline;white-space:pre-wrap;"><span =
class=3D"font" style=3D"font-family:Arial;"><span class=3D"size" style=3D=
"font-size:11pt;">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2018-February/015717.html</span></span></span></a><span style=3D"color=
:rgb(0, 0, 0);background-color:transparent;font-variant-numeric:normal;f=
ont-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wr=
ap;"><span class=3D"font" style=3D"font-family:Arial;"><span class=3D"si=
ze" style=3D"font-size:11pt;">), even if LN/L2 discussion has largely ov=
ertaken it due to HTLC theft risks.</span></span></span><br></p><div><br=
></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-al=
ign:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"font-f=
amily:Arial;"><span class=3D"size" style=3D"font-size:11pt;">Open Questi=
on(s):</span></span></span><br></p><div><br></div><ol style=3D"margin-to=
p:0px;margin-bottom:0px;"><li dir=3D"ltr" style=3D"list-style-type:decim=
al;font-size:11pt;font-family:Arial;color:rgb(0, 0, 0);background-color:=
transparent;font-variant-numeric:normal;font-variant-east-asian:normal;v=
ertical-align:baseline;white-space:pre;"><p dir=3D"ltr" style=3D"line-he=
ight:1.38;margin-top:0pt;margin-bottom:0pt;" role=3D"presentation"><span=
 style=3D"background-color:transparent;font-variant-numeric:normal;font-=
variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;"=
><span class=3D"size" style=3D"font-size:11pt;">If we allow non-zero val=
ue in ephemeral outputs, does this open up a MEV we are worried about? W=
allets should toss all the value directly to fees, and add their own add=
itional fees on top, otherwise miners have incentive to make the smalles=
t utxo burn transaction to claim those funds. They just confirmed your p=
arent transaction anyways, so do we care?</span></span><br></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-numer=
ic:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s=
pace:pre;"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt;" role=3D"presentation"><span style=3D"background-color:tra=
nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;vert=
ical-align:baseline;white-space:pre-wrap;"><span class=3D"size" style=3D=
"font-size:11pt;">SIGHASH_GROUP like constructs would allow uncommitted =
ephemeral anchors to be added at spend time, depending on spending requi=
rements. SIGHASH_SINGLE already allows this.</span></span><br></p></li><=
/ol><div><br></div><div><br></div><div><br></div><p dir=3D"ltr" style=3D=
"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"colo=
r:rgb(0, 0, 0);background-color:transparent;font-variant-numeric:normal;=
font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-w=
rap;"><span class=3D"font" style=3D"font-family:Arial;"><span class=3D"s=
ize" style=3D"font-size:11pt;">Hopefully this gives people something to =
consider as we move forward in thinking about mempool design within the =
constraints we have today.</span></span></span><br></p><div><br></div><d=
iv><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;mar=
gin-bottom:0pt;"><span style=3D"color:rgb(0, 0, 0);background-color:tran=
sparent;font-variant-numeric:normal;font-variant-east-asian:normal;verti=
cal-align:baseline;white-space:pre-wrap;"><span class=3D"font" style=3D"=
font-family:Arial;"><span class=3D"size" style=3D"font-size:11pt;">Greg<=
/span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-=
height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style=3D"color:rgb(=
0, 0, 0);background-color:transparent;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;">=
<span class=3D"font" style=3D"font-family:Arial;"><span class=3D"size" s=
tyle=3D"font-size:11pt;">0: With V3 transactions where you have "veto po=
wer" over all the inputs in that transaction. Therefore something like A=
NYONECANPAY is still broken. We need a more complex solution, which I=E2=
=80=99m punting for the sake of progress.</span></span></span><br></p></=
span></div><div>_______________________________________________<br></div=
><div>bitcoin-dev mailing list<br></div><div><a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><=
br></div><div><a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev</a><br></div><div><br></div></blockquote><div><br></div></body><=
/html>
--777b826cc2484de1bc0722d4ad4851e5--