path: root/c6/f60d1950c25e15ab906b8dcc8b5c18ff43bd91

Return-Path: <johanth@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E8057C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 09:37:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id C971960597
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 09:37:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C971960597
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=NIhpzeRd
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 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_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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Cvh22Dqx6ya8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 09:37:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 96B316006A
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com
 [IPv6:2607:f8b0:4864:20::b33])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 96B316006A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 09:37:13 +0000 (UTC)
Received: by mail-yb1-xb33.google.com with SMTP id y72so1128926yby.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 02:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=To9AxH5ztWMk70ummW/wiXWntvoFC0iIb9ruTFaR3GI=;
 b=NIhpzeRdMcnC/ksQt5SO0KvGZMTzJaeK4Q2YdeoinSI693hE4v9HRsSs7bwUonAANh
 PKYzpwL3+R8DZ4o7FAbwA8+YxynzYtzfgvrS5+LrbvWIFQ6YnWqpVZMVNzLu0898wTGi
 BWDhP6lcQMmJ7N9Lm4JmahE39cZ//EmtVS0dMnsGZK7h1+sp1BZX/Qb74NMAHZCzUys5
 /bXoXIf/KAkr69awwfKQaatMgl5lJYzKirIiDZXldntKpnWJjzuYtDUacJGYjhW4+DRJ
 uyoQLPix2iyWscekk+JLfbw8g2Zk82eyNTWLbkal0l5P/mmDX0zvZN4CIwATiwvBSbZm
 5CHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=To9AxH5ztWMk70ummW/wiXWntvoFC0iIb9ruTFaR3GI=;
 b=HmTZUM5VThyDW2SwdkDzmuy2WtcMvgTwy/2zxrf/5X0yKZRJj+N8xJVkYjxIf8Xob5
 8/n9ak1EiNoMMWMF5C9MVGcJwHWER+GV01m0KbmcRoKsk7qZaLvrxXtwJEa7Iq3oE2zn
 lEFoiZC7Yrh6Jl590PZATBnAitt7nmIBqE+RKcjnWqSNnd2lFPMamMwwEMyDCGc8KLka
 J1adIJHWUfqjR9XlBVxYwtaPkmh2p0UkWgNMuCxnI3j32XEhtuezh3Ij8D6sq455Uo/O
 5xTfYJPRGhhzcJuExwZhQUvLRhUYw0lBcHff7D5At1kn2449SBJLO9GxvDcFjAqYbYl7
 zTTw==
X-Gm-Message-State: ACrzQf0RzuxFUKHq18iKO9ftvyqIb9bIEtdE4wj/RFAfn36EMPziGU3D
 2mHlhqfvu4cjp8ICWdEP2Hnq+wAcUyVFBm8DRLRQjMAG3GqRmfM3
X-Google-Smtp-Source: AMsMyM7ZTeaAgLFxHjwD2z/6gzFDi5JJcVpTygV7nmYRo7kuRvGU9bZU/D3w6WAjcM+LtCj9fbOWa7w9EQ4pdLrALSI=
X-Received: by 2002:a25:4942:0:b0:6bd:29b0:3ed8 with SMTP id
 w63-20020a254942000000b006bd29b03ed8mr44718153yba.79.1666863432369; Thu, 27
 Oct 2022 02:37:12 -0700 (PDT)
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>
In-Reply-To: <CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>
From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
Date: Thu, 27 Oct 2022 11:37:01 +0200
Message-ID: <CAD3i26DCm0DjpFwFfzBB=os+Z8ZA=JnK6tQQ_gqu8Ti5S7e8BQ@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c68ce005ec00e243"
X-Mailman-Approved-At: Thu, 27 Oct 2022 09:49:52 +0000
Cc: Jeremy Rubin <j@rubin.io>
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: Thu, 27 Oct 2022 09:37:16 -0000

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

Hi, Greg.

I find this proposal super interesting, and IIUC something that seems
fairly "safe" to allow (assuming V3).

