Переполнение мемпула: почему зависают транзакции и что предпринять

На экране кошелька перевод остаётся в статусе pending, получатель его не видит, а сумма кажется зависшей между двумя кошельками. Не переживайте: сами монеты обычно не исчезают, ведь транзакция ещё не попала в блок и распоряжение средствами не завершено.

Важно понимать, что мемпул Bitcoin не является единой общей очередью. У каждого полноценного узла собственный набор неподтвержденных транзакций, собственные лимиты памяти и правила обработки. Поэтому один кошелек может показывать платеж как pending, второй — сообщать об ошибке, а получатель вообще не видеть перевода. Давайте разберёмся, где именно образовалась задержка и какое действие поможет быстрее всего.

Как устроена очередь неподтвержденных транзакций

Bitcoin Core — программа, на которой работает узел сети. Она проверяет присланные транзакции, хранит ещё не подтверждённые операции и передаёт их другим узлам. Жизненный цикл платежа выглядит так:

1. Кошелёк формирует транзакцию, подписывает её приватным ключом и отправляет узлам.

2. Узлы проверяют транзакцию и сохраняют её в своих локальных мемпулах.

3. Майнинговые пулы собирают из доступных операций кандидат в следующий блок.

4. После inclusion транзакции в блок появляется первое подтверждение, а за ним могут прийти остальные.

Слово «очередь» здесь помогает представить процесс, но общей очереди для всех пользователей нет. Ваша транзакция может одновременно находиться в мемпуле одного узла, отсутствовать в другом и уже обсуждаться майнинговым пулом как кандидат в следующий блок.

Мемпул Bitcoin — это собрание частных очередей у отдельных узлов, а не единая касса, где всем выдают место по единой очереди.

У Bitcoin Core есть два стандартных параметра, которые напрямую влияют на эту очередь. Максимальный размер мемпула задаётся опцией -maxmempool и по умолчанию составляет 300 МБ. Срок хранения транзакции по умолчанию равен 336 часам, то есть 14 суткам.

Если новые транзакции продолжают поступать, а объём мемпула достиг 300 МБ, узел начинает вытеснять операции с наименьшей комиссионной ставкой. После удаления транзакции её входы, то есть использованные монеты, освобождаются в памяти этого узла. Деньги снова становятся доступны отправителю в его кошельке.

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

Почему даже высокая комиссия не помогает

Майнеры оценивают транзакции по плотности комиссии, измеряемой в sat/vB, то есть сатоши на виртуальный байт. Этот показатель отвечает на вопрос: сколько сети приходится платить за каждое занявшее место в блоке единицу данных.

Здесь легко ошибиться, если смотреть только на общую сумму комиссии. Тяжёлая транзакция с большим объёмом данных занимает больше виртуальных байтов, поэтому даже крупная абсолютная плата может давать невысокую ставку sat/vB. Небольшая транзакция с меньшей комиссией окажется выгоднее для майнера, если ставка на один виртуальный байт у неё выше.

Базовый объём блока Bitcoin составляет около 1 МБ, а с учётом веса SegWit доступный объём данных может достигать примерно 4 МБ. Но даже свободное место блока не гарантирует включения конкретной операции: пул выбирает транзакции, конкурирующие за это место, и оценивает общий доход от будущего блока.

Порог sat/vB постоянно меняется. Новые платежи увеличивают нагрузку, старые операции получают блок, а настройки разных пулов и узлов отличаются. Поэтому комиссия, которая была достаточной при отправке, через некоторое время может оказаться ниже актуального уровня сети. Именно поэтому транзакция способна сначала попасть в мемпул, а затем долго ждать включения.

Если кошелёк показывает платеж как pending, полезно посмотреть не только общую комиссию, но и ставку sat/vB, рассчитанную на момент отправки. Текущий ориентир можно получить из комиссионного оценщика кошелька или сервиса, которым он пользуется. Эти данные постоянно обновляются, поэтому сохранённая вчера рекомендация сегодня уже может устареть.

С чего начать: найти реальную причину зависания

Прежде чем нажимать кнопку ускорения, стоит потратить несколько минут на проверку. Это поможет не запустить второй перевод поверх первого и понять, какой из способов вообще доступен.

1. Найдите TXID транзакции. Это идентификатор из 64 символов в шестнадцатеричном формате. С его помощью можно проверить наличие платежа в блокчейн-обозревателе и увидеть фактическое количество подтверждений. Отсутствие TXID и статус pending говорят о разных вещах: в первом случае отправка, возможно, не была принята сетью, во втором транзакция уже ушла, но ещё ждёт блока.

2. Посмотрите текущий статус и комиссионную ставку. Если операция подтверждена, проблема с мемпулом уже решена. Если она остаётся неподтверждённой, сравните её sat/vB с текущим уровнем и посмотрите, предлагает ли кошелёк операцию ускорения.

