Как превратить подпись из «чёрного ящика» в математическую систему наблюдаемых инвариантов

Аннотация

Эта статья не про «магический взлом Bitcoin» и не про сенсационную кнопку восстановления приватного ключа. Она про другое: как строго и математически корректно перевести подписи Schnorr (BIP340) и MuSig2 (BIP327) из формата «пара чисел (r, s)» в формат набора affine-ограничений, семейства скрытых нонсов и измеримых структурных функционалов.

Главная идея системы проста по формулировке, но нетривиальна по последствиям:

подпись — это не чёрный ящик, а уравнение над скалярами и точками, из которого можно восстановить семейство скрытых нонсов как функцию от кандидата секрета и затем изучать геометрию этого семейства.

В статье я покажу:

как устроен строгий BIP340 membership bridge;
почему скрытый нонс естественно рассматривать как функцию k_i(d') = s_i - e_i d' mod n;
как из этого появляются compression- и connectivity-метрики;
как частичная подпись MuSig2 приводится к protocol-valid affine-форме;
какие результаты уже подтверждены артефактами проекта;
и, что принципиально важно, что именно здесь доказано, а что не заявляется.

Интерактивный демонстрационный стенд доступен на GitHub. Откройте html файл любым браузером

1. Почему вообще нужен другой язык для подписи

Обычный способ думать о подписи такой: есть публичный ключ, есть сообщение, есть подпись — проверка сказала valid или invalid. На этом почти все инструменты останавливаются. Но если нас интересует не только проверка, а forensics, то этого мало. Нас интересуют вопросы другого класса:

Как строго отделить протокольно-корректные строки от любых псевдосигналов?
Можно ли перевести подпись в нормализованное affine-представление?
Можно ли анализировать не одну подпись, а ансамбль подписей одного ключа?
Можно ли не угадывать скрытый нонс напрямую, а исследовать семейство нонсов, индуцированное кандидатом секрета?
Можно ли измерять это семейство через интерпретируемые метрики: коллизии, повтор дельт, префиксные массы, локальную связность? Именно здесь возникает nonce-forensics как отдельная дисциплина.

2. Базовая алгебра: secp256k1, x-only и even-Y канонизация

Работа ведётся в группе secp256k1.

Поле: F_p, где p = 2^256 - 2^32 - 977
Порядок группы: n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
Базовая точка: G Все скалярные уравнения ниже понимаются по модулю n. Для BIP340 важна x-only модель публичного ключа и канонический even-Y представитель. Если P = d0 G, то в x-only формате секрет effectively нормализуется так:
d = d0, если y(d0 G) чётен,
d = n - d0, если y(d0 G) нечётен. То же касается нонса: используется такой скаляр k, для которого точка R = kG имеет even-Y представление. Это кажется технической деталью, но на самом деле здесь происходит важная вещь: мы перестаём работать с «произвольным знаком» точки и фиксируем каноническую геометрию представления.

3. BIP340 как affine-ограничение

Для сообщения m, x-only публичного ключа P_x и нонса k подпись BIP340 задаётся так:

$e = H_{tag}(r | P_x | m) \bmod n,$ $s = k + e d \bmod n.$

С точки зрения классической криптографии это стандартная подпись. Но с точки зрения nonce-forensics последнее равенство — уже ключевой объект:

$s = k + e d \pmod n.$

Это affine-уравнение по скрытому нонсу k и секрету d. И именно эта форма открывает дверь для дальнейшего анализа.

4. Строгий BIP340 membership bridge

Проверка подписи в системе строится не как «вызвали verify и забыли», а как нормализующий переход. Восстанавливается точка:

Подпись принадлежит BIP340-многообразию тогда и только тогда, когда выполнены одновременно:

0 <= r < p
0 <= s < n
R^* \neq O
y(R^*) — even
x(R^*) = r Это и есть membership bridge.

Зачем он нужен

Он решает сразу три задачи. Во-первых, он отделяет валидную подпись от невалидной не по одному биту истины, а по диагностируемой причине отказа:

r_out_of_field
s_out_of_range
r_star_is_infinity
r_star_odd_y
r_star_x_mismatch

Во-вторых, он переводит строку (r, s, P, m) в точку R^*, то есть в геометрически нормализованную форму.

В-третьих, он защищает последующий forensic-анализ от ложных сигналов: все метрики считаются только на строках, уже прошедших bridge. Это критически важно. Если не сделать этот шаг, то любой дальнейший «анализ структур» быстро превращается в игру с артефактами парсинга и мусорными строками.

5. Главная идея: скрытый нонс как функция от кандидата секрета

Из уравнения:

$s_i = k_i + e_i d \pmod n$

естественно следует определение:

$k_i(d') = s_i - e_i d' \pmod n.$

Здесь d' — не настоящий секрет, а кандидат. Если d' = d, то:

то есть мы попадаем в истинный канонический нонс строки. Если d' \neq d, то семейство k_i(d') становится affine-смещённой псевдослучайной конструкцией. Вот отсюда и рождается весь nonce-forensics слой.

Важная переинтерпретация

Обычно задачу формулируют так:

можно ли восстановить секрет d? Но корректнее и сильнее формулировать её так: существует ли такой функционал F, что F({k_i(d)}) заметно отличается от F({k_i(d')}) для ложных кандидатов? Это переводит разговор из области лозунгов в область измеримых математических свойств.

6. Почему одна подпись почти ничего не даёт

На одной подписи

$k(d') = s - e d' \pmod n$

все кандидаты выглядят примерно одинаково: это просто одно число по модулю n. Но если мы берём группу подписей одного и того же x-only публичного ключа:

$G(P_x) = {(r_i, s_i, m_i, e_i)}_{i=1}^m,$

то для каждого d' получаем целое семейство

$K(d') = [k_1(d'), \dots, k_m(d')].$

И уже над этим ансамблем можно измерять:

число коллизий,
число разных дельт,
плотность высоких префиксов,
локальные кластеры,
паритетно-симметричную повторяемость. То есть в центре системы стоит не отдельная подпись, а геометрия семейства скрытых нонсов.

7. Compression-модель: как измерять сжатие семейства

Compression отвечает на вопрос:

становится ли семейство K(d') более компактным, если подставить конкретный кандидат секрета?

7.1. Число различных нонсов:

$U_k(d') = |{k_i(d')}|.$

7.2. Число коллизий:

Если в данных есть reuse-сценарии, правильный d уменьшает U_k и увеличивает C_k.

7.3. Последовательные дельт:

$\Delta_i(d') = k_{i+1}(d') - k_i(d') \pmod n,$

для i = 1, ..., m-1.

7.4. Число различных дельт:

$U_\Delta(d') = |{\Delta_i(d')}|.$

7.5. Число повторяющихся дельт:

$C_\Delta(d') = (m-1) - U_\Delta(d').$

В ladder-сценариях правильный d уменьшает число различных дельт.

7.6. Префиксные метрики

Для числа бит b определим:

$Pref_b(k) = \left\lfloor \frac{k}{2^{256-b}} \right\rfloor.$

Тогда:

$U_{pref_b}(d') = |{Pref_b(k_i(d'))}|.$

На практике используются уровни:

U_pref_128
U_pref_64
U_pref_32
U_pref_16 Если нонсы имеют short/prefix bias, правильный кандидат даёт заметное уменьшение числа разных высоких префиксов.

7.7. Интерпретация

Compression — это не «магический score». Это набор прозрачных гипотез:

reuse → коллизии;
ladder → повтор дельт;
short nonce → малая энтропия high-prefix;
prefix bias → аномально малая разнообразность префиксов.

8. Connectivity-модель: локальная геометрия вместо глобальных агрегатов

Compression смотрит на глобальное сжатие. Connectivity смотрит на локальную форму семейства.

8.1. Два знаковых листа

Строятся две ветви:

$K^+(d') = sort({k_i(d')}),$ $K^-(d') = sort({-k_i(d') \bmod n}).$

