Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-19 🗒️ Summary of this message: Discussion on ...
📅 Original date posted:2023-02-19
🗒️ Summary of this message: Discussion on introducing a way to negotiate a different short id mapping table without needing a mechanism for re-negotiating. Also, a debate on including REJECT in the current list.
📝 Original message: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
🗒️ Summary of this message: Discussion on introducing a way to negotiate a different short id mapping table without needing a mechanism for re-negotiating. Also, a debate on including REJECT in the current list.
📝 Original message: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