For LN having the commitment transaction pay a non-zero fee is a cause for
a lot of complexity in the channel state machine. Something like this would
remove a lot of edge cases and add more flexibility around adding HTLCs.

Thanks!

- Johan

On Thu, Oct 20, 2022 at 3:42 PM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 unde=
r
> the current consensus regime and ephemeral anchors. The child will just b=
e
> 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 vaul=
ts
>> 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 the=
n
>> multiple users with a vested interest of expedited confirmation could al=
l
>> "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 so=
me
>> way we could (possibly later) amend the ephemeral anchor interface to al=
low
>> 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 the
>>> requirement to sweep the output must be incentive compatible for the mi=
ner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners=
).
>>> 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 f=
or
>>> v3? That might help with e.g. anonymity set, as well as potentially kee=
p
>>> 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 been
>>>> 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 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 implicati=
on
>>>>> therefore that to safely spend a transaction with an ephemeral anchor=
, 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-Septembe=
r/020937.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 b=
e made
>>>>> and propagated, it costs the expected amount of fees to do so. This i=
s 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 me=
mpool
>>>>> due to the existing mempool package it is being added to already bein=
g too
>>>>> large in count or vsize.
>>>>>
>>>>> Zooming into the V3 simplified scenario for sake of discussion, thoug=
h
>>>>> 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 t=
o
>>>>> disallow a spend from the other. In Gloria's proposal for ln-penalty,=
 this
>>>>> is worked around by reducing the number of anchors per commitment
>>>>> transaction to 1, and each version of the commitment transaction has =
a
>>>>> unique party's key on it. The honest participant can spend their vers=
ion
>>>>> with their anchor and package RBF the other commitment transaction sa=
fely.
>>>>>
>>>>> 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 t=
o
>>>>> an existing transaction in the mempool, the parent will be detected a=
nd
>>>>> 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 th=
e 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 i=
s
>>>>> paying "enough" to bump spends from the same parent, it knocks its si=
bling
>>>>> 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 thr=
ough.
>>>>>
>>>>> 2) Ephemeral Anchors (my real policy-only proposal)
>>>>>
>>>>> Ephemeral Anchors is a term which means an output is watermarked as a=
n
>>>>> output that MUST be spent in a V3 package. We mark this anchor by bei=
ng the
>>>>> bare script `OP_TRUE` and of course make these outputs standard to re=
lay
>>>>> 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 r=
elax
>>>>> 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 o=
f 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 n=
ew
>>>>> channels, into statechains, your custodial wallet account, your cold
>>>>> wallet, wherever, without requiring other wallets to support arbitrar=
y
>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be mini=
script
>>>>> 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-Septembe=
r/018168.html)
>>>>> proposal without consensus changes. As long as someone gets a fully s=
igned
>>>>> 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-Octobe=
r/002240.html)
>>>>> is superseded by this logic, as we are not restricted to two immediat=
ely
>>>>> spendable output scenarios. In its place, robust multi-party fee bump=
ing 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 painf=
ul.
>>>>> 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=
/015717.html),
>>>>> even if LN/L2 discussion has largely overtaken it due to HTLC theft r=
isks.
>>>>>
>>>>> 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 dire=
ctly to
>>>>>    fees, and add their own additional fees on top, otherwise miners h=
ave
>>>>>    incentive to make the smallest utxo burn transaction to claim thos=
e funds.
>>>>>    They just 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 requireme=
nts.
>>>>>    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 fo=
r 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
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi, Greg.<input name=3D"virtru-metadata" =
type=3D"hidden" value=3D"{&quot;email-policy&quot;:{&quot;disableCopyPaste&=
quot;:false,&quot;disablePrint&quot;:false,&quot;disableForwarding&quot;:fa=
lse,&quot;enableNoauth&quot;:false,&quot;expandedWatermarking&quot;:false,&=
quot;expires&quot;:false,&quot;sms&quot;:false,&quot;expirationNum&quot;:1,=
&quot;expirationUnit&quot;:&quot;days&quot;,&quot;isManaged&quot;:false,&qu=
ot;persistentProtection&quot;:false},&quot;attachments&quot;:{},&quot;compo=
se-id&quot;:&quot;8&quot;,&quot;compose-window&quot;:{&quot;secure&quot;:fa=
lse}}"><div><br></div><div>I find this proposal super interesting, and IIUC=
 something that seems fairly=C2=A0&quot;safe&quot; to allow (assuming V3).<=
