Package Relay позволяет узлам Bitcoin совместно передавать и оценивать связанные неподтверждённые транзакции. Это полезно, когда первая предлагает слишком маленькую комиссию, но следующая, расходующая её выход, добавляет достаточно для обеих. Правила действительности и местные правила узла сохраняются; совместная оценка не гарантирует подтверждения.
Анна ждёт платёж в биткоинах. Отправитель указал низкую комиссию, а спрос на место в блоках с тех пор вырос. Блок объединяет транзакции в пакет, добавляемый в общую историю. Узел — программа, которая проверяет транзакции и блоки и обменивается данными с другими участниками сети. Поэтому некоторые узлы отказываются помещать транзакцию в свой mempool — локальный набор неподтверждённых транзакций. Анна хочет добавить комиссию следующей транзакцией. Но та расходует монеты, о поступлении которых отказавший узел ещё не знает. Package Relay помогает преодолеть этот разрыв: узел получает нужный контекст и может рассматривать связанные транзакции вместе. [1] [6]
Первую транзакцию называют родительской, а расходующую её выход — дочерней. Анна может создать дочернюю, если способна выполнить условия расходования выхода родительской: конкретной суммы, доступной для дальнейшей траты. Например, перевести полученные монеты на другой свой адрес и выделить часть на комиссию. Это CPFP (Child Pays for Parent): более высокая комиссия дочерней транзакции может помочь подтвердить обе. Package Relay помогает передаче и оценке, но не платит комиссию, ничего не подписывает и не даёт доступа к чужим монетам. [1] [5]
Допустим, родительская транзакция занимает 200 vB и платит 200 sat, а дочерняя — 100 vB и 1300 sat. vByte (vB) измеряет виртуальный размер транзакции, обычно используемый для расчёта комиссий; sat — малая единица биткоина. Вместе они платят 1500 sat за 300 vB, то есть 5 sat/vB. Это не простое среднее отдельных ставок 1 и 13 sat/vB. Предполагаются только эти две ещё не принятые транзакции, без других неподтверждённых предков и местных корректировок комиссий. Уже принятые транзакции узел повторно не учитывает, поэтому важен точный набор оцениваемых зависимостей. [5] [3]
Вход дочерней транзакции ссылается на выход родительской. Совместная оценка может быть полезна, но не позволяет пропустить недостающую историю монет. В списке каждый включённый родитель располагается раньше потомка; это топологический порядок. Подписи и остальные правила действительности всё равно проверяются. Цифровая подпись подтверждает разрешение на платёж с помощью закрытого ключа — секретного числового значения, не раскрывая сам ключ. Две транзакции, тратящие одни и те же монеты, не становятся совместимыми благодаря дополнительной комиссии. Ограничения количества, размера и структуры пакета также сдерживают нагрузку на узел: они не разрешают отправлять сколь угодно длинную цепочку. [5] [3] [7]
Кошелёк — приложение или устройство для получения и отправки биткоинов. Доставка означает, что узел получил данные. Принятие — что он включил транзакции в mempool по своим правилам. Подтверждение требует включения в блок. У каждого узла свой mempool; успех на одном не показывает решение соседа. В Bitcoin Core 28.0 общая ставка может преодолеть изменяющийся минимум переполненного mempool, но в общем случае не отменяет отдельный минимум ретрансляции. В этой версии есть исключение для TRUC Transactions — особого типа транзакций с ограничениями. Поэтому дорогой потомок не спасёт любого родителя. [2] [5] [8]
BIP 331, предложенный Gloria Zhao, описывает согласование поддержки и сообщения для запроса сведений о предках и самих транзакций. Это более широкое предложение. Bitcoin Core 28.0 документировал ограниченное объединение одного родителя с одним потомком через существующий сетевой протокол. Локальный программный интерфейс RPC мог принимать и потомка с несколькими независимыми родителями, но это не означало такой же поддержки передачи между узлами. Эти сведения относятся к указанной версии; для другой проверяйте её документацию и возможности соседнего узла. [1] [2]
Команда submitpackage в Bitcoin Core 28.0 передаёт подготовленный пакет местному узлу. Ожидаются потомок и его неподтверждённые родители, не зависящие друг от друга, причём потомок должен быть последним. Читайте package_msg вместе с отдельными tx-results. Узел может принять часть пакета: ошибка автоматически не отменяет всё уже принятое. Даже общий успех не доказывает распространения по сети или подтверждения. Это не универсальная услуга ускорения платежей: нужны правильно построенные транзакции, а не только адреса. [3]
В отдельной тестовой среде testmempoolaccept проверяет принятие без рассылки. Если другая транзакция не прошла проверку, allowed может отсутствовать, поскольку данная транзакция не была полностью проверена. Условия тестового вызова и submitpackage тоже не вполне совпадают. Запишите версию, настройки, зависимости, размеры и комиссии, а принятие другим узлом наблюдайте отдельно. Чувствительные ко времени транзакции Lightning Network по-прежнему требуют своевременной реакции: сам Package Relay не устраняет перегрузку, неравномерное появление блоков или pinning — намеренное использование правил mempool для затруднения повышения комиссии. [4] [2] [1]
Для полной картины прочитайте эту статью вместе с Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. На эту статью также ссылаются CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.