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.