path: root/31/480385e16a302b4db555191874b6bbbecec397

Return-Path: <gloriajzhao@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4C03CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 May 2022 01:13:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 39F8441602
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 May 2022 01:13:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 nRxxyP7-T8qq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 May 2022 01:13:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [IPv6:2607:f8b0:4864:20::b2d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0278A414C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 May 2022 01:13:55 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id i11so28390094ybq.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 May 2022 18:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=KVx5PGjyi8QUd7Ke3nFWDIPh22zsbcxc1w6igi4IeBE=;
 b=QD2JFiWFZKJ8kdwzXwfO07f8PKgudhk4HpYFP/YHg3FZAS5k1kvg38SGk36ONxZnql
 /j5lowyWD8mKzfH69TCVgRZWjRBmvvT9BLFgED+6tbFuFOxE77yIeWp51MV24Bkl4SEp
 Cdf8jPWPis0j8PfeQmhyPMyVDX/3+0Gdpd8iF+Ho1QkWiV25Ak9JOaXvGM5/XKLmfsPx
 QRWSc8o6lylQf9WMzjhu1ffhsieN7SwWfLrGhWX40lfMIpVYyTk+Mpg2Mav70d617Zz9
 K8pNNpwMhSpv5LbPi7BPy3nZRMUznJexTB6V4zWOegllztkWjVOZVQWnaWZC03mCga5N
 QmSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=KVx5PGjyi8QUd7Ke3nFWDIPh22zsbcxc1w6igi4IeBE=;
 b=0qOcqbdi9EqwIjtmyGb17Lc+AB61L/njrANHbXFG95me+UYYB6UEep20EnER1oYYk/
 wY67Sjor+d9XIh2xcEHsGJqdY7nrEXv+FnhxKeMFh8XRSMuwWpJNYWL9k102Nmq2jO6C
 PxMFyaf89F0oJMT7+650NBnBMyZBC4kOeYyZzp0nPV7NfQ72a3ht+MbxmZFFuZofPufH
 Wi1rdXruymcsipjTSVO+g/AYNAafSuMWn6r3rngcVaooE1GBWVle/sFmmklZ+xHVUAtE
 edJ1VHnpt3i2nyb4QMucyjgzoTQaoHYV8WGGtr8GjmP/EXnk3P70MXXBV+RB9Rbn8JCL
 U1Eg==
X-Gm-Message-State: AOAM530QxLeW8rfN1VVk+cr30DBGb/6p/9rEYblrLHhvDVYG3gkz8Fcp
 o8tUlHemew2agSosimx5U0mtyqbnEwf4TC3yA1qUNduj
X-Google-Smtp-Source: ABdhPJwn8ek1Mi0oDBhtJSki2idrnVkPqVMd7Re2n4dyI/o1cgBPXvp1/yslnPg7mBJmEn51UqQSmtllbV0svE6zfK4=
X-Received: by 2002:a25:d908:0:b0:652:e0a4:c0ec with SMTP id
 q8-20020a25d908000000b00652e0a4c0ecmr438060ybg.356.1653354834880; Mon, 23 May
 2022 18:13:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
 <20220518003531.GA4402@erisian.com.au>
 <CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
 <20220523213416.GA6151@erisian.com.au>
In-Reply-To: <20220523213416.GA6151@erisian.com.au>
From: Gloria Zhao <gloriajzhao@gmail.com>
Date: Mon, 23 May 2022 21:13:43 -0400
Message-ID: <CAFXO6=KXToP2MFWQ1JVKX6jV++utw8E4Z13T4cH+mfgtyeUx_A@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009ee9c905dfb7ab67"
X-Mailman-Approved-At: Tue, 24 May 2022 08:34:27 +0000
Subject: Re: [bitcoin-dev] Package Relay Proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 01:13:58 -0000

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

Hi aj,

> if you're writing a protocol that's
> dependent on people seeing that a package as a whole pays a competitive
> feerate, don't you want to know in advance what conditions the network
> is going to impose on your transactions in order to consider them as a
> package?

I do think unifying the size/count constraints would result in a more
stable/easier to reason about interface for L2 devs. Then the requirement
for propagation is just a path of nodes that support v1 package relay, and
it=E2=80=99s implied their mempool policy supports it as well. Also seems l=
ike it
could be a fingerprinting problem for nodes to give very specific
count/size limits.

> (=E2=80=A6 maybe core's defaults should be reconsidered rather than stand=
ardised
as-is)

> Worst case, you could presumably do a new package relay version with
> different constraints, if needed.

Maybe this was my actual concern. I think the defaults are safe but it=E2=
=80=99s
not like they=E2=80=99ve been proven to be optimal. This creates an obstacl=
e to
changing them, especially if we want to make them smaller. But I think it=
=E2=80=99s
unlikely we=E2=80=99ll do that, and adding another version for new constrai=
nts
doesn=E2=80=99t seem too bad.


(Agreed with everything here, thanks for the feedback and clarifications!)
TLDR, making these changes:
- Count and size are implied by the version. Version 1 is specifically
child-with-unconfirmed-parents, where the whole package is at most 25
transactions and 101KvB.
- Announce sendpackages based on our own state. It=E2=80=99s ok to send
=E2=80=9Csendpackages=E2=80=9D if they sent fRelay=3Dfalse.
- At verack, require fRelay=3Dtrue and wtxidrelay if they sent sendpackages=
,
otherwise disconnect.
- If we get =E2=80=9Cgetpckgtxns=E2=80=9D or =E2=80=9Cpckgtxns=E2=80=9D wit=
hout having negotiated
=E2=80=9Csendpackages=E2=80=9D ahead of time, ignore, don=E2=80=99t disconn=
ect. Emphasize that the
intention is to validate all of the transactions received through
=E2=80=9Cpckgtxns=E2=80=9D together.

> If you're asking for the package for "D", would a response telling you:
>   txid_D (500 sat, 100vB)
>   txid_A (0 sat, 100vB)
>   txid_B (2000 sat, 100 vB)
> be better, in that case? Then the receiver can maybe do the logic
> themselves to figure out that they already have A in their mempool
> so it's fine, or not?

Right, I also considered giving the fees and sizes of each transaction in
the package in =E2=80=9Cpckginfo1=E2=80=9D. But I don=E2=80=99t think that =
information provides
additional meaning unless you know the exact topology, i.e. also know if
the parents have dependency relationships between them. For instance, in
the {A, B, D} package there, even if you have the information listed, your
decision should be different depending on whether B spends from A. The only
thing you know for sure about a child with direct parents is: if the
aggregate feerate is too low, you won=E2=80=99t want the child since it dep=
ends on
everyone else. If there=E2=80=99s a good-feerate transaction in there that =
doesn=E2=80=99t
have a dependency, you=E2=80=99re fine as long as someone sends it to you
individually.

Best,
Gloria

On Mon, May 23, 2022 at 2:34 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev
> wrote:
> > > Does it make sense for these to be configurable, rather than implied
> > > by the version?
> > > =E2=80=A6 would it be better to either just not do sendpackages
> > > at all if you're limiting ancestors in the mempool incompatibly
> > Effectively: if you=E2=80=99re setting your ancestor/descendant limits =
lower than
> > the default, you can=E2=80=99t do package relay. I wonder if this might=
 be
> > controversial, since it adds pressure to adhere to Bitcoin Core=E2=80=
=99s current
> > mempool policy? I would be happy to do it this way, though - makes thin=
gs
> > easier to implement.
>
> How about looking at it the other way: if you're writing a protocol that'=
s
> dependent on people seeing that a package as a whole pays a competitive
> feerate, don't you want to know in advance what conditions the network
> is going to impose on your transactions in order to consider them as a
> package? In that case, aren't the "depth" and "size" constraints things
> we should specify in a standard?
>
> (The above's not a rhetorical question; I'm not sure what the answer is.
> And even if it's "yes", maybe core's defaults should be reconsidered
> rather than standardised as-is)
>
> Worst case, you could presumably do a new package relay version with
> different constraints, if needed.
>
> > > > 5. If 'fRelay=3D=3Dfalse' in a peer's version message, the node mus=
t not
> > > >    send "sendpackages" to them. If a "sendpackages" message is
> > > > received by a peer after sending `fRelay=3D=3Dfalse` in their versi=
on
> > > > message, the sender should be disconnected.
> > > Seems better to just say "if you set fRelay=3Dfalse in your version
> > > message, you must not send sendpackages"? You already won't do packag=
es
> > > with the peer if they don't also announce sendpackages.
> > I guess, theoretically, if you allow bloom filters with this peer, it=
=E2=80=99s
> > plausible they=E2=80=99re saying =E2=80=9CfRelay=3Dfalse, I=E2=80=99ll =
send you a bloom filter
> later,
> > and I=E2=80=99ll also want to talk about packages.=E2=80=9D
>
> I was just meaning "it's okay to send VERSION fRelay=3Dtrue then immediat=
ely
> send WTXIDRELAY then immediately send SENDPACKAGES" without having to
> first verify what the other guy's fRelay was set to. On the other hand,
> you do already have to verify the other guy's version is high enough,
> but it would be kind-of nice to move towards just announcing the features
> you support, and not having to make it a multistep negotiation...
>
> > > Maybe: "You must not send sendpackages unless you also send
> wtxidrelay" ?
> > Do you mean if we get a verack, and the peer sent =E2=80=9Csendpackages=
=E2=80=9D but not
> > =E2=80=9Cwtxidrelay,=E2=80=9D we should disconnect them?
>
> Yes.
>
> > I have it as: we send a PCKG INV when this transaction=E2=80=99s feerat=
e is above
> > the fee filter, but one or more of its parents don=E2=80=99t. I don=E2=
=80=99t think using
> > ancestor feerate is better.
> > See this counterexample:
> >
> https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_gar=
den/abc_1parent_2kids.png
> > A (0fee) has 2 kids, B (3sat/vB) and C (20sat/vB), everything=E2=80=99s=
 the same
> > vsize. Let=E2=80=99s say the fee filter is 3sat/vB.
> > If we do it based on ancestor feerate, we won=E2=80=99t send B. But B i=
s actually
> > fine; C is paying for A.
>
> But that only works if the receiver also has C, in which case they also
> have A, and you don't need package relay to do anything with B? If they
> didn't have C already, then relaying {A,B} would be a waste of time,
> because {A,B} would be rejected as only paying 1.5sat/vB or whatever..
>
> If you switch it to being:
>
>   A (0 sats, 200vB)
>   B (2000 sats, 200vB, spends A:0)
>   C (200 sats, 200vB)
>   D (1000 sats, 200vB, sepnds A:1, C:0)
>
> then you get:
>
>   A alone =3D 0s/vB
>   B+A =3D 5s/vB
>
>   C alone =3D 1s/vB
>   D+C+A =3D 2s/vB
>   D+C =3D 3s/vB      (B+A already at 5s/vB)
>
> which I think recovers your point, while also having all the details
> only be dealing with direct parents.
>
> > > Are "getpckgtxns" / "pcktxns" really limited to packages, or are they
> > > just a general way to request a batch of transactions?
> > > Maybe call those messages "getbatchtxns" and "batchtxns" and allow
> them to
> > > be used more generally, potentially in ways unrelated to packages/cpf=
p?
> > Indeed, it=E2=80=99s a general way to request a batch of transactions. =
I=E2=80=99ll
> > highlight that it is =E2=80=9Call or nothing,=E2=80=9D i.e. if the send=
er is missing any
> of
> > them, they=E2=80=99ll just send a notfound.
> > The idea here was to avoid downloading any transactions that can=E2=80=
=99t be
> > validated right away.
>
> Right; maybe I should just be calling a "batch of packages to be validate=
d
> together" a "tx package" in the first place.
>
> Maybe it would be worth emphasising that you should be expecting to
> validate all the txs you receive as a response to getpckgtxns (getpkgtxs
> :) all at the same time, and immediately upon receiving them?
>
> > > The "only be sent if both peers agreed to do package relay" rule coul=
d
> > > simply be dropped, I think.
> > Wouldn=E2=80=99t we need some way of saying =E2=80=9Chey I support batc=
htxns?=E2=80=9D Otherwise
> > you would have to guess by sending a request and waiting to see if it=
=E2=80=99s
> > ignored?
>
> Sure, perhaps I should have said leave that rule, but drop the following
> "should be disconnected" rule, so that other BIPs could add in other
> ways of negotiating the connection in future? *shrug*
>
> > > Shouldn't the sender only be sending package announcements when they
> know
> > > the recipient will be interested in the package, based on their
> feefilter?
> > I think there are cases where the sender doesn=E2=80=99t necessarily kn=
ow.
> > Consider this example:
> >
> https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_gar=
den/rich_parent_bad_cpfp.png
> > D (5sat/vB) has 2 parents, A (0sat/vB) and B (20sat/vB). All same size.
> > Feefilter is 3sat/vB.
> > If the receiver already has B, they=E2=80=99ll know they can just rejec=
t the
> > package already based on the pckginfo.
> > But the sender doesn=E2=80=99t really know that. The sender just knows =
A is below
> > feerate and D is above. D is above the fee filter, and its ancestor
> feerate
> > is above the fee filter.
>
> The sender would also need to know whether or not there's some other
> child E that pays for A sufficiently?
>
> If you're asking for the package for "D", would a response telling you:
>
>   txid_D (500 sat, 100vB)
>   txid_A (0 sat, 100vB)
>   txid_B (2000 sat, 100 vB)
>
> be better, in that case? Then the receiver can maybe do the logic
> themselves to figure out that they already have A in their mempool
> so it's fine, or not?
>
> If you've got a package for X, and its direct parents P1..Pn, then
> I think the logic would be:
>
>   * is X alone above my fee rate? no, then forget it
>   * otherwise, s :=3D X.size, f :=3D X.fees, R :=3D [X]
>   * for P =3D P1..Pn:
>     * do I already have P? then skip to the next parent
>     * s +=3D P.size, f +=3D P.fees, R +=3D [P]
>   * if f/s above my fee rate floor? if so, request all the txs in R
>
> and you'd request txs if-and-only-if they're a match for you mempool rate=
?
>
> If you have a tx with 20 in-mempool parents, then the pkginfo1 message
> as proposed would be 737 bytes; including all the fee/size info would be
> 957 bytes, maybe a 30% increase. Might be worth it though?
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div><div dir=3D"ltr">Hi aj,<br><div></div></div></div><div><br>&gt; if you=
&#39;re writing a protocol that&#39;s<br>&gt; dependent on people seeing th=
at a package as a whole pays a competitive<br>&gt; feerate, don&#39;t you w=
ant to know in advance what conditions the network<br>&gt; is going to impo=
se on your transactions in order to consider them as a<br>&gt; package?<br>=
<br></div><div>I do think unifying the size/count constraints would result =
in a more stable/easier to reason about interface for L2 devs. Then the req=
uirement for propagation is just a path of nodes that support v1 package re=
lay, and it=E2=80=99s implied their mempool policy supports it as well. Als=
o seems like it could be a fingerprinting problem for nodes to give very sp=
ecific count/size limits.<br><br>&gt; (=E2=80=A6 maybe core&#39;s defaults =
should be reconsidered rather than standardised as-is)</div><div><br>&gt; W=
orst case, you could presumably do a new package relay version with<br>&gt;=
 different constraints, if needed.<br><br></div><div>Maybe this was my actu=
al concern. I think the defaults are safe but it=E2=80=99s not like they=E2=
=80=99ve been proven to be optimal. This creates an obstacle to changing th=
em, especially if we want to make them smaller. But I think it=E2=80=99s un=
likely we=E2=80=99ll do that, and adding another version for new constraint=
s doesn=E2=80=99t seem too bad. <br><div><br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">(Agreed with everything here, thanks for the feedback=
 and clarifications!) TLDR, making these changes:<br>- Count and size are i=
