Bitcoin-транзакция в mempool: как fee rate, RBF и CPFP влияют на подтверждение

До блока транзакцию видят узлы, но каждый — по-своему

Узел проверяет consensus rules и собственную relay policy, прежде чем добавить операцию в memory pool и передать peers. Другой узел может ещё не получить её, уже удалить при нехватке памяти или применять иной минимальный fee rate. Поэтому «есть в одном explorer» означает наблюдение конкретной инфраструктуры, а не запись в реестре всех участников сети.

Майнер сравнивает ставку за место, а не только общую fee

Абсолютная transaction fee равна разнице между суммой inputs и outputs. Для сравнения затрат на block space её делят на virtual size: получается sat/vB. Транзакция с fee 4 000 sat и размером 400 vB даёт 10 sat/vB; другая с fee 3 000 sat и размером 150 vB — 20 sat/vB. Вторая платит меньше satoshi, но предлагает больше за единицу места.

Неподтверждённые переводы образуют семьи

Если B тратит output ещё неподтверждённой A, B становится descendant, а A — ancestor. Узел хранит эти зависимости; block builder может оценивать связанную группу, потому что child нельзя включить раньше parent. Это и объясняет CPFP: новая дочерняя транзакция с высокой fee делает суммарный package экономически привлекательнее.

Пример показывает арифметику, а не гарантию включения. Узел и miner policy ограничивают цепочки, размер и правила package acceptance; конкретный кошелёк должен контролировать подходящий output и уметь построить child. Получатель иногда способен применить CPFP к полученному output, отправитель — к change output, но это определяется фактической структурой транзакции.

RBF меняет конфликтующую версию, CPFP оставляет parent

В общей RBF-модели replacement конфликтует хотя бы по одному input и должен пройти актуальные policy fee constraints; он не обязан сохранять весь исходный набор inputs. Конкретный RPC Bitcoin Core bumpfee, напротив, включает все original inputs, может добавить новые и возвращает новый txid. Современная документация Core не требует, чтобы исходная транзакция обязательно сигнализировала opt-in RBF, а policy самого Core эволюционирует. Но кошельки, сервисы и другие node implementations могут поддерживать разные действия и версии правил. Практический вопрос звучит не «RBF существует?», а «может ли этот кошелёк сейчас заменить именно эту транзакцию и какие outputs будут в replacement?».

Исчезновение из mempool не возвращает inputs отдельной операцией

Неподтверждённая запись может быть evicted или забыта конкретным узлом. В блокчейне при этом не возникает «refund transaction». Если inputs исходной транзакции были подтверждёнными неизрасходованными выходами и их не потратил подтверждённый конфликт, удаление записи из mempool не уничтожает эти UTXO. Но output, созданный только неподтверждённым parent, не входит в подтверждённый набор неизрасходованных выходов (UTXO set), пока parent не попадёт в блок. Wallet может временно показывать confirmed inputs как занятые из-за своей локальной истории, поэтому abandon, rebroadcast и rebuild — разные действия, зависящие от приложения.

Результат диагностики — не обещание времени, а новая проверяемая запись: либо исходный txid включён в блок, либо replacement получил собственный txid, либо parent и child образуют видимый package. До одного из этих исходов pending остаётся наблюдением, а обычная повторная отправка рискует создать отдельный платёж.