(To everyone):
I should have made it much clearer that version 1 is only supposed to solve 1 of the 2 use cases. I was a lot more focused on the fee-bumping use case, since it’s more important. Orphan-fetching was added to the motivation section last-minute because John Newbery mentioned to me “hey you could deal with orphans really easily with this.” Of course, child-with-unconfirmed-parents packages aren’t very useful for orphan-fetching since non-parent ancestors are quite common.
Maybe a version 2 package for orphan-fetching could look like this:
“pckginfo2” message contains a tx with all of its ancestors
“MSG_PCKG2” inv type refers to a “pckginfo2” for a tx. You don’t send inv(MSG_PCKG2), but a node can request getdata(MSG_PCKG2) for a transaction they want the ancestors for, provided they sent sendpackages(version=2) ahead of time. It seems to me that orphan-fetching only ever needs to be receiver-initiated.
Protocol flow would look like this:
https://user-images.githubusercontent.com/25183001/168891185-1630f583-de47-4937-86b1-2652cf8852f2.png We don’t have a policy for dealing with anything more than a child with its direct parents, but I also don’t think anybody is relying on fee-bumping more than 2 generations, so the validation logic here could probably just submit them all individually. Maybe they can request a pckginfo1 if they see something that’s too-low-fee, and/or use the child-with-unconfirmed-parents logic opportunistically.
Thanks aj for the feedback! Responding:
> The "PCKG" abbreviation threw me for a loop; isn't the usual
> abbreviation "PKG" ?
Oh I didn't know that. I could change it if people feel strongly.
> 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.
> > 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 don’t know if that’s a use case we want to support - my gut reaction is no.
> 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?
> As I understand it, the two cases for the protocol flow are "I received
> an orphan, and I'd like its ancestors please" which seems simple enough,
> and "here's a child you may be interested in, even though you possibly
> weren't interested in the parents of that child".
(Btw, please see my notes at the top of this email about separating those two use cases. sorry for the confusion).
> I think the logic for the latter is: […]
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.pngA (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.
> 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. With packages, this makes sense, because there are dependency relationships. But if you’re requesting multiple unrelated transactions, for example, it’s unnecessary. You might end up with even more transaction data that’s just sitting around waiting to be validated.
> 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?
> 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.
> CAmount in consensus/amount.h is a int64_t
> The maximum block weight is 4M…
Oops yes. I think we just usually use int64_t for vsizes afaik. Agree that it should be 8 bytes for fee, and 4 bytes is enough for vsize.
> I guess tx relay is low priority enough that it wouldn't be worth tagging
> some peers as "high bandwidth" and having them immediately announce the
> PCKGINFO1 message, and skip the INV/GETDATA step?
I had the same idea as well, but seemed unnecessary. It would reduce the number of round trips, but I don’t think an extra round trip is that big of a deal for transaction relay. Block relay, yes of course, but I don’t think we care that much if it takes an extra second to send a transaction?
Best,
Gloria
