Package Relay and child-with-unconfirmed-parents + tx-with-unconfirmed-ancestors Packages

[glozow]

Please leave concept/approach feedback on the mailing list thread so that people can follow the discussion in one place. Feel free to leave a review comment if you find typos or incorrect wording.

[instagibbs]

Based on email discussion, I'd request that the spec makes it explicit that you do not request packages from peers when they report a different chaintip blockhash(and disconnect them right after...)

it's possible I missed it, but I keep looking and not seeing it

[glozow]

Based on email discussion, I'd request that the spec makes it explicit that you do not request packages from peers when they report a different chaintip blockhash(and disconnect them right after...)

Thanks @instagibbs I will add this. Also, if a peer sends us a "pckginfo1" with a blockhash that's different from ours, we should probably just drop it and re-request when they catch up (I think nowadays we usually have an accurate idea of what our peer's best block is). We're definitely not going to disconnect a peer for sending a "pckginfo1" with a different blockhash from ours.

[glozow]

Added tx-with-unconfirmed-ancestors packages as a second type of package dedicated to orphan-fetching.

[glozow]

Last push (thanks @ajtowns)

• Count and size are implied by the version. Version 1 and Version 2 both have maximum of 25 transactions and 404KWu.
• Announce sendpackages based on our own state. It’s ok to send “sendpackages” if they sent fRelay=false.
• At verack, require fRelay=true and wtxidrelay if they sent sendpackages, otherwise disconnect.
• If we get “getpckgtxns” or “pckgtxns” without having negotiated “sendpackages” ahead of time, ignore, don’t disconnect. Emphasize that the intention is to validate all of the transactions received through “pckgtxns” together.

Thanks for the feedback @michaelfolkson, I'll get to the style/wording comments later when the design is more finalized.

[flack]

Sorry for also leaving a style nit, but as someone also mentioned on the mailing list, pkg is a much more common abbreviation than pckg (it's even mentioned on Wikipedia: https://en.wikipedia.org/wiki/PKG), so it might be nice to consider switching to that.

[glozow]

Last push:

• Renamed s/pckg/pkg everywhere, updated diagrams
• Removed fee and weight information from pkginfo1

[glozow]

Closing as the updated proposal is going to be significantly different from this one, which has no number assigned, and I think it would be confusing.