Hi,
Thanks again for your work on this!
One question I have is about potential bandwidth waste in the case of nodes running with different policy rules. Here's my understanding of a scenario I think could happen:
1) Transaction A is both low-fee and non-standard to some nodes on the network.
2) Whenever a transaction T that spends A is relayed, new nodes will send INV(PKGINFO1, T) to all package-relay peers.
3) Nodes on the network that have implemented package relay, but do not accept A, will send getdata(PKGINFO1, T) and learn all of T's unconfirmed parents (~32 bytes * number of parents(T)).
4) Such nodes will reject T. But because of transaction malleability, and to avoid being blinded to a transaction unnecessarily, these nodes will likely still send getdata(PKGINFO1, T) to every node that announces T, in case someone has a transaction that includes an alternate set of parent transactions that would pass policy checks.
Is that understanding correct? I think a good design goal would be to not waste bandwidth in non-adversarial situations. In this case, there would be bandwidth waste from downloading duplicate data from all your peers, just because the announcement doesn't commit to the set of parent wtxids that we'd get from the peer (and so we are unable to determine that all our peers would be telling us the same thing, just based on the announcement).
Some ways to mitigate this might be to: (a) include a hash (maybe even just a 20-byte hash -- is that enough security?) of the package wtxids (in some canonical ordering) along with the wtxid of the child in the initial announcement; (b) limit the use of v1 packages to transactions with very few parents (I don't know if this is reasonable for the use cases we have in mind).
Another point I wanted to bring up is about the rules around v1 package validation generally, and the use of a blockhash in transaction relay specifically. My first observation is that it won't always be the case that a v1 package relay node will be able to validate that a set of package transactions is fully sorted topologically, because there may be (non-parent) ancestors that are missing from the package and the best a peer can validate is topology within the package -- this means that a peer can validly (under this BIP) relay transaction packages out of the true topological sort (if all ancestors were included).
This makes me wonder how useful this topological rule is. I suppose there is some value in preventing completely broken implementations from staying connected and so there is no harm in having the rule, but perhaps it would be helpful to add that nodes SHOULD order transactions based on topological sort in the complete transaction graph, so that if missing-from-package ancestors are already known by a peer (which is the expected case when using v1 package relay on transactions that have more than one generation of unconfirmed ancestor) then the remaining transactions are already properly ordered, and this is helpful even if unenforceable in general.
The other observation I wanted to make was that having transaction relay gated on whether two nodes agree on chain tip seems like an overly restrictive criteria. I think an important design principle is that we want to minimize disruption from network splits -- if there are competing blocks found in a small window of time, it's likely that the utxo set is not materially different on the two chains (assuming miners are selecting from roughly the same sets of transactions when this happens, which is typical). Having transaction relay bifurcate on the two network halves would seem to exacerbate the difference between the two sides of the split -- users ought to be agnostic about how benign splits are resolved and would likely want their transactions to relay across the whole network.
Additionally, use of a chain tip might impose a larger burden than is necessary on software that would seek to participate in transaction relay without implementing headers sync/validation. I don't know what software exists on the network, but I imagine there are a lot of scripts out there for transaction submission to the public p2p network, and in thinking about modifying such a script to utilize package relay it seems like an unnecessary added burden to first learn a node's tip before trying to relay a transaction.
Could you explain again what the benefit of including the blockhash is? It seems like it is just so that a node could prioritize transaction relay from peers with the same chain tip to maximize the likelihood of transaction acceptance, but in the common case this seems like a pretty negligible concern, and in the case of a chain fork that persists for many minutes it seems better to me that we not partition the network into package-relay regimes and just risk a little extra bandwidth in one direction or the other. If we solve the problem I brought up at the beginning (of de-duplicating package data across peers with a package-wtxid-commitment in the announcement), I think this is just some wasted pkginfo bandwidth on a single-link, and not across links (as we could cache validation failure for a package-hash to avoid re-requesting duplicate pkginfo1 messages).
Best,
Suhas