MIME-Version: 1.0
References: <Jilb-w5AFlMx809pICIKdhhj3xBynWDlPtRTiJVIoxnC5_1gi6sK7rhOjl4e5HeMr7DDk9NjLdSGc8nWXaDIePDsjroiTd5xLU0xL3_INiY=@protonmail.com>
In-Reply-To: <Jilb-w5AFlMx809pICIKdhhj3xBynWDlPtRTiJVIoxnC5_1gi6sK7rhOjl4e5HeMr7DDk9NjLdSGc8nWXaDIePDsjroiTd5xLU0xL3_INiY=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 22 Sep 2020 09:52:55 -0400
Message-ID: <CALZpt+E19yodt3_LG+5x7G-bZ=6egrcGsTMR1+75aePNa1YPfw@mail.gmail.com>
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000070cb6405afe7498f"
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
 TXID Dependencies for Fee Sponsoring
Precedence: list

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

Hello AC,

Yes that's a real issue. In the context of multi-party protocols, you may
pre-signed transactions with the feerate of _today_ and then only going to
be broadcast later with a feerate of _tomorrow_.
In that case the pre-signed feerate may be so low that the transaction
won't even propagate across network mempools with a local minimal feerate
higher.

That's why you want to be sure that the feerate of your  package of
transactions (either sponsor+sponsoree or parent+CPFP) is going to be
evaluated as a whole to decide acceptance of each element of the package.

Antoine


Le mar. 22 sept. 2020 =C3=A0 03:28, ArmchairCryptologist via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Not sure if I'm missing something, but I'm curious if (how) this will wor=
k
> if the sponsored transaction's feerate is so low that it has been largely
> evicted from mempools due to fee pressure, and is too low to be widely
> accepted when re-broadcast? It seems to me that the following requirement
>
> >1. The Sponsor Vector's entry must be present in the mempool
>
> means that you enter a catch-22 where the sponsor transaction cannot be
> broadcast because the sponsored transaction is not in the mempool, and th=
e
> sponsored transaction cannot be (re-)broadcast because the fee is too low=
.
> This requirement might therefore need to be revised.
>
> There is of course no global mempool, but RBF by its nature would still
> work in this case, by replacing the transaction if it exists and insertin=
g
> it if it does not.
>
> --AC
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div><div><div>Hello AC,<br><br></div>Yes that&#39;s a rea=
l issue. In the context of multi-party protocols, you may pre-signed transa=
ctions with the feerate of _today_ and then only going to be broadcast late=
r with a feerate of _tomorrow_.<br></div>In that case the pre-signed feerat=
e may be so low that the transaction won&#39;t even propagate across networ=
k mempools with a local minimal feerate higher.<br><br></div><div>That&#39;=
s why you want to be sure that the feerate of your=C2=A0 package of transac=
tions (either sponsor+sponsoree or parent+CPFP) is going to be evaluated as=
 a whole to decide acceptance of each element of the package.<br><br></div>=
<div>Antoine<br></div><div>=C2=A0</div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 22 sept. 2020 =C3=A0=C2=
=A003:28, ArmchairCryptologist via bitcoin-dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>Not sure if I&#39;m missing something, but I&#39;m curious if =
(how) this will work if the sponsored transaction&#39;s feerate is so low t=
hat it has been largely evicted from mempools due to fee pressure, and is t=
oo low to be widely accepted when re-broadcast? It seems to me that the fol=
lowing requirement<br></div><div><br></div><div>&gt;1. The Sponsor Vector&#=
39;s entry must be present in the mempool<br></div><div><br></div><div>mean=
s that you enter a catch-22 where the sponsor transaction cannot be broadca=
st because the sponsored transaction is not in the mempool, and the sponsor=
ed transaction cannot be (re-)broadcast because the fee is too low. This re=
quirement might therefore need to be revised.<br></div><div><br></div><div>=
There is of course no global mempool, but RBF by its nature would still wor=
k in this case, by replacing the transaction if it exists and inserting it =
if it does not.<br></div><div><br></div><div>--AC</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>

--00000000000070cb6405afe7498f--