path: root/c3/80251fb1ce409086048ba96f3bf367260b7bc2

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 351FAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 May 2022 21:34:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 1C08840469
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 May 2022 21:34:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bbeLN8MWv9pz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 May 2022 21:34:27 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C2C1D400BF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 May 2022 21:34:27 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1ntFh0-0006Ns-IG
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 24 May 2022 07:34:24 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Tue, 24 May 2022 07:34:16 +1000
Date: Tue, 24 May 2022 07:34:16 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20220523213416.GA6151@erisian.com.au>
References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
 <20220518003531.GA4402@erisian.com.au>
 <CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
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: Mon, 23 May 2022 21:34:29 -0000

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?
> > … would it be better to either just not do sendpackages
> > at all if you're limiting ancestors in the mempool incompatibly
> Effectively: if you’re setting your ancestor/descendant limits lower than
> the default, you can’t do package relay. I wonder if this might be
> controversial, since it adds pressure to adhere to Bitcoin Core’s current
> mempool policy? I would be happy to do it this way, though - makes things
> 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==false' in a peer's version message, the node must not
> > >    send "sendpackages" to them. If a "sendpackages" message is
> > > received by a peer after sending `fRelay==false` in their version
> > > message, the sender should be disconnected.
> > Seems better to just say "if you set fRelay=false in your version
> > message, you must not send sendpackages"? You already won't do packages
> > with the peer if they don't also announce sendpackages.
> I guess, theoretically, if you allow bloom filters with this peer, it’s
> plausible they’re saying “fRelay=false, I’ll send you a bloom filter later,
> and I’ll also want to talk about packages.”

I was just meaning "it's okay to send VERSION fRelay=true then immediately
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 “sendpackages” but not
> “wtxidrelay,” we should disconnect them?

Yes.

> I have it as: we send a PCKG INV when this transaction’s feerate is above
> the fee filter, but one or more of its parents don’t. I don’t think using
> ancestor feerate is better.
> See this counterexample:
> https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_garden/abc_1parent_2kids.png
> A (0fee) has 2 kids, B (3sat/vB) and C (20sat/vB), everything’s the same
> vsize. Let’s say the fee filter is 3sat/vB.
> If we do it based on ancestor feerate, we won’t send B. But B is 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 = 0s/vB
  B+A = 5s/vB

  C alone = 1s/vB
  D+C+A = 2s/vB
  D+C = 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/cpfp?
> Indeed, it’s a general way to request a batch of transactions. I’ll
> highlight that it is “all or nothing,” i.e. if the sender is missing any of
> them, they’ll just send a notfound.
> The idea here was to avoid downloading any transactions that can’t be
> validated right away.

Right; maybe I should just be calling a "batch of packages to be validated
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 could
> > simply be dropped, I think.
> Wouldn’t we need some way of saying “hey I support batchtxns?” Otherwise
> you would have to guess by sending a request and waiting to see if it’s
> 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’t necessarily know.
> Consider this example:
> https://raw.githubusercontent.com/glozow/bitcoin-notes/master/mempool_garden/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’ll know they can just reject the
> package already based on the pckginfo.
> But the sender doesn’t 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 := X.size, f := X.fees, R := [X]
  * for P = P1..Pn:
    * do I already have P? then skip to the next parent
    * s += P.size, f += P.fees, R += [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