Бит функциональности

В Lightning нет номера версии, который могли бы сравнить пиры, поэтому два узла выясняют, что они умеют делать вместе, обмениваясь битовым полем в момент подключения. BOLT 9 назначает 25 именованных пар, от бита 0 до бита 67, и никто не может установить оба бита одной пары. Если ваш кошелек отклоняет счет, который оплачивает другой кошелек, отсутствующий бит функциональности стоит проверить в числе прочего.

Как это работает

Биты функциональности отсчитываются от младшего бита битового поля, начиная с бита 0, который имеет значение 0x1 и считается четным.

Их выдают парами, и в этом вся хитрость: нечетный бит означает, что узел поддерживает функциональность, четный бит означает, что он ее требует. Поэтому возможность может появиться как необязательная, тихо распространиться и позже стать обязательной, а BOLT 9 указывает, что устаревшие узлы ее отклонят, так что несовместимость обнаруживается при встрече двух узлов, а не посреди платежа. Требования говорят остальное прямо: исходный узел не должен устанавливать оба бита пары, а принимающий узел, который все же видит оба, считает функциональность обязательной.

Некоторые функциональности опираются на другие, и отправитель несет всю цепочку. Базовые многочастные платежи занимают биты 16 и 17 и зависят от payment_secret; каналы zeroconf занимают 50 и 51 и зависят от option_scid_alias; option_onion_messages_only_channels на битах 66 и 67 зависит от обычных onion-сообщений. Исходный узел должен установить все транзитивные зависимости, поэтому код за одним флагом функциональности может исходить из того, что поддерживающие биты присутствуют, а не проверять их заново.

Пять из 25 пар теперь читаются только как ASSUMED: 0/1, 8/9, 12/13, 14/15 и 44/45. Каждая стала настолько распространенной, что считается, будто она есть у каждого узла, и ее семантика сохраняется только в более ранних редакциях спецификации. Таблица также пропускает номера: ничего не назначено на 2/3, 20/21, 30/31, 32/33, с 52 по 59 и на 64/65, так что пропуски обычны.

Где это встречается

Биты функциональности передаются в нескольких разных местах, и столбец Context таблицы BOLT 9 указывает, к каким из них относится каждая пара; в шести из 25 строк он пуст.

I обозначает сообщение init, которым обмениваются два пира при подключении, N обозначает node_announcement, рассылаемое в граф сплетен, C обозначает channel_announcement, 9 обозначает счет BOLT 11, B обозначает поле allowed_features ослепленного маршрута, а T обозначает channel_type, согласуемый при открытии канала. Многие биты встречаются только в одном контексте: option_payment_metadata, биты 48 и 49, есть только в счете, а option_anchors на 22 и 23 встречается в init, в сплетнях и как тип канала, но никогда в счете.

Где два контекста расходятся, побеждает счет: обоснование BOLT 9 указывает, что для флагов, передаваемых и в node_announcement, и в BOLT 11, значения из счета преобладают над объявленными. Поэтому кошелек читает возможности из счета, который вы вставили, а не из того, что получатель объявил сети сплетен несколькими часами ранее.

Phoenix, созданный ACINQ на его реализации Eclair, запускает настоящий узел на вашем смартфоне, поэтому принимает ли он многочастный платеж или ослепленный маршрут, решает битовое поле, которым он обменивается с пиром, а не рекламная страница. Muun показывает ончейн и Lightning как один баланс, и его платежи Lightning все равно сводятся к битам в счете.

Бит функциональности vs бит версии

Бит функциональности согласует возможности между двумя пирами Lightning; бит версии сигнализирует о мягком форке в заголовке блока биткоина. BIP-9 дает майнерам биты с 0 по 28 поля версии заголовка и фиксирует развертывание при 1916 из окна в 2016 блоков в основной сети, после чего оно действует для каждого следующего блока. Бит функциональности никого не связывает: это утверждение между двумя пирами, верное в одном соединении и неверное в следующем, без порога, без тайм-аута и без активации во всей сети. Lightning согласует, что два узла будут делать друг для друга; биткоин решает, что должны принять все.