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?

1 Answer 1


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:


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.