path: root/16/8a10c711c1705fddb71efcf4648718da15d7b3

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 E6FC4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Jan 2023 14:05:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id AC5EA41D5A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Jan 2023 14:05:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AC5EA41D5A
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=SvRw7OK5
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 T1U4qw_5LWEY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Jan 2023 14:05:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AAA9E41D2D
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp4.osuosl.org (Postfix) with ESMTPS id AAA9E41D2D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Jan 2023 14:05:34 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id me3so13983978ejb.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Jan 2023 06:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=yKx9CeQtCv0e5An9NbD/k6yqhk4/vh+lvlG36sUkjFg=;
 b=SvRw7OK5fKSrW3GEfYs6ytnypqHZ5lfFHlbMpXBDiH3UeqJ5CxMi4Lu2NYstkw9wpq
 kMkFcp70qaOhSpnaEpveF3W1lggen8VFaW+qllHvQqPRgK+LTD/OUIS6xuHDbTxSHUHA
 Iy21tpA1Acr67Aopm/H7zuNHtDyuxTmxFW8Nd5Ad/Lpx+F6oBfZFvbHflCxv6tDVqZiL
 tYAZ1ig0ji4vl849HmU4zBF74xaRc4r+XhssPHc+UHyi2jDR1FaVd1l7ZfpIbjDZs9zD
 mGw2ds7wsPRqdj3/qBF5HgKTZbzfzRIHcKUfLyZUd9SGhixco8qiQ2jIlrZPPrarLba1
 JUvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=yKx9CeQtCv0e5An9NbD/k6yqhk4/vh+lvlG36sUkjFg=;
 b=2tkCMCh2RaH+lsatVhetObRktn1viEWhedV0m8Kx/Ng82FQUuUnr+tpkwnYH32eodD
 GWIvf6G6mL74I0U0FGv6n86VOEL/PBkPS08yxQeowq6H9+3uRJhFkRFgt0PgCe07XJ5L
 vUbDsP6R7PKBurs42T0NXGQeJY9XYWjo0x84wQ7LhhU8gv4G50w9+S3QJ7YlT89KK/xt
 9fSPYSopGgatygLphKqmpucd65huv+kojH4mvg0l6hQ5ySY4uggKn7sUFIbpS1bDkKQE
 xoqDqOcjTuxxSV2NJi91pRYODxcYvrGIV5ss3p5OA5jktdwYxQ/lWTmGf4vYvWPQVpff
 xHCg==
X-Gm-Message-State: AO0yUKWMWcawcuxr8hCiOmtygeYrbKRIcmzLYXf75xFXN85oc7ge3o48
 DpH9o8Dk6xpCVV3yCjoYsSqJZJF7yGS3Ot8sGFIRNPYhn+M=
X-Google-Smtp-Source: AK7set+38nyEz+ztXbMMbvFYO26uk7C7IJE9gZRz2RtRAe0MYAKZ2JBnmawQiZOAt1pcle1aUa8OJ4JF8lEJKOQT0EE=
X-Received: by 2002:a17:906:c449:b0:878:4ee0:7ded with SMTP id
 ck9-20020a170906c44900b008784ee07dedmr1820267ejb.9.1674828332107; Fri, 27 Jan
 2023 06:05:32 -0800 (PST)
MIME-Version: 1.0
References: <CAB3F3Dukoz3P3Ne7tCxMiwwAGm3Fv8r_fUkNbGAtGhAZDYDgCQ@mail.gmail.com>
 <ec952a9c-d810-4996-9ca9-1e9c6f6faca4@app.fastmail.com>
 <CAB3F3DvH3FnK8krykbcRVKc-z8F4yjt9mzYHevpYxaWkH4w9tw@mail.gmail.com>
 <CAD5xwhgFBQ-ScyBU5=WnREGsN-T=Nv=oR6vOsnHJ-ZMzDF8Vqg@mail.gmail.com>
 <CAPfvXf+N8aF+bqjGzpfDrhCYg7ngciSDCpUnCMHD+k5F+m3oWA@mail.gmail.com>
 <CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>
 <CAB3F3DtrSFPmperGJJAUDZj7vt9aHgvkc0b5Pts3+mq5fTuWXA@mail.gmail.com>
In-Reply-To: <CAB3F3DtrSFPmperGJJAUDZj7vt9aHgvkc0b5Pts3+mq5fTuWXA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 27 Jan 2023 09:05:20 -0500
Message-ID: <CAB3F3DvToF_fia+X5SQi-L=BDYGLpzr8nNHqjtFBUjLMbyPE9Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cb8ff605f33f5b5e"
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: Fri, 27 Jan 2023 14:05:38 -0000

--000000000000cb8ff605f33f5b5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello again dev,

Due to the interest in the proposal and the prodding of certain folks, I've
written up a short draft BIP of the Ephemeral Anchors idea here:
https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralancho=
rs.mediawiki

The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been
refreshed on top of the latest V3 proposal, but the BIP itself is
unaffected.

Cheers,
Greg

On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders <gsanders87@gmail.com> wrote:

> Small update.
>
> A bit ago I went ahead and implemented ephemeral anchors on top of the V3
> proposal to see what the complexity looks like:
> https://github.com/bitcoin/bitcoin/pull/26403
>
> Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not cam=
p
> the value that is used elsewhere.
>
> Please let me know if you have any early feedback on this!
>
> Greg
>
> On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders <gsanders87@gmail.com> wrote=
:
>
>> So it doesn't look like I'm ignoring a good question:
>>
>> No solid noninteractive ideas, unless we get some very flexible sighash
>> softfork. Interactively, I think you can get collaborative fee bumps und=
er
>> the current consensus regime and ephemeral anchors. The child will just =
be
>> built with inputs from different people.
>>
>> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne <james.obeirne@gmail.com=
>
>> wrote:
>>
>>> I'm also very happy to see this proposal, since it gets us closer to
>>> having a mechanism that allows the contribution to feerate in an
>>> "unauthenticated" way, which seems to be a very helpful feature for vau=
lts
>>> and other contracting protocols.
>>>
>>> One possible advantage of the sponsors interface -- and I'm curious for
>>> your input here Greg -- is that with sponsors, assuming we relaxed the =
"one
>>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>>> collaboratively bump a tx's feerate. A simple example would be a batch
>>> withdrawal from an exchange could be created with a low feerate, and th=
en
>>> multiple users with a vested interest of expedited confirmation could a=
ll
>>> "chip in" to raise the feerate with multiple sponsor transactions.
>>>
>>> Having a single ephemeral output seems to create a situation where a
>>> single UTXO has to shoulder the burden of CPFPing a package. Is there s=
ome
>>> way we could (possibly later) amend the ephemeral anchor interface to a=
llow
>>> for this kind of collaborative sponsoring? Could you maybe see "chained=
"
>>> ephemeral anchors that would allow this?
>>>
>>>
>>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Excellent proposal and I agree it does capture much of the spirit of
>>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>>
>>>> The only drawbacks I see is they don't work for lower tx version
>>>> contracts, so there's still something to be desired there, and that th=
e
>>>> requirement to sweep the output must be incentive compatible for the m=
iner,
>>>> or else they won't enforce it (pass the buck onto the future bitcoiner=
s).
>>>> The Ephemeral UTXO concept can be a consensus rule (see
>>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>>> UTXO") we add later on in lieu of managing them by incentive, so maybe=
 it's
>>>> a cleanup one can punt.
>>>>
>>>> One question I have is if V3 is designed for lightning, and this is
>>>> designed for lightning, is there any sense in requiring these outputs =
for
>>>> v3? That might help with e.g. anonymity set, as well as potentially ke=
ep
>>>> the v3 surface smaller.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> > does that effectively mark output B as unspendable once the child
>>>>> gets confirmed?
>>>>>
>>>>> Not at all. It's a normal spend like before, since the parent has bee=
n
>>>>> confirmed. It's completely unrestricted, not being bound to any
>>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>>>
>>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> Thank you very much for sharing your proposal!
>>>>>>
>>>>>> I think there's one thing about the second part of your proposal tha=
t
>>>>>> 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 implicat=
ion
>>>>>> therefore that to safely spend a transaction with an ephemeral ancho=
r, all
>>>>>> outputs must be spent? Thanks!
>>>>>>
>>>>>> Best,
>>>>>> Arik
>>>>>>
>>>>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote=
:
>>>>>>
>>>>>> Hello Everyone,
>>>>>>
>>>>>> Following up on the "V3 Transaction" discussion here
>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septemb=
er/020937.html
>>>>>> , I would like to elaborate a bit further on some potential follow-o=
n 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 m=
empool
>>>>>> due to the existing mempool package it is being added to already bei=
ng 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 ver=
sion
>>>>>> with their anchor and package RBF the other commitment transaction s=
afely.
>>>>>>
>>>>>> What if there's only one version of the commitment transaction, such
>>>>>> as in other protocols like duplex payment channels, eltoo? What abou=
t 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 detect=
ed and
>>>>>> removed from the package proposal. You are then left with a single V=
3 child
>>>>>> transaction, which is then proposed for entry into the mempool. In t=
he case
>>>>>> of another parent output already being spent, this is simply rejecte=
d,
>>>>>> 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 it=
s
>>>>>> 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 w=
orked
>>>>>> 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 simple=
r in
>>>>>> case the child-spend is somehow evicted, guaranteeing the parent wil=
l 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 arbitra=
ry
>>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be min=
iscript
>>>>>> compatible to begin with...
>>>>>>
>>>>>> c) *Anyone* can bump the transaction, without any transaction key
>>>>>> material. This is essentially achieving Jeremy's Transaction Sponsor=
s (
>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Septemb=
er/018168.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-Octob=
er/002240.html)
>>>>>> is superseded by this logic, as we are not restricted to two immedia=
tely
>>>>>> spendable output scenarios. In its place, robust multi-party fee bum=
ping 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 pain=
ful.
>>>>>> 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-Februar=
y/015717.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 mine=
rs have
>>>>>>    incentive to make the smallest utxo burn transaction to claim tho=
se funds.
>>>>>>    They just confirmed your parent transaction anyways, so do we car=
e?
>>>>>>    2.
>>>>>>
>>>>>>    SIGHASH_GROUP like constructs would allow uncommitted ephemeral
>>>>>>    anchors to be added at spend time, depending on spending requirem=
ents.
>>>>>>    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 toda=
y.
>>>>>>
>>>>>>
>>>>>> 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 f=
or the sake of
>>>>>> progress.
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>