mplied by the version. Version 1 is specifically child-with-unconfirmed-par=
ents, where the whole package is at most 25 transactions and 101KvB.<br>- A=
nnounce sendpackages based on our own state. It=E2=80=99s ok to send =E2=80=
=9Csendpackages=E2=80=9D if they sent fRelay=3Dfalse.<br>- At verack, requi=
re fRelay=3Dtrue and wtxidrelay if they sent sendpackages, otherwise discon=
nect.<br>- If we get =E2=80=9Cgetpckgtxns=E2=80=9D or =E2=80=9Cpckgtxns=E2=
=80=9D without having negotiated =E2=80=9Csendpackages=E2=80=9D ahead of ti=
me, ignore, don=E2=80=99t disconnect. Emphasize that the intention is to va=
lidate all of the transactions received through =E2=80=9Cpckgtxns=E2=80=9D =
together.</div><div><br></div><div></div></div><div>&gt; If you&#39;re aski=
ng for the package for &quot;D&quot;, would a response telling you:<br>&gt;=
 =C2=A0 txid_D (500 sat, 100vB)<br>&gt; =C2=A0 txid_A (0 sat, 100vB)<br>&gt=
; =C2=A0 txid_B (2000 sat, 100 vB)<br>&gt; be better, in that case? Then th=
e receiver can maybe do the logic<br>&gt; themselves to figure out that the=
y already have A in their mempool<br>&gt; so it&#39;s fine, or not?<br><br>=
</div><div>Right, I also considered giving the fees and sizes of each trans=
action in the package in =E2=80=9Cpckginfo1=E2=80=9D. But I don=E2=80=99t t=
hink that information provides additional meaning unless you know the exact=
 topology, i.e. also know if the parents have dependency relationships betw=