/div><div><br></div><div>For LN having the commitment=C2=A0transaction pay =
a non-zero fee is a cause for a lot of complexity in the channel state mach=
ine. Something like this would remove a lot of edge cases and add more flex=
ibility around adding HTLCs.</div><div><br></div><div>Thanks!</div><div><br=
></div><div>- Johan</div></div><br><div class=3D"gmail_quote" style=3D""><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 20, 2022 at 3:42 PM Greg Sa=
nders via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote 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"ltr">So it doesn&#=
39;t look like I&#39;m ignoring a good question:<div><br></div><div>No soli=
d noninteractive ideas, unless we get some very flexible sighash softfork. =
Interactively, I think you can get collaborative fee bumps under the curren=
t consensus regime and ephemeral=C2=A0anchors. The child will just be built=
 with inputs from different people.</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 2022 at 11:12 AM J=
ames O&#39;Beirne &lt;<a href=3D"mailto:james.obeirne@gmail.com" target=3D"=
_blank">james.obeirne@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I&#39;m also very ha=
ppy to see this proposal, since it gets us closer to having a mechanism tha=
t allows the contribution to  feerate in an &quot;unauthenticated&quot; way=
, which seems to be a very helpful feature for vaults and other contracting=
 protocols.</div><div><br></div><div>One possible advantage of 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 sponsoree&quot; con=
straint, multiple uncoordinated parties can collaboratively bump a tx&#39;s=
 feerate. A simple example would be a batch withdrawal from an exchange cou=
ld be created with a low feerate, and then multiple users with a vested int=
erest of expedited confirmation could all &quot;chip in&quot; to raise the =
feerate with multiple sponsor transactions. <br></div><div><br></div><div>H=
aving a single ephemeral output seems to create a situation where a single =
UTXO has to shoulder the burden of CPFPing a package. Is there some way we =
could (possibly later) amend the ephemeral anchor interface to allow for th=
is kind of collaborative sponsoring? Could you maybe see &quot;chained&quot=
; ephemeral anchors that would allow this?<br></div><div><br></div></div><b=
r><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">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"><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Excellent proposal and I a=
gree it does capture much of the spirit of sponsors w.r.t. how they might b=
e used for V3 protocols.</div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The only dr=
awbacks I see=C2=A0is they don&#39;t work for lower tx version contracts, s=
o there&#39;s still something to be desired there, and that the requirement=
 to sweep the output must be incentive compatible for the miner, or else th=
ey won&#39;t enforce it (pass the buck onto the future bitcoiners). The Eph=
emeral UTXO concept can be a consensus rule (see=C2=A0<a href=3D"https://ru=
bin.io/public/pdfs/multi-txn-contracts.pdf" target=3D"_blank">https://rubin=
.io/public/pdfs/multi-txn-contracts.pdf</a> &quot;Intermediate UTXO&quot;) =
we add later on in lieu of managing them by incentive, so maybe it&#39;s a =
cleanup one can punt.</div><div style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">One question I=
 have is if V3 is designed for lightning, and this is designed for lightnin=
g, is there any sense in requiring these outputs for v3? That might help wi=
th e.g. anonymity set, as well as potentially keep the v3 surface smaller.<=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; does that effectivel=
y 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 confirmed. It&#39;s completely unrestricted, not being bound to any V=
3/ephemeral anchor restrictions on size, version, etc.</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 18,=
 2022 at 11:47 AM Arik Sosman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div><u></u><div><div>Hi Greg,<br></div><div><br></div><div>Tha=