--000000000000cb8ff605f33f5b5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello again dev,</div><div><br></div>Due to the inter=
est in the proposal and the prodding of certain folks, I&#39;ve written up =
a short draft BIP of the Ephemeral Anchors idea here:=C2=A0<a href=3D"https=
://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.me=
diawiki">https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephem=
eralanchors.mediawiki</a><div><br></div><div>The pull request at=C2=A0<a hr=
ef=3D"https://github.com/bitcoin/bitcoin/pull/26403">https://github.com/bit=
coin/bitcoin/pull/26403</a> has been refreshed on top of the latest V3 prop=
osal, but the BIP itself is unaffected.</div><div><br></div><div>Cheers,</d=
iv><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders &lt;<a href=
=3D"mailto:gsanders87@gmail.com">gsanders87@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
Small update.</div><div><br></div>A bit ago I went ahead and implemented ep=
hemeral anchors on top of the V3 proposal to see what the complexity looks =
like:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/26403" target=
=3D"_blank">https://github.com/bitcoin/bitcoin/pull/26403</a><div><br></div=
><div>Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not=
 camp the value that is used elsewhere.</div><div><br></div><div>Please let=
 me know if you have any early feedback on this!</div><div><br></div><div>G=
reg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders &lt;<a href=3D"mailto=
:gsanders87@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">So it doesn&#39;t look like I&#39;m ignoring a good question:<div><br></=
div><div>No solid noninteractive ideas, unless we get some very flexible si=
ghash softfork. Interactively, I think you can get collaborative fee bumps =
under the current consensus regime and ephemeral=C2=A0anchors. The child wi=
ll just be built with inputs from different people.</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 20=
22 at 11:12 AM James O&#39;Beirne &lt;<a href=3D"mailto:james.obeirne@gmail=
.com" target=3D"_blank">james.obeirne@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;=
m also very happy to see this proposal, since it gets us closer to having a=
 mechanism that allows the contribution to  feerate in an &quot;unauthentic=