3. Поймите, с каким узлом работает кошелёк. Обычное мобильное приложение соединяется с сервисом, который обслуживает собственные узлы. Отдельные пользователи запускают Bitcoin Core самостоятельно. Ошибка mempool is full может относиться к локальному узлу или политике провайдера, даже если другие узлы сети готовы принять платёж.

4. Проверьте возможность RBF. Если в интерфейсе есть кнопка «ускорить», «повысить комиссию» или «заменить транзакцию», кошелёк умеет строить замену. Отсутствие такого пункта может означать, что конкретная операция не помечена как заменяемая либо сервис не поддерживает эту функцию.

5. Не создавайте вслепую второй перевод. Дополнительный платёж на тот же адрес способен запутать кошелёк и получателя, а при неправильной настройке привести к конфликту между транзакциями. Сначала используйте штатное ускорение либо разберитесь, можно ли оплатить ускорение со стороны получателя.

Как ускорить: RBF и CPFP

Replace-by-Fee: отправитель заменяет собственную транзакцию

Replace-by-Fee, или RBF, — механизм, стандартизированный в BIP 125. Он позволяет отправителю заменить зависшую операцию новой транзакцией с теми же входами и более высокой комиссией. После принятия замены старая транзакция становится недействительной, а новой присваивается другой TXID.

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

Современные кошельки обычно берут эту работу на себя. Пользователю достаточно открыть pending-платёж, выбрать увеличение комиссии и подтвердить операцию. Размер новой комиссии рассчитывается с учётом текущей сети и правил замены. Самостоятельно редактировать сырые данные транзакции новичку не стоит: здесь легко получить некорректную подпись или неверный набор входов.

RBF особенно удобен, когда завис именно платёж отправителя, а получатель не может влиять на его обработку. После ускорения у получателя может появиться новый TXID, поэтому сервисам, которые учитывают конкретный идентификатор перевода, потребуется время на обновление статуса.

Child Pays for Parent: комиссию платит следующая транзакция

Child Pays for Parent, или CPFP, работает иначе. Здесь создаётся дочерняя транзакция, которая spends ещё не подтверждённый выход родительской операции. Дочерняя транзакция получает повышенную комиссию, и майнинговый пул рассматривает обе как связанный пакет.

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

Здесь действует важное ограничение: дочерняя транзакция не может подтвердиться раньше родительской. Если исходный платёж остаётся в мемпуле с низкой ставкой, увеличение комиссии только следующей операции не отделит её от родителя. Пул включит обе транзакции, если суммарная выгода от пакета покажется ему достаточной.

CPFP не подойдёт получателю, чей адрес обслуживает кастодиальный или биржевой кошелёк: пользователь не может самостоятельно создать транзакцию, расходующую полученный UTXO. В такой ситуации ускорение обычно остаётся на стороне отправителя через RBF.

Ускорение помогает тогда, когда вы предлагаете сети не просто крупную сумму комиссии, а достаточную ставку за занимаемое в блоке место.

Что происходит через 14 дней и как очищается очередь

Срок 336 часов часто понимают как гарантию: «через две недели транзакция обязательно пропадёт». На деле это лишь стандартный срок хранения неподтверждённой операции в памяти узла Bitcoin Core.

Когда срок истекает, конкретный узел удаляет транзакцию из своего мемпула. Если за это время она не попала в блок, её входы освобождаются, и отправитель снова может распоряжаться этими монетами. Именно так работает механизм expiry.

Очистка очереди может произойти раньше. Когда мемпул заполнен, узел принудительно вытесняет операции с низкой комиссионной ставкой, даже если их срок хранения ещё далеко не истёк. Поэтому транзакция, которую кошелёк считал pending, иногда внезапно меняет статус на failed, rejected или возвращается в доступный баланс.

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

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

Отдельно про Ethereum: когда транзакция зависла из-за низкого газа

В Ethereum используется другая механика. Платежу нужны лимит газа, цена газа и место в блоке; при перегрузке сети транзакция с недостаточной оплатой может долго оставаться в ожидании. В некоторых кошельках это называют проблемой «низкого газа».

Здесь полезно различать лимит газа и его цену. Слишком маленький лимит газа обычно приводит к ошибке исполнения контракта, тогда как зависание pending-транзакции чаще связано с недостаточной комиссией за обработку.

Если кошелёк поддерживает замену, можно отправить транзакцию с тем же номером операции, или nonce, и более высокой оплатой газа. Если прежняя транзакция уже отброшена сетью, её можно повторить с актуальными параметрами. Значения 300 МБ и 336 часов в этом случае не применяются: лимиты Bitcoin Core относятся к его мемпулу, а правила Ethereum зависят от сети, кошелька и обслуживающего его узла.

Практический порядок для зависшего платежа выглядит так: найдите TXID, подтвердите его отсутствие в блокчейне, посмотрите текущую ставку, примените RBF при наличии такой функции, уточните у получателя возможность CPFP, а при отсутствии ускорения дождитесь подходящего блока. Не отправляйте второй перевод поверх первого и следите за статусом в нескольких независимых источниках.

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