nk you very much for sharing your proposal!</div><div><br></div><div>I thin=
k there&#39;s one thing about the second part of your proposal that I&#39;m=
 missing. Specifically, assuming the scenario of a v3 transaction with thre=
e outputs, A, B, and the ephemeral anchor OP_TRUE. If a child transaction s=
pends A and OP_TRUE, does that effectively mark output B as unspendable onc=
e the child gets confirmed? If so, isn&#39;t the implication therefore that=
 to safely spend a transaction with an ephemeral anchor, all outputs must b=
e spent? Thanks!<br></div><div><br></div><div>Best,<br></div><div>Arik</div=
><div><br></div><div>On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bit=
coin-dev wrote:<br></div><blockquote type=3D"cite" id=3D"m_6448368428778965=
701m_-7137361365701771057m_5142274361577099701m_8177486709224577946m_-70240=
55043742391057m_4368086065316228638qt"><div dir=3D"ltr"><span id=3D"m_64483=
68428778965701m_-7137361365701771057m_5142274361577099701m_8177486709224577=
946m_-7024055043742391057m_4368086065316228638qt-gmail-docs-internal-guid-2=
d3e64aa-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);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">Hello Everyone,</span></span></s=
pan><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;ver=
tical-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial=
"><span style=3D"font-size:11pt">Following up on the &quot;V3 Transaction&q=
uot; discussion here <a href=3D"https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2022-September/020937.html" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.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></span></sp=
an><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-t=
op:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:=
transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vert=
ical-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"=
><span style=3D"font-size:11pt">V3 transactions may solve bip125 rule#3 and=
 rule#5 pinning attacks under some constraints[0]. This means that when a r=
eplacement is to be made and propagated, it costs the expected amount of fe=
es to do so. This is a great start. What&#39;s left in this subset of pinni=
ng is *package limit* pinning. In other words, a fee-paying transaction can=
not 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;marg=
in-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 styl=
e=3D"font-size:11pt">Zooming into the V3 simplified scenario for sake of di=
scussion, though this problem exists in general 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: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"><span style=3D"font-family:Arial"><s=
pan 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 include=
s two outputs which can be immediately spent by separate parties, this allo=
ws one party to disallow a spend from the other. In Gloria&#39;s proposal f=
or 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&#39;s key on it. The honest 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: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">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></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);ba=
ckground-color:transparent;font-variant-numeric:normal;font-variant-east-as=
ian:normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D"fon=
t-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 m=
empool, the parent will be detected and removed from the package proposal. =
You are then left with a single V3 child transaction, which is then propose=
d 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 chil=
d.</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-ea=
st-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 s=
olutions, 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;ma=
rgin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:transpare=
nt;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-alig=
n:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span st=
yle=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 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.</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">2) Ephemeral Anchors (my real policy-only proposal)</span></spa=
n></span><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;ma=
rgin-top:0pt;margin-bottom:0pt"><span style=3D"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"><span style=3D"font-family:=
Arial"><span style=3D"font-size:11pt">Ephemeral Anchors is a term which mea=
ns 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.</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">Also as a simplifying assumption,=
 we require the parent transaction with such an output to be 0-fee. This ma=
kes mempool reasoning simpler in case the child-spend is somehow evicted, g=
uaranteeing the parent will be as well.</span></span></span><br></p><div><b=
r></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bott=
om:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-v=
ariant-numeric:normal;font-variant-east-asian:normal;vertical-align:baselin=
e;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"fo=
nt-size:11pt">Implications:</span></span></span><br></p><div><br></div><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><spa=
n style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-numer=
ic:normal;font-variant-east-asian:normal;vertical-align:baseline;white-spac=
e: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 the utxo set. We relax this p=
olicy for maximum smart contract flexibility and specification simplicity..=
</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">b) Since this anchor MUST=
 be spent, any spending of other outputs in the same parent transaction MUS=
