Refreshed BIP324

In a Bitcoin mailing list, Pieter Wuille discussed the possibility of introducing a way to negotiate a different short ID mapping table without needing a mechanism for re-negotiating. He suggests that if there is no need for these IDs to be available before VERACK negotiation, it may be less complex to close some doors. However, he still believes that two negotiation steps will be needed. One to tell each other what tables are known about and another to choose a mutually recognised table and specify any additions. When discussing missing items from the current list, bip 61 reject and bip 331 getpkgtxns, pkgtxns, ancpkginfo were mentioned. Aj brought up the question of whether or not REJECT should be included in the list. Reject messages are rare and include a reason so only saving around 20% of bytes would have minimal impact. Finally, they talked about the possibility of having the transport layer translate short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), which seems reasonable presuming the transport layer continues to reject commands that have a '\x00' byte at the start or in the middle (ie !IsCommandValid()).