📅 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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 23:19:51
in reply to nevent1q…6erj
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-07 23:19:51Event JSON
{
"id": "780a975b745c07fb4e198950fbc959067be9fe134dfe16f4962aaf1b48a4c89f",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686179991,
"kind": 1,
"tags": [
[
"e",
"429be874d3570713c540c47c8be4f6f1e3388c0ba98ab349c4ee16626a758167",
"",
"root"
],
[
"e",
"b1bad9bfc91eb564dc636ef38cff15b093115be1a9acb1a88d147efad5e39abe",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2023-02-19\n🗒️ 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.\n📝 Original message:On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote:\n\u003e \u003e I think it's probably less complex to close some of the doors?\n\u003e \u003e 2) are short ids available/meaningful to send prior to VERACK being\n\u003e \u003e completed?\n\u003e 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.\n\nI think you still need/want two negotiation steps -- once to tell each\nother what tables you know about, once to choose a mutually recognised\ntable and specify any additions.\n\n\u003e \u003e I think the things missing from the current list (and not currently in\n\u003e \u003e use by bitcoin core) are:\n\u003e \u003e bip 61: REJECT\n\u003e \u003e bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO\n\u003e Do you feel REJECT should be included?\n\nI don't think it matters much; reject messages are both rare and include\na reason so you'd only be saving maybe 12 bytes out of 62 (~20%)\nfor maybe 6000 messages a day per peer that sends reject messages,\nso 72kB/day/reject-peer?\n\n\u003e 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?\n\nPresuming the transport layer also continues to reject commands that\nhave a '\\x00' byte at the start or in the middle (ie !IsCommandValid()),\nthat seems pretty reasonable...\n\nCheers,\naj",
"sig": "88b9f5bbc302ce2fc9fa862a225c48bd34ead5d63691c67b073dae6c349d6e4252e0e29ff9409f3b8503ae2bdb4036f4f99f52cd12e5b0cb21b36d1bd48f3098"
}