Adding Protocol specification to docs (WIP) #1727
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "doc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am slowly formatting Protocol Specification doc. I see some typos and mistakes in the wiki, which I also hope to fix.
A quick preview
Almost finished (: The first question is about references: there are some references to object type definition tables like var_int, var_str, var_int_list, which are incomplete; so I cannot guess how to make them properly:
Another question: what addresses of version 5 has to do with extended encoding? In the section Extended encoding Specification says: "It is planned that v5 addresses will have to support this.". The v5 address is an address with compressed pubkey instead of ripe, if I recall it correctly. Unfortunately I cannot found an issue which describes it.
There hasn't been a decision made about this yet, only me making proposals. I'd be very happy for feedback on how to properly add new features (extended encoding, new pubkey format, ...), i.e. whether to use a new version, a flag in the bitfield, or something else.
I'm really surprised there is no ticket for addresses v5. May Bitmessage have some standards track, you know, the BIPs or BEP - in pythonic style?
This reminds me #1612. I don't think that such things need any signaling in bitfield, because they don't affect the communication between nodes, e.g. don't introduce a new command like "invbloom" or "dinv".
Here I'm just asking about the text of this section in the Protocol Specification.
Do you want me to squash and merge as is and make changes related to links and address generation in the separate PR?
I leave it up to you.
Hmm, now I'm observing a strange failure while building the docs:
More interesting is that I'm still able to build them locally with these changes:
Using the command