T directly double-spend prior spends of the ephemeral anchor. This causes t=
he 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 cust=
odial wallet account, your cold wallet, wherever, without requiring other w=
allets to support arbitrary scripts. Also it hurts that 1 CSV time locked s=
cripts may not be miniscript compatible to begin with...</span></span></spa=
n><br></p><div><br></div><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"color:rgb(0,0,0);background-color:t=
ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;verti=
cal-align:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial">=
<span style=3D"font-size:11pt">c) *Anyone* can bump the transaction, withou=
t any transaction key material. This is essentially achieving Jeremy&#39;s =
Transaction Sponsors (</span></span></span><a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2020-September/018168.html" style=3D"tex=
t-decoration-line:none" target=3D"_blank"><span style=3D"background-color:t=
ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-=
decoration-line:underline;vertical-align:baseline;white-space:pre-wrap"><sp=
an style=3D"font-family:Arial"><span 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);background-color:transpa=
rent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-al=
ign:baseline;white-space:pre-wrap"><span style=3D"font-family:Arial"><span =
style=3D"font-size:11pt">) proposal without consensus changes. As long as s=
omeone gets a fully signed parent, they can execute a bump with minimal wal=
let tooling. If a transaction author doesn=E2=80=99t want a =E2=80=9Csponso=
r=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-botto=
m:0pt"><span style=3D"color:rgb(0,0,0);background-color:transparent;font-va=
riant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline=
;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"fon=
t-size:11pt">d) Lightning Carve-out(</span></span></span><a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html=
" style=3D"text-decoration-line:none" target=3D"_blank"><span style=3D"back=
ground-color:transparent;font-variant-numeric:normal;font-variant-east-asia=
n: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/lightning-dev/2019-October/002=
240.html</span></span></span></a><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">)=C2=A0 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.</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">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 l=
ot 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></span></span><a h=
ref=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Februar=
y/015717.html" style=3D"text-decoration-line:none" target=3D"_blank"><span =
style=3D"background-color:transparent;font-variant-numeric:normal;font-vari=
ant-east-asian:normal;text-decoration-line:underline;vertical-align:baselin=
e;white-space:pre-wrap"><span style=3D"font-family:Arial"><span style=3D"fo=
nt-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-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap"><span style=3D=
"font-family:Arial"><span style=3D"font-size:11pt">), even if LN/L2 discuss=
ion has largely overtaken 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:0=
pt;margin-bottom:0pt"><span style=3D"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"><span style=3D"font-family:Arial"><sp=
an 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-size:11pt;font-family:Arial;color:r=
gb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-var=
iant-east-asian:normal;vertical-align:baseline;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:normal;vertical-align:baseline;white=
-space:pre-wrap"><span style=3D"font-size:11pt">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 f=
ees on top, otherwise miners have incentive to make the smallest utxo burn =
transaction to claim those funds. They just confirmed your parent transacti=
on 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-numeric:normal;font-variant-ea=
st-asian:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr=
" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"prese=
ntation"><span style=3D"background-color:transparent;font-variant-numeric:n=
ormal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pr=
e-wrap"><span style=3D"font-size:11pt">SIGHASH_GROUP like constructs would =
allow uncommitted ephemeral anchors to be added at spend time, depending on=
 spending requirements. SIGHASH_SINGLE already allows this.</span></span><b=
r></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=
"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">Hopefull=
y this gives people something to consider as we move forward in thinking ab=
out mempool design within the constraints we have today.</span></span></spa=
n><br></p><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"color:rgb(0,0,0);bac=
kground-color:transparent;font-variant-numeric:normal;font-variant-east-asi=
an: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"line-height:1.38;margin-top:0pt;=
margin-bottom:0pt"><span style=3D"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"><span style=3D"font-family:Arial"><span =
style=3D"font-size:11pt">0: With V3 transactions where you have &quot;veto =
power&quot; over all the inputs in that transaction. Therefore something li=
ke ANYONECANPAY 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><d=
iv>bitcoin-dev mailing list<br></div><div><a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-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>
_______________________________________________<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></div>

--000000000000c68ce005ec00e243--