bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-06-01 17:15:27 +00:00
Code Issues Releases Wiki Activity

BIP-434: Various rationale edits

Browse Source
This commit is contained in:
Anthony Towns
2026-05-29 15:28:41 +10:00
parent 7f9434c9c8
commit 18ff6bb77b
1 changed files with 29 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
bip-0434.md
View File

@@ -127,16 +127,26 @@ The payload of the `feature` message contains exactly the following data:
The `featureid` is encoded in the usual way, that is, as a `CompactSize` The `featureid` is encoded in the usual way, that is, as a `CompactSize`
specifying the string length, followed by that many bytes. The string specifying the string length, followed by that many bytes. The string
length MUST be between 4 and 80, inclusive. The string SHOULD include length MUST be between 4[^feature-id-min] and 80[^feature-payload-max],
only printable ASCII characters (ie, each byte should have a value inclusive. The string SHOULD include only printable ASCII characters
between 32 and 126, inclusive). (ie, each byte should have a value between 32 and 126, inclusive).
Likewise, `featuredata` is encoded as a `CompactSize` specifying the Likewise, `featuredata` is encoded as a `CompactSize` specifying the
byte-vector size, followed by that many bytes. How these bytes are byte-vector size, followed by that many bytes. How these bytes are
interpreted is part of the feature's specification. The byte-vector size interpreted is part of the feature's specification. The byte-vector
MUST NOT be more than 512 bytes. Note that the `featuredata` field is not size MUST NOT be more than 512 bytes[^feature-payload-max]. Note that
optional, so if no data is required, an empty vector should be provided, the `featuredata` field is not optional, so if no data is required,
ie serialized as `CompactSize` of 0. an empty vector should be provided, ie serialized as `CompactSize` of 0.
The `featureid` MUST be a globally unique identifier for the feature.
For features published as a BIP, the `featureid` SHOULD be the assigned
BIP number, eg "BIP434", or be based on the BIP number (eg, "BIP434v2"
where the "v2" suffix covers versioning, or "BIP434.3" where the ".3"
suffix covers part 3 of the BIP). For experimental features that do not
(yet) have a BIP number assigned, some other unique identifier MUST be
chosen, such as a URL to the repository where development is taking
place, or the sha256 digest of some longer reference.
Nodes implementing this BIP MUST ignore `feature` messages specifying a Nodes implementing this BIP MUST ignore `feature` messages specifying a
`featureid` they do not support, so long as the payload conforms to the `featureid` they do not support, so long as the payload conforms to the
@@ -147,15 +157,6 @@ messages where the `feature` message's payload cannot be correctly
parsed (including having missing or additional data), even if they do parsed (including having missing or additional data), even if they do
not recognise the `featureid`. not recognise the `featureid`.
The `featureid` MUST be a globally unique identifier for the feature.
For features published as a BIP, the `featureid` SHOULD be the assigned
BIP number, eg "BIP434", or be based on the BIP number (eg, "BIP434v2"
where the "v2" suffix covers versioning, or "BIP434.3" where the ".3"
suffix covers part 3 of the BIP). For experimental features that do not
(yet) have a BIP number assigned, some other unique identifier MUST be
chosen, such as a URL to the repository where development is taking place,
or the sha256 digest of some longer reference.
#### `feature` message 1-byte identifier #### `feature` message 1-byte identifier
Nodes implementing both this BIP and [BIP 324 (v2 P2P encrypted Nodes implementing both this BIP and [BIP 324 (v2 P2P encrypted
@@ -269,7 +270,8 @@ pairs). It was chosen because:
A mild disadvantage compared to using a `verack` payload is that this A mild disadvantage compared to using a `verack` payload is that this
approach allows the possibility of interactive feature negotiation prior approach allows the possibility of interactive feature negotiation prior
to `verack`. However interactive feature negotiation is always possible to `verack`, which would make negotiation more complex and increase
latency. However interactive feature negotiation is always possible
simply by having the initiating peer disconnect and reconnect after simply by having the initiating peer disconnect and reconnect after
discovering the listening peer's supported features. discovering the listening peer's supported features.
@@ -304,6 +306,16 @@ negotiation][suhas-draft].
This BIP is licensed under the 2-clause BSD license. This BIP is licensed under the 2-clause BSD license.
[^feature-id-min]: The minimum `featureid` length of 4 characters
corresponds with a "BIPx" string for BIPs in the range 1-9. Longer
identifiers than this will almost always be needed in order to meet the
"globally unique" requirement.
[^feature-payload-max]: The maximum values for the `featureid` and
`featuredata` lengths serve only to bound the volume of the feature
message payload, particularly as this data will be automatically
advertised even to peers that do not support the features in question.
[BIP130]: https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki [BIP130]: https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki
[BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki [BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
[BIP152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki [BIP152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki