Сначала простое объяснение, затем технический разбор.
Как работает схема простыми словами
Вам говорят: «Перевод завис. Оплатите комиссию — и деньги придут». Вы ожидаете небольшой платёж, нажимаете подтверждение, а затем видите, что из кошелька ушла совсем другая сумма.
В одном из вариантов такого обмана мошенник заранее готовит транзакцию — перевод ваших BTC на свой адрес. Вам её показывают как «оплату комиссии» или «разблокировку». Если вы подтверждаете и подписываете именно этот перевод, вы сами даёте разрешение отправить деньги. Сеть исполняет подписанную транзакцию, а не обещание человека, который её прислал.
Есть и другой вариант: нужная подпись уже получена раньше или ключ кошелька уже известен мошеннику. Тогда подготовленный перевод могут отправить позже. Доплата комиссии иногда лишь помогает подтвердить уже разрешённое списание.
Но без подписи или другого действительного права расходовать ваши BTC эта схема не работает. Если вы просто оплачиваете отдельный перевод из своего защищённого кошелька, получатель не получает доступ к остальному балансу. Поэтому история «кто-то оплатил комиссию — у другого автоматически списалось всё» пропускает главный момент: откуда взялось разрешение на списание.
Теперь разберём, что может скрываться за этой историей: PSBT, подмена сдачи, режим SIGHASH, ошибка nonce и утечка ключа. Это разные возможные механизмы, а не обязательные этапы одной атаки. Конкретный случай устанавливают по транзакциям и действиям владельца.
Что происходит внутри Bitcoin
Баланс Bitcoin складывается из неистраченных выходов транзакций — UTXO. Новый перевод расходует конкретные UTXO и создаёт новые выходы. Разница между суммой входов и суммой выходов составляет комиссию. Низкая ставка комиссии может задержать подтверждение, но не создаёт разрешения на расходование других средств.
Следует различать подготовленный файл, подписанную транзакцию, транзакцию в мемпуле и перевод, включённый в блок. PSBT с неполным набором подписей ещё не обязательно пригодна для отправки. Надпись «pending» на сайте сама по себе не доказывает, что перевод существует в сети.
Полностью подписанную транзакцию можно передать в сеть позже. Поэтому разрешение на расходование иногда возникает задолго до видимого списания. Исчезновение записи из мемпула или удаление файла из интерфейса не означает, что у другого участника больше нет копии подписи.
Обман при подписании PSBT
PSBT — стандартный формат обмена данными для частично подписанных Bitcoin-транзакций. Он позволяет разделить подготовку перевода и создание подписей, в том числе при работе с аппаратным кошельком. Сам формат не является вредоносным. Опасность появляется, если человек подписывает подготовленный посторонним участником перевод, не проверив его содержание.
Перед подтверждением существенны получатели, суммы, комиссия и принадлежность сдачи. BIP 174 описывает проверки входных данных, допустимости SIGHASH и распознавания сдачи. Аппаратное устройство полезно только вместе с проверкой данных на его доверенном экране.
Подмена адреса сдачи
При расходовании UTXO его стоимость используется целиком. Если платёж меньше этой стоимости, остаток обычно возвращается владельцу отдельным выходом сдачи. Например, при входе 1 BTC, платеже 0,01 BTC и комиссии 0,0001 BTC сдача составляет 0,9899 BTC.
Если в подготовленной транзакции этот остаток направлен постороннему лицу и владелец подтверждает такой перевод, он теряет основную часть суммы, хотя ожидаемый небольшой платёж тоже проходит. Это условный пример, а не описание установленного инцидента.
При обычной подписи, которая фиксирует все выходы, нельзя просто заменить адрес сдачи после подписания и сохранить действительность той же подписи. Подмена должна попасть в подписываемые данные либо потребовать нового подтверждения. Для подписи с иной областью действия результат зависит от её режима и остальных подписей.
Почему режим SIGHASH имеет значение
SIGHASH задаёт, какие части транзакции защищает подпись от изменения. В классических и SegWit v0 транзакциях доступны разные режимы. Они предусмотрены протоколом, поэтому слово «нестандартный» здесь означает необычный для конкретного пользовательского действия, а не автоматически недопустимый.
| Режим | Что нужно понимать |
| SIGHASH_ALL | Фиксирует все выходы, включая получателей и суммы. |
| SIGHASH_NONE | Не фиксирует выходы. Их могут защищать другие подписи. |
| SIGHASH_SINGLE | Фиксирует соответствующий выход; защита остальных зависит от других подписей. |
| ANYONECANPAY | Ограничивает привязку к входам подписываемым входом. Защита выходов зависит от базового режима. |
Источник таблицы — BIP 143 и руководство Bitcoin Developer Guide.
Подпись с ограниченной областью защиты не даёт доступа ко всему кошельку: она относится к определённому расходованию. Но ожидания владельца могут оказаться шире гарантий этой подписи. Поэтому необычный режим при обычном платеже требует понятного объяснения. Для Taproot правила подписи следует проверять отдельно.
Ошибка генерации nonce в ECDSA
При создании ECDSA-подписи используется секретное значение nonce k. Это не комиссия и не счётчик переводов. Повторение одного k для разных подписываемых сообщений с тем же ключом, его раскрытие или некоторые ошибки генерации могут позволить восстановить приватный ключ. Наличие публичных подписей само по себе такой возможности не создаёт.
После восстановления ключа возможны новые подписи на расходование защищённых им средств. Здесь причина потери — дефект подписывающего программного обеспечения, а не действие плательщика комиссии. Одна уязвимая подпись не обязательно раскрывает все ключи, производные от seed-фразы.
RFC 6979 описывает детерминированную генерацию nonce; библиотека libsecp256k1 поддерживает такой подход. Повторное подписание одного и того же сообщения в корректной детерминированной реализации нельзя автоматически приравнивать к опасному повторению nonce для разных сообщений.
ECDSA не охватывает все современные Bitcoin-транзакции. В Taproot применяются подписи Schnorr по BIP 340. Безопасность nonce остаётся существенной, но переносить описание конкретной ECDSA-ошибки на любой адрес без проверки типа расходования нельзя.
Заранее скомпрометированный кошелёк
Если приватный ключ или seed-фраза уже известны постороннему лицу, ему не требуется получать подпись владельца заново. Иллюстрацией служит импорт seed-фразы, которую передал другой человек: такой кошелёк нельзя считать находящимся только под контролем получателя. Аналогичный риск возникает при утечке резервной копии или работе поддельного кошелька.
Перевод денег на такой кошелёк может предшествовать их расходованию другим обладателем ключа. Просьба «пополнить для комиссии» в этом случае служит объяснением для пользователя, а возможность списания существовала раньше. В Bitcoin комиссия включается в транзакцию в BTC; отдельного обязательного gas-токена для обычного BTC-перевода нет.
Знание одного приватного ключа и знание всей seed-фразы имеют разный масштаб последствий. В первом случае под угрозой средства, условия расходования которых позволяют использовать этот ключ. Во втором — потенциально многие производные ключи кошелька. Формулировка «спишутся все деньги» требует проверки состава UTXO и доступных злоумышленнику полномочий.
Какую роль играют RBF и CPFP
RBF позволяет заменить неподтверждённую транзакцию конфликтующей транзакцией, удовлетворяющей правилам узла, обычно ради повышения комиссии. Замена также должна быть действительной: повышение комиссии не отменяет требования к подписи и условиям расходования.
CPFP использует дочернюю транзакцию, расходующую выход неподтверждённой родительской. Её комиссия может сделать подтверждение связанного пакета привлекательнее для майнера. Участник должен иметь право расходовать выбранный выход; создание дочерней транзакции не разрешает ему произвольно менять перевод из чужого кошелька.
Следовательно, ускорение может помочь подтвердить уже разрешённый нежелательный перевод. Однако оно не создаёт само разрешение. Задержка подтверждения и кража средств — разные события, даже если пользователь видит их как одну историю про комиссию.
Что проверять в конкретном случае
Название Retention Address или Retention Attack само по себе не определяет условия расходования в Bitcoin. «Адрес удержания» может быть внутренним термином сервиса. Проверять нужно скрипт, транзакцию и полномочия участников, а не название адреса. Без этих данных связывать Retention с конкретной уязвимостью некорректно.
Для установления причины нужны TXID исходной и последующих транзакций, состав входов и выходов, суммы, адреса, название кошелька и последовательность подтверждений. Если передавалась PSBT, полезна её копия до подписания. Скриншот с балансом или слово Retention этих данных не заменяют.
Основной вопрос — откуда взялось разрешение на расходование. Если владелец подписывал файл, проверяют подписанные данные и SIGHASH. Если подписания не было, исследуют утечку ключей, происхождение seed-фразы и работу приложения. Подмена сдачи требует проверки получателя остатка. Ошибка nonce требует анализа соответствующих подписей и реализации, а не догадки по задержке.
Перед новым подтверждением следует проверить итоговые суммы, комиссию, получателей и сдачу в доверенном кошельке. Seed-фразу и приватные ключи нельзя вводить на сайтах «активации». При подозрении на утечку seed-фразы защита оставшихся средств требует нового кошелька с новой фразой на доверенном устройстве. Для разбора нужно сохранить переписку, файлы и сведения о транзакциях, не раскрывая секретные ключи.
Источники
Документация Bitcoin и первичные технические материалы:
https://bitcoin.org/en/how-it-works
https://developer.bitcoin.org/devguide/transactions.html
https://www.rfc-editor.org/rfc/rfc6979
https://github.com/bitcoin-core/secp256k1/blob/master/README.md
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
https://bitcoincore.reviews/24152