een them. For instance, in the {A, B, D} package there, even if you have th=
e information listed, your decision should be different depending on whethe=
r B spends from A. The only thing you know for sure about a child with dire=
ct parents is: if the aggregate feerate is too low, you won=E2=80=99t want =
the child since it depends on everyone else. If there=E2=80=99s a good-feer=
ate transaction in there that doesn=E2=80=99t have a dependency, you=E2=80=
=99re fine as long as someone sends it to you individually.<div><br></div><=
div>Best,</div><div>Gloria<br></div></div><div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 23, 2022 at 2:34 PM An=
thony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed=
, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev wrote:<br>
&gt; &gt; Does it make sense for these to be configurable, rather than impl=
ied<br>
&gt; &gt; by the version?<br>
&gt; &gt; =E2=80=A6 would it be better to either just not do sendpackages<b=
r>
&gt; &gt; at all if you&#39;re limiting ancestors in the mempool incompatib=
ly<br>
&gt; Effectively: if you=E2=80=99re setting your ancestor/descendant limits=
 lower than<br>
&gt; the default, you can=E2=80=99t do package relay. I wonder if this migh=
t be<br>
&gt; controversial, since it adds pressure to adhere to Bitcoin Core=E2=80=
=99s current<br>
&gt; mempool policy? I would be happy to do it this way, though - makes thi=
ngs<br>
&gt; easier to implement.<br>
<br>
How about looking at it the other way: if you&#39;re writing a protocol tha=
t&#39;s<br>
dependent on people seeing that a package as a whole pays a competitive<br>
feerate, don&#39;t you want to know in advance what conditions the network<=
br>
is going to impose on your transactions in order to consider them as a<br>
package? In that case, aren&#39;t the &quot;depth&quot; and &quot;size&quot=
; constraints things<br>
we should specify in a standard?<br>
<br>
(The above&#39;s not a rhetorical question; I&#39;m not sure what the answe=
r is.<br>
And even if it&#39;s &quot;yes&quot;, maybe core&#39;s defaults should be r=
econsidered<br>
rather than standardised as-is)<br>
<br>
Worst case, you could presumably do a new package relay version with<br>
different constraints, if needed.<br>
<br>
&gt; &gt; &gt; 5. If &#39;fRelay=3D=3Dfalse&#39; in a peer&#39;s version me=
ssage, the node must not<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 send &quot;sendpackages&quot; to them. If a &qu=
ot;sendpackages&quot; message is<br>
&gt; &gt; &gt; received by a peer after sending `fRelay=3D=3Dfalse` in thei=
r version<br>
&gt; &gt; &gt; message, the sender should be disconnected.<br>
&gt; &gt; Seems better to just say &quot;if you set fRelay=3Dfalse in your =
version<br>
&gt; &gt; message, you must not send sendpackages&quot;? You already won&#3=
9;t do packages<br>
&gt; &gt; with the peer if they don&#39;t also announce sendpackages.<br>
&gt; I guess, theoretically, if you allow bloom filters with this peer, it=
=E2=80=99s<br>
&gt; plausible they=E2=80=99re saying =E2=80=9CfRelay=3Dfalse, I=E2=80=99ll=
 send you a bloom filter later,<br>
