<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>

CC BY-SA 4.0
2022-11-28T10:01:36.950Z
2022-11-28T10:01:36.950Z
cdecker
<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>

<lightning-network><core-lightning>
CLN listnodes command occasionally returns too many features flags
Zephyrus
# CLN listnodes command occasionally returns too many features flags

(Asked by: username_0 on 2022-11-27)

The [BOLT #9 specification](https://github.com/lightning/bolts/blob/master/09-features.md) 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?

**Tags:** lightning-network, core-lightning


---

## 1 answers

### Answer by username_1 on 2022-11-28. Score: 1 | Accepted answer

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.


---