ated&quot; way, which seems to be a very helpful feature for vaults and oth=
er contracting protocols.</div><div><br></div><div>One possible advantage o=
f the sponsors interface -- and I&#39;m curious for your input here Greg --=
 is that with sponsors, assuming we relaxed the &quot;one sponsor per spons=
oree&quot; constraint, multiple uncoordinated parties can collaboratively b=
ump a tx&#39;s feerate. A simple example would be a batch withdrawal from a=
n exchange could be created with a low feerate, and then multiple users wit=
h a vested interest of expedited confirmation could all &quot;chip in&quot;=
 to raise the feerate with multiple sponsor transactions. <br></div><div><b=
r></div><div>Having a single ephemeral output seems to create a situation w=
here a single UTXO has to shoulder the burden of CPFPing a package. Is ther=
e some way we could (possibly later) amend the ephemeral anchor interface t=
o allow for this kind of collaborative sponsoring? Could you maybe see &quo=
t;chained&quot; ephemeral anchors that would allow this?<br></div><div><br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">Excellent proposal and I agree it does capture much of the spir=
it of sponsors w.r.t. how they might be used for V3 protocols.</div><div cl=
ass=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,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">The only drawbacks I see=C2=A0is they don&#39;t work for lower tx version=
 contracts, so there&#39;s still something to be desired there, and that th=
e requirement to sweep the output must be incentive compatible for the mine=
r, or else they won&#39;t enforce it (pass the buck onto the future bitcoin=
ers). The Ephemeral UTXO concept can be a consensus rule (see=C2=A0<a href=
=3D"https://rubin.io/public/pdfs/multi-txn-contracts.pdf" target=3D"_blank"=
>https://rubin.io/public/pdfs/multi-txn-contracts.pdf</a> &quot;Intermediat=
e UTXO&quot;) we add later on in lieu of managing them by incentive, so may=
be it&#39;s a cleanup one can punt.</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)">One question I have is if V=
3 is designed for lightning, and this is designed for lightning, is there a=
ny sense in requiring these outputs for v3? That might help with e.g. anony=
mity set, as well as potentially keep the v3 surface smaller.</div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, =
Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">&gt; does that effectively mark output=
 B as unspendable once the child gets confirmed?<div><br></div><div>Not at =
all. It&#39;s a normal spend like before, since the parent has been confirm=
ed. It&#39;s completely unrestricted, not being bound to any V3/ephemeral a=
nchor restrictions on size, version, etc.</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 18, 2022 at 11:4=
7 AM Arik Sosman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div><u></u><div><div>Hi Greg,<br></div><div><br></div><div>Thank you very m=
uch for sharing your proposal!</div><div><br></div><div>I think there&#39;s=
 one thing about the second part of your proposal that I&#39;m missing. Spe=
cifically, 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 O=
P_TRUE, does that effectively mark output B as unspendable once the child g=
ets confirmed? If so, isn&#39;t the implication therefore that to safely sp=
end a transaction with an ephemeral anchor, all outputs must be spent? Than=
ks!<br></div><div><br></div><div>Best,<br></div><div>Arik</div><div><br></d=
iv><div>On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrot=
e:<br></div><blockquote type=3D"cite" id=3D"m_6295189323921585862m_79166807=
40001169827m_-7137361365701771057m_5142274361577099701m_8177486709224577946=
m_-7024055043742391057m_4368086065316228638qt"><div dir=3D"ltr"><span id=3D=
"m_6295189323921585862m_7916680740001169827m_-7137361365701771057m_51422743=
61577099701m_8177486709224577946m_-7024055043742391057m_4368086065316228638=
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 sty=
le=3D"color:rgb(0,0,0);background-color:transparent;font-variant-numeric:no=
rmal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre=
-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Hel=
lo Everyone,</span></span></span><br></p><div><br></div><p dir=3D"ltr" styl=
e=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-wrap"><sp=
an style=3D"font-family:Arial"><span style=3D"font-size:11pt">Following up =
on the &quot;V3 Transaction&quot; discussion here <a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html" targe=
t=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-S=
eptember/020937.html</a> , I would like to elaborate a bit further on some =
potential follow-on work that would make pinning severely constrained in ma=
ny 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-variant-numeric:normal;font-v=
ariant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><spa=
n style=3D"font-family:Arial"><span style=3D"font-size:11pt">V3 transaction=
s 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 co=
sts 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 words,=
 a fee-paying transaction cannot enter the mempool due to the existing memp=
