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

Merge pull request #2181 from ajtowns/202605-bip434-edits

Browse Source 
BIP-434: Various rationale edits
This commit is contained in:
Jon Atack
2026-05-29 10:07:18 -07:00
committed by GitHub
parent 7f9434c9c8 18ff6bb77b
commit b4241dc504
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`
specifying the string length, followed by that many bytes. The string
length MUST be between 4 and 80, inclusive. The string SHOULD include
only printable ASCII characters (ie, each byte should have a value
between 32 and 126, inclusive).
length MUST be between 4[^feature-id-min] and 80[^feature-payload-max],
inclusive. The string SHOULD include only printable ASCII characters
(ie, each byte should have a value between 32 and 126, inclusive).
Likewise, `featuredata` is encoded as a `CompactSize` specifying the
byte-vector size, followed by that many bytes. How these bytes are
interpreted is part of the feature's specification. The byte-vector size
MUST NOT be more than 512 bytes. Note that the `featuredata` field is not
optional, so if no data is required, an empty vector should be provided,
ie serialized as `CompactSize` of 0.
interpreted is part of the feature's specification. The byte-vector
size MUST NOT be more than 512 bytes[^feature-payload-max]. Note that
the `featuredata` field is not optional, so if no data is required,
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
`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
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
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
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
discovering the listening peer's supported features.
@@ -304,6 +306,16 @@ negotiation][suhas-draft].
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
[BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
[BIP152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki