Protocol specification - Revision history

PeterSurda: /* Pubkey bitfield features */ Reassign bit 29 from extended_encoding to chat

2020-04-29T02:40:12Z

Pubkey bitfield features: Reassign bit 29 from extended_encoding to chat

2018-02-03T11:34:36Z

Pubkey bitfield features: typo

2018-02-03T11:33:58Z

Dandelion is now ready

2017-07-31T05:47:57Z

version: Reserve bitfield for dandelion

2017-07-31T05:46:11Z

Pubkey bitfield features

2017-04-21T12:54:16Z

Added NODE_POW services (proposal)

2017-02-08T10:31:17Z

Pubkey bitfield features: Add proposals.

2016-11-15T15:55:57Z

Update extended encoding

2016-06-24T20:29:53Z

Added EXTENDED encoding.

2016-06-24T19:49:27Z

Decided to go for msgpack instead of bencode after all

@@ Line 214: / Line 214: @@
 | 28 || forward_secrecy || ('''Proposal''') Receiving node supports a forward secrecy encryption extension. The exact design is pending.
 |-
-| 29 || extended_encoding || ('''Proposal''') Receiving node supports extended encoding.
+| 29 || chat || ('''Proposal''') Address if for chatting rather than messaging.
 |-
 | 30 || include_destination || ('''Proposal''') Receiving node expects that the RIPE hash encoded in their address preceedes the encrypted message data of msg messages bound for them.

@@ Line 214: / Line 214: @@
 | 28 || forward_secrecy || ('''Proposal''') Receiving node supports a forward secrecy encryption extension. The exact design is pending.
 |-
-| 29 || extended_encoding || ('''Proposal'') Receiving node supports extended encoding.
+| 29 || extended_encoding || ('''Proposal''') Receiving node supports extended encoding.
 |-
 | 30 || include_destination || ('''Proposal''') Receiving node expects that the RIPE hash encoded in their address preceedes the encrypted message data of msg messages bound for them.

@@ Line 264: / Line 264: @@
 | 3 || NODE_POW     || '''(Proposal)''' This node may do PoW on behalf of some its peers (PoW offloading/delegating), but it doesn't have to. Clients may have to meet additional requirements (e.g. TLS authentication)
 |-
-| 4 || NODE_DANDELION || '''(Proposal)''' Node supports dandelion (https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki)
+| 4 || NODE_DANDELION || Node supports dandelion (https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki)
 |}

@@ Line 262: / Line 262: @@
 | 2 || NODE_SSL     || This node supports SSL/TLS in the current connect (python < 2.7.9 only supports a SSL client, so in that case it would only have this on when the connection is a client).
 |-
-| 3 || NODE_POW     || This node may do PoW on behalf of some its peers (PoW offloading/delegating), but it doesn't have to. Clients may have to meet additional requirements (e.g. TLS authentication) '''(proposal)'''
+| 3 || NODE_POW     || '''(Proposal)''' This node may do PoW on behalf of some its peers (PoW offloading/delegating), but it doesn't have to. Clients may have to meet additional requirements (e.g. TLS authentication)
 |}

@@ Line 214: / Line 214: @@
 | 28 || forward_secrecy || ('''Proposal''') Receiving node supports a forward secrecy encryption extension. The exact design is pending.
 |-
-| 29 || extended_encoding || Receiving node supports extended encoding.
+| 29 || extended_encoding || ('''Proposal'') Receiving node supports extended encoding.
 |-
-| 30 || include_destination || ('''Proposal''') Receiving node expects that the RIPE hash encoded in their address preceedes the encrypted message data of msg messages bound for them. '''NOTE:''' since hardly anyone implements this, this will be redesigned as simple recipient verification: https://github.com/Bitmessage/PyBitmessage/pull/808#issuecomment-170189856
+| 30 || include_destination || ('''Proposal''') Receiving node expects that the RIPE hash encoded in their address preceedes the encrypted message data of msg messages bound for them.
 |-
 | 31 || does_ack|| If true, the receiving node does send acknowledgements (rather than dropping them).

@@ Line 195: / Line 195: @@
 <code>messageToTransmit = 'Subject:' + subject + '\n' + 'Body:' + message</code>
 |-
-| 3 || EXTENDED || A data structure in msgpack, then compressed with zlib. Null data type is encoded as an empty string, and booleans as an integer 0 (false) or 1 (true). Text fields are encoded using UTF-8. v5 and newer address versions MUST support this. Proposal, exact structure pending standardisation.
+| 3 || EXTENDED || See [[Extended encoding]]
 |}

@@ Line 209: / Line 209: @@
 |-
 | ... || ... || ...
 |-
 | 30 || include_destination || Receiving node expects that the RIPE hash encoded in their address preceedes the encrypted message data of msg messages bound for them.