&gt; and I=E2=80=99ll also want to talk about packages.=E2=80=9D<br>
<br>
I was just meaning &quot;it&#39;s okay to send VERSION fRelay=3Dtrue then i=
mmediately<br>
send WTXIDRELAY then immediately send SENDPACKAGES&quot; without having to<=
br>
first verify what the other guy&#39;s fRelay was set to. On the other hand,=
<br>
you do already have to verify the other guy&#39;s version is high enough,<b=
r>
but it would be kind-of nice to move towards just announcing the features<b=
r>
you support, and not having to make it a multistep negotiation...<br>
<br>
&gt; &gt; Maybe: &quot;You must not send sendpackages unless you also send =
wtxidrelay&quot; ?<br>
&gt; Do you mean if we get a verack, and the peer sent =E2=80=9Csendpackage=
s=E2=80=9D but not<br>
&gt; =E2=80=9Cwtxidrelay,=E2=80=9D we should disconnect them?<br>
<br>
Yes.<br>
<br>
&gt; I have it as: we send a PCKG INV when this transaction=E2=80=99s feera=
te is above<br>
&gt; the fee filter, but one or more of its parents don=E2=80=99t. I don=E2=
=80=99t think using<br>
&gt; ancestor feerate is better.<br>
&gt; See this counterexample:<br>
&gt; <a href=3D"https://raw.githubusercontent.com/glozow/bitcoin-notes/mast=
er/mempool_garden/abc_1parent_2kids.png" rel=3D"noreferrer" target=3D"_blan=
k">https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_ga=
rden/abc_1parent_2kids.png</a><br>
&gt; A (0fee) has 2 kids, B (3sat/vB) and C (20sat/vB), everything=E2=80=99=
s the same<br>
&gt; vsize. Let=E2=80=99s say the fee filter is 3sat/vB.<br>
&gt; If we do it based on ancestor feerate, we won=E2=80=99t send B. But B =
is actually<br>
&gt; fine; C is paying for A.<br>
<br>
But that only works if the receiver also has C, in which case they also<br>
have A, and you don&#39;t need package relay to do anything with B? If they=
<br>
didn&#39;t have C already, then relaying {A,B} would be a waste of time,<br=
>
because {A,B} would be rejected as only paying 1.5sat/vB or whatever..<br>
<br>
If you switch it to being:<br>
<br>
=C2=A0 A (0 sats, 200vB)<br>
=C2=A0 B (2000 sats, 200vB, spends A:0)<br>
=C2=A0 C (200 sats, 200vB)<br>
=C2=A0 D (1000 sats, 200vB, sepnds A:1, C:0)<br>
<br>
then you get:<br>
<br>
=C2=A0 A alone =3D 0s/vB<br>
=C2=A0 B+A =3D 5s/vB<br>
<br>
=C2=A0 C alone =3D 1s/vB<br>
=C2=A0 D+C+A =3D 2s/vB<br>
=C2=A0 D+C =3D 3s/vB=C2=A0 =C2=A0 =C2=A0 (B+A already at 5s/vB)<br>
<br>
which I think recovers your point, while also having all the details<br>
only be dealing with direct parents.<br>
<br>
&gt; &gt; Are &quot;getpckgtxns&quot; / &quot;pcktxns&quot; really limited =
to packages, or are they<br>
&gt; &gt; just a general way to request a batch of transactions?<br>
&gt; &gt; Maybe call those messages &quot;getbatchtxns&quot; and &quot;batc=
htxns&quot; and allow them to<br>
&gt; &gt; be used more generally, potentially in ways unrelated to packages=
/cpfp?<br>
&gt; Indeed, it=E2=80=99s a general way to request a batch of transactions.=
 I=E2=80=99ll<br>
&gt; highlight that it is =E2=80=9Call or nothing,=E2=80=9D i.e. if the sen=
der is missing any of<br>
&gt; them, they=E2=80=99ll just send a notfound.<br>
&gt; The idea here was to avoid downloading any transactions that can=E2=80=
=99t be<br>
&gt; validated right away.<br>
<br>
Right; maybe I should just be calling a &quot;batch of packages to be valid=
ated<br>
together&quot; a &quot;tx package&quot; in the first place.<br>
<br>
Maybe it would be worth emphasising that you should be expecting to<br>
validate all the txs you receive as a response to getpckgtxns (getpkgtxs<br=
>
:) all at the same time, and immediately upon receiving them?<br>
<br>
&gt; &gt; The &quot;only be sent if both peers agreed to do package relay&q=
uot; rule could<br>
&gt; &gt; simply be dropped, I think.<br>
&gt; Wouldn=E2=80=99t we need some way of saying =E2=80=9Chey I support bat=
chtxns?=E2=80=9D Otherwise<br>
&gt; you would have to guess by sending a request and waiting to see if it=
=E2=80=99s<br>
&gt; ignored?<br>
<br>
Sure, perhaps I should have said leave that rule, but drop the following<br=
>
&quot;should be disconnected&quot; rule, so that other BIPs could add in ot=
her<br>
ways of negotiating the connection in future? *shrug*<br>
<br>
&gt; &gt; Shouldn&#39;t the sender only be sending package announcements wh=
en they know<br>
&gt; &gt; the recipient will be interested in the package, based on their f=
eefilter?<br>
&gt; I think there are cases where the sender doesn=E2=80=99t necessarily k=
now.<br>
&gt; Consider this example:<br>
&gt; <a href=3D"https://raw.githubusercontent.com/glozow/bitcoin-notes/mast=
er/mempool_garden/rich_parent_bad_cpfp.png" rel=3D"noreferrer" target=3D"_b=
lank">https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool=
_garden/rich_parent_bad_cpfp.png</a><br>
&gt; D (5sat/vB) has 2 parents, A (0sat/vB) and B (20sat/vB). All same size=
.<br>
&gt; Feefilter is 3sat/vB.<br>
&gt; If the receiver already has B, they=E2=80=99ll know they can just reje=
ct the<br>
&gt; package already based on the pckginfo.<br>
&gt; But the sender doesn=E2=80=99t really know that. The sender just knows=
 A is below<br>
