Короткий ответ: CPFP, или Child Pays for Parent, позволяет владельцу выхода неподтверждённой Bitcoin-транзакции потратить его в новой операции с повышенной комиссией. Майнеру становится выгодно включить в блок обе транзакции, потому что дочерняя не может подтвердиться раньше родительской, а средняя ставка всего пакета оказывается выше.
Почему дочерняя комиссия помогает родителю
В модели UTXO каждая новая транзакция ссылается на конкретные предыдущие выходы. Если получатель тратит ещё не подтверждённый выход, возникает зависимость: сначала блок должен признать родителя, затем ребёнка. Узел хранит эту связь в мемпуле, а майнер может оценивать совокупный доход от связанного набора операций.
Представьте, что медленный родитель занимает 200 vB и заплатил 200 sat, то есть 1 sat/vB. Дочерняя операция размером 150 vB может добавить такую комиссию, чтобы сумма выплат за 350 vB соответствовала подходящей ставке для текущего спроса. Нельзя просто поставить ребёнку «обычную» комиссию и ожидать чуда: она должна компенсировать низкую ставку всего пакета.
Точный порог меняется вместе с мемпулом и политикой узлов. Поэтому не копируйте устаревшее число из инструкции и не обещайте определённый срок. Совместимый кошелёк обычно рассчитывает пакет сам. При ручной подготовке нужно знать виртуальный размер и комиссию обеих операций, а также проверить ограничения на цепочки неподтверждённых транзакций.
Кто может выполнить CPFP
Дочернюю транзакцию подписывает тот, кто контролирует один из выходов родителя. Это может быть получатель платежа либо отправитель, если у исходной операции есть выход сдачи на его кошелёк. Посторонний наблюдатель, знающий TxID и адрес, не получает такого права: для расходования UTXO всё равно требуется действительная подпись владельца.
Полученный баланс может отображаться как доступный, ожидающий или непроверенный. Кошелёк вправе запрещать его расходование до первого подтверждения. Это ограничение интерфейса, а не доказательство невозможности CPFP в протоколе. Не стоит ради обхода запрета вводить seed-фразу в незнакомый кошелёк. Риск компрометации всех средств намного выше пользы от срочного ускорения.
Перед началом убедитесь, что родитель действительно существует в мемпулах. Откройте его в нескольких обозревателях и проверьте адрес, сумму и отсутствие блока. Если сервисы расходятся, полезно сначала выяснить, почему транзакция исчезла из мемпула. Ребёнок не исправит родителя, который недействителен, уже заменён или больше не распространяется.
Практический алгоритм
- Найдите родительский TxID и проверьте Bitcoin-перевод по хешу в двух обозревателях.
- Определите выход, который принадлежит вашему кошельку: полученную сумму либо сдачу отправителя.
- Посмотрите размер и комиссию родителя. Если кошелёк показывает только общую плату, найдите также ставку в sat/vB.
- Выберите штатную функцию ускорения CPFP или создайте перевод на собственный новый адрес именно из нужного неподтверждённого выхода.
- Проверьте рассчитанную среднюю ставку пакета, адрес назначения ребёнка и итоговый расход до подписи.
- После отправки сохраните оба TxID. В обозревателе у ребёнка должна отображаться ссылка на неподтверждённого родителя.
Отправка на собственный адрес не делает операцию бесплатной. Дочерняя комиссия вычитается из контролируемого выхода, поэтому итоговый баланс уменьшится. Если выход слишком мал, добавление нового входа увеличивает размер и может заметно поднять необходимую плату. Иногда разумнее подождать снижения загрузки, чем расходовать значительную часть небольшой суммы.
CPFP, RBF и повторная отправка
При RBF отправитель заменяет Bitcoin-транзакцию, используя те же входы. При CPFP родитель остаётся прежним, а к нему добавляется ребёнок. RBF обычно создаёт меньший дополнительный объём данных и может стоить дешевле. CPFP полезен получателю, который не управляет исходной операцией, или отправителю, когда кошелёк не предлагает замену, но позволяет потратить сдачу.
Обычная повторная отправка той же суммы не является ни RBF, ни CPFP. Если она использует другие UTXO, обе операции могут попасть в блок и получатель получит два платежа. Безопасный ребёнок расходует конкретный выход родителя, а безопасная замена конфликтует с его входами. Эти признаки нужно проверять по структуре транзакций, а не по похожим подписям в истории кошелька.
Когда метод не сработает
CPFP бесполезен после подтверждения родителя, при отсутствии доступного выхода и при конфликте, который уже победил в сети. Узлы также ограничивают число и общий размер неподтверждённых предков и потомков. Очень длинная цепочка может не пройти их политику. Отказ одного сервиса ещё не описывает всю сеть, но многократная рассылка разных вариантов усложняет диагностику.
Если ускорение не принимается, подготовьте для поддержки два TxID, публичные адреса, суммы, размеры, комиссии, время создания и текст ошибки. Не отправляйте seed-фразу, приватный ключ, пароль, 2FA или резервную копию файла кошелька. Для изучения связи родителя и ребёнка секреты не требуются.
Итог
CPFP работает не за счёт магической доплаты старой операции, а благодаря новой транзакции, которая зависит от её выхода. Убедитесь, что контролируете этот выход, оцените комиссию всего пакета и создавайте ребёнка штатным способом. Если задерживаются уже несколько связанных платежей, отдельно проверьте, как неподтверждённый родитель удерживает дочернюю транзакцию.