Зачем это нужно? Потому что sign/parity-симметрии могут маскировать локальные структуры, если смотреть только на одну ветвь.

8.2. Режимы соседства

Рассматриваются четыре режима:

++
--
+-
-+ Для каждой пары ветвей считается локальная статистика ближайших соседей в окне ширины w.

8.3. Локальная delta-support метрика

Для режима mode вводится счётчик:

$\operatorname{count}_{\mathrm{mode}}(\delta)=\left|\{(x,y)\in \mathcal{N}_{\mathrm{mode}} : y-x=\delta\}\right|.$

Далее:

$Support_{mode}(d') = \max_\delta count_{mode}(\delta),$

и

$Support_{local}(d') = \max_{mode} Support_{mode}(d').$

В коде это соответствует max_local_delta_support.

8.4. Повторная масса дельт

Если одна и та же локальная разность повторяется много раз, возникает дополнительный сигнал:

$Mass_{repeat}(d') = \sum_\delta \max(count(\delta)-1, 0).$

В реализации это total_repeated_delta_mass.

8.5. Префиксная поддержка

Для ветвей K^+, K^- и набора b \in {128,96,64,32,16} считается:

$TopPref_b^+(d') = \max_u |{k \in K^+ : Pref_b(k)=u}|,$ $TopPref_b^-(d') = \max_u |{k \in K^- : Pref_b(k)=u}|,$ $TopPref_b(d') = \max(TopPref_b^+(d'), TopPref_b^-(d')).$

Ключевые реализованные метрики:

max_prefix128_support
max_prefix96_support
max_prefix32_support
max_prefix16_support

8.6. Интерпретация

Connectivity нужна тогда, когда структура проявляется не как грубая коллизия, а как:

повторяющиеся локальные сдвиги;
кластеры ближайших соседей;
устойчивые префиксные листья;
симметрии между K^+ и K^-. Именно здесь система начинает видеть то, что не видно простым счётом совпадений.

9. Почему MuSig2 требует отдельной математики

У BIP340 есть простая форма:

$s = k + e d \pmod n.$

У MuSig2 в финальной on-chain подписи внутренняя структура уже скрыта агрегированием. Поэтому на итоговой подписи делать тот же анализ напрямую нельзя. Нужен другой вход: partial signatures плюс session context. Это и есть принципиальный переход:

для MuSig2 forensic-анализ должен работать не на финальной подписи, а на protocol-valid частичных подписях с полным session context.

10. Protocol-valid affine-линеаризация MuSig2

Пусть участник использует два сырых нонса:

k1_raw
k2_raw Публичные точки:

$R_1 = k1_{raw} G,$ $R_2 = k2_{raw} G.$

Из полного session context восстанавливаются:

агрегированный ключ Q;
aggregate nonce R;
nonce coefficient b;
challenge e;
key aggregation coefficient a;
parity factors g и gacc.

10.1. Паритет ключа

Для aggregate key:

g = 1, если y(Q) even,
g = n - 1, если y(Q) odd. Из reference context берётся также gacc. Комбинированный фактор ключа:

$par_{key} = g \cdot gacc \pmod n.$

10.2. Паритет нонса

Для aggregate nonce R:

par_nonce = 1, если y(R) even,
par_nonce = n - 1, если y(R) odd. Эффективные компоненты нонса:

$k1_{eff} =\begin{cases}k1_{raw}, & par_{nonce}=1 \n-k1_{raw}, & par_{nonce}=n-1\end{cases}$ $k2_{eff} =\begin{cases}k2_{raw}, & par_{nonce}=1 \n-k2_{raw}, & par_{nonce}=n-1\end{cases}$

10.3. Эффективный нонс участника

$k_{eff} = k1_{eff} + b \cdot k2_{eff} \pmod n.$

10.4. Эффективный коэффициент секрета

$c = e \cdot a \cdot g \cdot gacc \pmod n.$

10.5. Итоговая affine-форма частичной подписи

Тогда partial signature участника принимает вид

$s_i = k_{eff,i} + c_i d_i \pmod n.$

Это центральный математический результат MuSig2-слоя. Он означает следующее:

частичная подпись MuSig2 допускает protocol-valid affine-линеаризацию, совместимую с тем же forensic-языком, что и обычная BIP340-подпись. После этого можно определить MuSig2-аналог семейства скрытых нонсов:

$k_{eff,i}(d') = s_i - c_i d' \pmod n.$

И над ним уже работают те же классы функционалов:

compression;
prefix-support;
connectivity;
groupwise ranking.

11. Dedup и sterile blind discipline: почему это не просто «сгенерированные игрушки»

Исследование подобного класса очень легко испортить искусственным усилением сигнала. Поэтому здесь принципиален слой data discipline.

11.1. Dedup по raw nonce pairs

Если две строки содержат одну и ту же пару

$(k1_{raw}, k2_{raw}),$

то это не независимые наблюдения для forensic-анализа, даже если они попали в разные тестовые контексты. Поэтому публичный partial-signature audit корпус учитывает:

число строк;
число различных сообщений;
число различных коэффициентов c_i;
число различных k_eff;
число различных raw nonce pairs. Это защищает исследование от ложного «накачивания сигнала».

11.2. Разделение public и truth

Каждый blind case разделён на два слоя:

public case — только наблюдаемые поля для solver/audit pipeline;
truth manifest — закрытый эталон для внешней проверки. Публичный слой не должен содержать секретных полей вроде:

secret
hex_d
musig_raw_secret_hex
musig_k1_raw_int
musig_k2_raw_int
musig_effective_k_int Это делает benchmark не просто синтетическим, а стерильным в смысле утечки истинных значений.

12. Что уже подтверждено артефактами

Ниже — только те результаты, которые уже отражены в отчётах и корпусах проекта.

12.1. BIP340 official vectors

Метрика	Значение
Всего официальных векторов	19
Ожидаемо валидных	9
Ожидаемо невалидных	10
Валидных, прошедших membership bridge	9
Невалидных, корректно отвергнутых	10
Все ожидаемо валидные прошли	true
Все ожидаемо невалидные отвергнуты	true

Это означает, что bridge не просто «примерно похож» на BIP340 verification, а согласуется с официальными векторами.

12.2. Реальные key-path Taproot подписи

Метрика	Значение
Просканировано файлов страниц	42
Просканировано транзакций	1050
Увидено P2TR inputs	64
Выделено key-path кандидатов	60
Размер корпуса	60
Проверка подписи пройдена	60
Membership bridge пройден	60
Все key-path подписи verified	true
Все key-path подписи прошли membership	true

Дополнительно был проведён локальный false-positive stress test:

Тест	Кандидатов	Fixed-point passes	Strict even-Y passes
Локальная сетка около подписи	17 280	0	0
Случайные near-кандидаты	7 680	0	0

Это важный аргумент против скепсиса: membership-мост не только пропускает валидные строки, но и не создаёт ложных срабатываний на близком шуме.

12.3. Holdout mainnet corpus

Метрика	Значение
Размер holdout-корпуса	1359
Точных verification-pass	1359
Membership-pass	1359

Это показывает, что bridge работает не только на официальных или игрушечных данных, но и на большом реальном корпусе.

12.4. Позитивные BIP340 control families

Family	Групп	Primary metric
`short_nonce128`	5	`high128_unique_count`
`short_nonce160`	5	`high64_unique_count`
`ladder`	5	`unique_delta_count`
`prefix_bias32`	5	`high32_unique_count`

Это означает, что система калибруется не на одном типе аномалии, а как минимум на четырёх разных leakage-гипотезах.

12.5. Protocol-valid MuSig2 control families

Family	Что моделирует
`raw_nonce_reuse`	повтор сырой пары нонсов
`raw_nonce_ladder`	лестничную структуру сырого нонса
`short_raw_nonce128`	сокращённый сырой нонс
`prefix_raw_nonce32`	общий high-prefix

Это критически важно: MuSig2-слой проекта не является «словесным продолжением BIP340», а имеет собственные protocol-valid контроли.

12.6. Dedup-public MuSig2 audit corpus

Метрика	Значение
Partial signatures в публичном корпусе	5
Различных сообщений	2
Различных коэффициентов `c_i`	5
Различных эффективных нонсов `k_eff`	5
Различных raw nonce pairs	5
Dedup по raw nonce pairs включён	true

Это маленький, но дисциплинированный аудит-корпус, очищенный от искусственных повторов.

12.7. Sterile blind case generation

Case	Сессий	Модель	Параметры нонса	Все подписи verified	Все membership-pass	Public без секретных полей	Sterile ready
`case_001`	20	baseline blind	`nonce_bits=128`	true	true	true	true
`case_002`	24	lite	`nonce_bits=128`, `k1_bits=64`, `k2_mode=fixed-one`	true	true	true	true
`case_003`	24	lite	`nonce_bits=128`, `k1_bits=32`, `k2_mode=fixed-one`	true	true	true	true
`case_004`	40	full	`nonce_bits=64`, `k1_bits=64`, `k2_bits=64`, `k2_mode=short-random`	true	true	true	true

Это, пожалуй, один из самых недооценённых результатов всей системы: экспериментальная дисциплина здесь формализована не хуже, чем алгебра.

12.8. Integrity-слой и blind verification

Артефакт	Public cases clean	Truth access	Verified recovery
`blind_benchmark_integrity_report.json`	true	false	false
`blind_solver_v2_case_001_integrity.json`	true	false	false
`blind_v3_case_002_integrity.json`	true	false	false
`blind_v3_case_003_integrity.json`	true	false	false
`blind_v4_case_003_integrity.json`	true	false	false
`blind_v5_case_003_integrity.json`	true	false	false
`blind_v6_case_003_integrity.json`	true	false	true
`v7_case_004_integrity.json`	true	false	true

Здесь важно интерпретировать таблицу правильно. Она не доказывает универсальную решаемость любой задачи. Она доказывает другое:

public cases действительно очищены от forbidden fields;
truth не подмешивается в solver-слой;
research pipeline эволюционирует и демонстрирует подтверждённые blind-successes на части protocol-valid кейсов.

12.9. Эволюция solver-ветки: что видно, а что не надо преувеличивать

Отчёт	Case	Модель	Параметры	Экспериментов	Exact/Liftable annihilators	Verified candidates	Blind recovery success
`blind_solver_v2_case_001_smoke.json`	`case_001`	baseline	`short_bits=128`	9	—	0	false
`blind_v5_case_003_solver_report.json`	`case_003`	lite	`short_bits=32`	6	9980 / 9980	0	false
`blind_v6_case_003_integrity.json`	`case_003`	lite	blind integrity	—	—	—	true
`v7_case_004_integrity.json`	`case_004`	full	blind integrity	—	—	—	true

Именно так и надо разговаривать со скептиком: не «у нас всё решается», а «вот честная траектория — ранние версии не решают, затем появляются protocol-valid blind-successes на более зрелых конфигурациях».

13. Что это всё на самом деле доказывает

На этом этапе система уже доказывает следующее.

13.1. Подпись можно перевести в строгую геометрию

BIP340-подпись — это не просто факт прохождения verify, а объект, который можно перевести в точку R^* и проверить на принадлежность точному even-Y/x-match многообразию.

14.2. Скрытый нонс можно анализировать как семейство, а не как единичную неизвестную

Определение:

$k_i(d') = s_i - e_i d' \pmod n$

даёт единый язык для анализа гипотез о weak nonces.

13.3. MuSig2 partial signatures допускают protocol-valid affine-редукцию

Это, возможно, самый важный результат на уровне архитектуры. Без него BIP340 и MuSig2 жили бы в разных мирах. С ним они сводятся к одному классу объектов: affine constraints вида:

$s = \text{nonce-term} + \text{coefficient} \cdot d.$

13.4. Наблюдаемая структура семейства скрытых нонсов измерима

Compression и connectivity — это не философия, а вполне конкретные семейства функционалов.

13.5. Эксперименты можно делать стерильно

Blind discipline, truth separation, dedup, integrity scanning — это самостоятельная ценность проекта.

14. Почему это важно для практики

Классический crypto tooling отвечает на вопрос «валидна ли подпись?». Эта система отвечает на другой вопрос:

какую геометрию создаёт семейство скрытых нонсов, если смотреть на подпись как на affine-ограничение, а не как на непрозрачный артефакт? Из этого следуют прикладные режимы:

forensic-аудит подписывающих систем;
анализ weak-nonce сценариев;
проверка дисциплины работы с nonce в MuSig2;
построение калибровочных и blind-корпусов;
экспериментальная оценка leakage-гипотез на synthetic, official и real-world данных. То есть ценность системы не в одном «чудесном solver-е», а в том, что она создаёт исследовательскую платформу гипотез.

15. Самая короткая формула всей системы.

Если сжать всё до одной строки, получится так.

BIP340-слой

$e_i = H(r_i | P_x | m_i) \bmod n,$

$k_i(d') = s_i - e_i d' \pmod n.$

Forensics-слой

По семейству:

$K(d') = {k_i(d')}$

вычисляются:

compression functionals;
prefix-support functionals;
local-connectivity functionals.

MuSig2-слой

$k_{eff,i} = k1_{eff,i} + b_i k2_{eff,i} \pmod n,$ $c_i = e_i a_i g_i gacc_i \pmod n,$ $s_i = k_{eff,i} + c_i d_i \pmod n,$ $k_{eff,i}(d') = s_i - c_i d' \pmod n.$

Именно это и есть фундаментальный каркас системы.

16. Вывод

На мой взгляд, главный результат здесь состоит не в одном «удачном отчёте» и не в одном solver-run. Подтверждённое ядро системы — это:

строгая BIP340 membership-геометрия;
affine-реконструкция скрытых нонсов как функции от кандидата секрета;
интерпретируемые compression/connectivity-функционалы;
protocol-valid MuSig2 affine-линеаризация;
dedup-aware sterile blind discipline. Именно в этом месте проект перестаёт быть набором заметок и становится исследовательской криптографической системой. Скептик может не принять закрытый solver-слой — и это нормально: он здесь специально не раскрыт. Но отвергать математический каркас уже значительно труднее, потому что он стоит на вполне конкретной алгебре, протокольной корректности и измеримых артефактах. Если сформулировать совсем коротко, то тезис статьи такой:

подпись Schnorr/MuSig2 — это не просто объект проверки. Это affine-структура, которая после нормализации и группового анализа превращается в наблюдаемую геометрию скрытых нонсов. И именно эта смена языка — от «проверить подпись» к «измерить семейство скрытых нонсов» — и составляет главное содержание всей теории.

Для серьёзного разговора о подписи этого уже достаточно, чтобы спорить не на уровне впечатлений, а на уровне модели.

Schnorr/MuSig2 Nonce-Forensics: