On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote: > > I think it's probably less complex to close some of the doors? > > 2) are short ids available/meaningful to send prior to VERACK being > > completed? > Ah, I hadn't considered this nuance. If we don't care about them being > available before VERACK negotiation, then it may be possible to introduce a > way to negotiate a different short id mapping table without needing a > mechanism for *re*-negotiating.
I think you still need/want two negotiation steps -- once to tell each other what tables you know about, once to choose a mutually recognised table and specify any additions. > > I think the things missing from the current list (and not currently in > > use by bitcoin core) are: > > bip 61: REJECT > > bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO > Do you feel REJECT should be included? I don't think it matters much; reject messages are both rare and include a reason so you'd only be saving maybe 12 bytes out of 62 (~20%) for maybe 6000 messages a day per peer that sends reject messages, so 72kB/day/reject-peer? > Perhaps a possibility is having the transport layer translate > short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), and > hand that to the application layer, which could then do the mapping? Presuming the transport layer also continues to reject commands that have a '\x00' byte at the start or in the middle (ie !IsCommandValid()), that seems pretty reasonable... Cheers, aj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
