user129189: The BOLT #9 specification shows a 52-bit field that represents various feature flags. That should require no more than 7 bytes, or less.
When I run the listnodes command, some of the nodes include features fields that are in the range of expected lengths, such as 808252a1 which is less than 7 bytes, but others are unexpectedly long, always beginning with the byte 80 followed by a long sequence of 00 bytes and then what appear to be the actual feature flags.
One of them looks like this: 800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000802000888252a1
Is this a bug of some sort, or is there some other information to be interpreted from these long sequences of feature flags?

user120: The BOLT#9 specification lists all standardized or soon-to-be-standardized features, but developers are free to pick a higher bit to represent their custom feature. Oftentimes the spec engineers also use a high bit while developing a feature to avoid clashes and later drop it to a lower one for the standardization (this saves bytes as you noticed).
The above feature bitset decodes into:
['option_data_loss_protect',
 'option_upfront_shutdown_script(opt)',
 'gossip_queries(opt)',
 'var_onion_optin(opt)',
 'option_static_remotekey',
 'payment_secret',
 'basic_mpp(opt)',
 'option_anchors_zero_fee_htlc_tx(opt)',
 'option_channel_type',
 'AMP(LND)(opt)',
 'ExplicitChannelType(LND)(opt)',
 'unknown[55]',
 'ScriptEnforcedLease(LND)(opt)']

(maintaining the order the bits are set in the bitset)
The large number of 0 is due to bit 2023 being set: script_enforced_lease, an experimental feature by lnd, which iirc is used by their proprietary Pool implementation.

129189: <p>The <a href="https://github.com/lightning/bolts/blob/master/09-features.md" rel="nofollow noreferrer">BOLT #9 specification</a> shows a 52-bit field that represents various feature flags. That should require no more than 7 bytes, or less.</p>
<p>When I run the <code>listnodes</code> command, some of the nodes include features fields that are in the range of expected lengths, such as <code>808252a1</code> which is less than 7 bytes, but others are unexpectedly long, always beginning with the byte <code>80</code> followed by a long sequence of <code>00</code> bytes and then what appear to be the actual feature flags.</p>
<p>One of them looks like this: <code>800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000802000888252a1</code></p>
<p>Is this a bug of some sort, or is there some other information to be interpreted from these long sequences of feature flags?</p>
 120: <p>The BOLT#9 specification lists all standardized or soon-to-be-standardized features, but developers are free to pick a higher bit to represent their custom feature. Oftentimes the spec engineers also use a high bit while developing a feature to avoid clashes and later drop it to a lower one for the standardization (this saves bytes as you noticed).</p>
<p>The above feature bitset decodes into:</p>
<pre><code>['option_data_loss_protect',
 'option_upfront_shutdown_script(opt)',
 'gossip_queries(opt)',
 'var_onion_optin(opt)',
 'option_static_remotekey',
 'payment_secret',
 'basic_mpp(opt)',
 'option_anchors_zero_fee_htlc_tx(opt)',
 'option_channel_type',
 'AMP(LND)(opt)',
 'ExplicitChannelType(LND)(opt)',
 'unknown[55]',
 'ScriptEnforcedLease(LND)(opt)']
</code></pre>
<p>(maintaining the order the bits are set in the bitset)</p>
<p>The large number of <code>0</code> is due to bit 2023 being set: <code>script_enforced_lease</code>, an experimental feature by <code>lnd</code>, which iirc is used by their proprietary Pool implementation.</p>