&gt; feerate and D is above. D is above the fee filter, and its ancestor fe=
erate<br>
&gt; is above the fee filter.<br>
<br>
The sender would also need to know whether or not there&#39;s some other<br=
>
child E that pays for A sufficiently?<br>
<br>
If you&#39;re asking for the package for &quot;D&quot;, would a response te=
lling you:<br>
<br>
=C2=A0 txid_D (500 sat, 100vB)<br>
=C2=A0 txid_A (0 sat, 100vB)<br>
=C2=A0 txid_B (2000 sat, 100 vB)<br>
<br>
be better, in that case? Then the receiver can maybe do the logic<br>
themselves to figure out that they already have A in their mempool<br>
so it&#39;s fine, or not?<br>
<br>
If you&#39;ve got a package for X, and its direct parents P1..Pn, then<br>
I think the logic would be:<br>
<br>
=C2=A0 * is X alone above my fee rate? no, then forget it<br>
=C2=A0 * otherwise, s :=3D X.size, f :=3D X.fees, R :=3D [X]<br>
=C2=A0 * for P =3D P1..Pn:<br>
=C2=A0 =C2=A0 * do I already have P? then skip to the next parent<br>
=C2=A0 =C2=A0 * s +=3D P.size, f +=3D P.fees, R +=3D [P]<br>
=C2=A0 * if f/s above my fee rate floor? if so, request all the txs in R<br=
>
<br>
and you&#39;d request txs if-and-only-if they&#39;re a match for you mempoo=
l rate?<br>
<br>
If you have a tx with 20 in-mempool parents, then the pkginfo1 message<br>
as proposed would be 737 bytes; including all the fee/size info would be<br=
>
957 bytes, maybe a 30% increase. Might be worth it though?<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<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>

--0000000000009ee9c905dfb7ab67--