ool 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-he=
ight: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 style=3D"=
font-family:Arial"><span style=3D"font-size:11pt">Zooming into the V3 simpl=
ified scenario for sake of discussion, though this problem exists in genera=
l today:</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: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"><span s=
tyle=3D"font-family:Arial"><span style=3D"font-size:11pt">V3 transactions r=
estrict the package limit of a V3 package to one parent and one child. If t=
he parent transaction includes two outputs which can be immediately spent b=
y separate parties, this allows one party to disallow a spend from the othe=
r. In Gloria&#39;s proposal for ln-penalty, this is worked around by reduci=
ng the number of anchors per commitment transaction to 1, and each version =
of the commitment transaction has a unique party&#39;s key on it. The hones=
t participant can spend their version with their anchor and package RBF the=
 other commitment transaction safely.</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:baseline;=
white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font=
-size:11pt">What if there&#39;s only one version of the commitment transact=
ion, such as in other protocols like duplex payment channels, eltoo? What a=
bout multi party payments?</span></span></span><br></p><div><br></div><p di=
r=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-numeri=
c:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space=
:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt"=
>In the package RBF proposal, if the parent transaction is identical to an =
existing transaction in the mempool, the parent will be detected and remove=
d from the package proposal. You are then left with a single V3 child trans=
action, which is then proposed for entry into the mempool. In the case of a=
nother parent output already being spent, this is simply rejected, regardle=
ss of feerate of the new child.</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-n=
umeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-=
space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:=
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-he=
ight: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 style=3D"=
font-family:Arial"><span style=3D"font-size:11pt">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 sibling out of th=
e mempool and takes the one child slot. This would solve it, but is a new e=
viction paradigm that would need to be carefully worked through.</span></sp=
an></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);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-family=
:Arial"><span style=3D"font-size:11pt">2) Ephemeral Anchors (my real policy=
-only proposal)</span></span></span><br></p><div><br></div><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"c=
olor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fo=
nt-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">=
<span style=3D"font-family:Arial"><span style=3D"font-size:11pt">Ephemeral =
Anchors is a term which means an output is watermarked as an output that MU=
ST 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.</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 style=
=3D"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"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">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.</span><=
/span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.3=
8;margin-top:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);backgro=
und-color:transparent;font-variant-numeric:normal;font-variant-east-asian:n=
ormal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-fam=
ily:Arial"><span style=3D"font-size:11pt">Implications:</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:tr=
ansparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertic=
al-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><=
span style=3D"font-size:11pt">a) If the ephemeral anchor MUST be spent, we =
can allow *any* value, even dust, even 0, without worrying about bloating t=
he utxo set. We relax this policy for maximum smart contract flexibility an=
d 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"><sp=
an style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nume=
ric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-spa=
ce:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11p=
t">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 eph=
emeral anchor. This causes the 1 block CSV timelock on outputs to be remove=
d in these situations. This greatly magnifies composability of smart contra=
cts, as now we can do things like safely splice directly into new channels,=
 into statechains, your custodial wallet account, your cold wallet, whereve=
r, without requiring other wallets to support arbitrary scripts. Also it hu=
rts that 1 CSV time locked scripts may not be miniscript compatible to begi=
n 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-color:transparent;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><spa=
n style=3D"font-family:Arial"><span style=3D"font-size:11pt">c) *Anyone* ca=
n bump the transaction, without any transaction key material. This is essen=
tially achieving Jeremy&#39;s Transaction Sponsors (</span></span></span><a=
 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Septe=
