The relevant changes from this discussion about short 1-byte message
type IDs are now in a PR for the bips repo:

On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote:
> On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-dev wrote:
>> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns 
>> <> wrote:
>>> 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.
>> Right, I wasn't talking about how many steps/messages the negotiation takes. 
>> I just meant that if all negotiation of the mapping table happens just once 
>> (before VERACK) and that negotiation itself happens without use of short 
>> commands, then there is no need for re-negotiating short commands after they 
>> are already in use. Nothing concrete, but I can imagine that that may 
>> simplify some implementations.
> Yeah; I was just thinking of the fact that currently the negotiation is:
>   * send your VERSION message
>   * see what their VERSION message is
>   * announce a bunch of features, depending on the version (or service
>     flags)
>   * send the VERACK (and GETADDR and final ALERT)
>   * wait for their announcements and VERACK
>   * negotiation is finished; we know everything; we're ready to go
> which only gets you two steps if you send the short id stuff as part of
> the VERSION message. Obviously you could just add an extra phase either
> just before or just after the VERACK, though.
> I suppose being able to choose your own short id mapping from day 0 would
> mean that every bip324 node could use a single short id mapping for all
> outgoing messages, which might also make implementation marginally easier
> (no need to use one table for modern nodes, but also support the original
> table for old bip324 implementations)...
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list

bitcoin-dev mailing list

Reply via email to