mber/018168.html" style=3D"text-decoration-line:none" target=3D"_blank"><sp=
an style=3D"background-color:transparent;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;text-decoration-line:underline;vertical-align:base=
line;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D=
"font-size:11pt">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-September/018168.html</span></span></span></a><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 styl=
e=3D"font-family:Arial"><span style=3D"font-size:11pt">) proposal without c=
onsensus changes. As long as someone gets a fully signed parent, they can e=
xecute 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:0pt"><span style=3D"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"><span style=3D"font-fa=
mily:Arial"><span style=3D"font-size:11pt">d) Lightning Carve-out(</span></=
span></span><a href=3D"https://lists.linuxfoundation.org/pipermail/lightnin=
g-dev/2019-October/002240.html" style=3D"text-decoration-line:none" target=
=3D"_blank"><span style=3D"background-color:transparent;font-variant-numeri=
c:normal;font-variant-east-asian:normal;text-decoration-line:underline;vert=
ical-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"=
><span style=3D"font-size:11pt">https://lists.linuxfoundation.org/pipermail=
/lightning-dev/2019-October/002240.html</span></span></span></a><span style=
=3D"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"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt">)=C2=
=A0 is superseded by this logic, as we are not restricted to two immediatel=
y spendable output scenarios. In its place, robust multi-party fee bumping =
is possible.</span></span></span><br></p><div><br></div><p dir=3D"ltr" styl=
e=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-wrap"><sp=
an style=3D"font-family:Arial"><span 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 spends cannot pin=
 you. Batched payouts become a lot less painful. This was one of the motiva=
ting use cases that created the term =E2=80=9Cpinning=E2=80=9D in the first=
 place(</span></span></span><a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2018-February/015717.html" style=3D"text-decoration-lin=
e:none" target=3D"_blank"><span style=3D"background-color:transparent;font-=
variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:=
underline;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font=
-family:Arial"><span style=3D"font-size:11pt">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2018-February/015717.html</span></span></span></=
a><span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant=
-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;whit=
e-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-siz=
e:11pt">), even if LN/L2 discussion has largely overtaken it due to HTLC th=
eft risks.</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"><spa=
n style=3D"font-family:Arial"><span style=3D"font-size:11pt">Open Question(=
s):</span></span></span><br></p><div><br></div><ol style=3D"margin-top:0px;=
margin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:decimal;font-si=
ze:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;fon=
t-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:base=
line;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height: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:norma=
l;vertical-align:baseline;white-space:pre-wrap"><span style=3D"font-size:11=
pt">If we allow non-zero value in ephemeral outputs, does this open up a ME=
V 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 funds. They just =
confirmed your parent transaction anyways, so do we care?</span></span><br>=
</p></li><li dir=3D"ltr" style=3D"list-style-type:decimal;font-size:11pt;fo=
nt-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"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;ma=
rgin-bottom:0pt" role=3D"presentation"><span style=3D"background-color:tran=
sparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical=
-align:baseline;white-space:pre-wrap"><span style=3D"font-size:11pt">SIGHAS=
H_GROUP like constructs would allow uncommitted ephemeral anchors to be add=
ed at spend time, depending on spending requirements. SIGHASH_SINGLE alread=
y 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;mar=
gin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align=
:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span sty=
le=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><div><br></div><p di=
r=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-numeri=
c:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space=
:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"font-size:11pt"=
>Greg</span></span></span><br></p><div><br></div><p dir=3D"ltr" style=3D"li=
ne-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 styl=
e=3D"font-family:Arial"><span style=3D"font-size:11pt">0: With V3 transacti=
ons where you have &quot;veto power&quot; over all the inputs in that trans=
action. Therefore something like ANYONECANPAY is still broken. We need a mo=
re complex solution, which I=E2=80=99m punting for the sake of progress.</s=
pan></span></span><br></p></span></div><div>_______________________________=
________________<br></div><div>bitcoin-dev mailing list<br></div><div><a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a><br></div><div><a href=3D"https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div><div>=
<br></div></blockquote><div><br></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>
</div></blockquote></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>
_______________________________________________<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>
</blockquote></div>
</blockquote></div>

--000000000000cb8ff605f33f5b5e--