Уяви, що тобі надіслали біткоїн із низькою комісією, і платіж досі не підтверджено. Якщо гаманець підтримує CPFP для цього платежу, можна створити наступну транзакцію, наприклад на іншу власну адресу. Початкову називають батьківською, а нову — дочірньою: вона витрачає створений батьківською вихід, тобто суму з умовами витрачання. Щоб отримати комісію дочірньої транзакції, майнеру потрібна й батьківська. Початковий платіж не змінюється; більша сума комісій може допомогти з підтвердженням, але не гарантує його строку.
Анна чекає на 100 000 sat. Скорочення sat означає сатоші, найменшу одиницю біткоїна. Платіж уже видно, але відправник указав малу комісію, і транзакція ще не потрапила до блоку. Гаманець Анни дозволяє витратити цей непідтверджений вихід. Вона створює з нього нову транзакцію на власну адресу й пропонує більшу комісію. Анна не платить відправникові чи окремому сервісу: це звичайна комісія біткоїн-транзакції. Майнер не може підтвердити нову транзакцію без початкової, адже потрібного виходу не було б у ланцюжку, який перевіряють. Батьківська має бути підтверджена раніше або стояти перед дочірньою в тому самому блоці разом з іншими потрібними непідтвердженими попередниками. Зворотної вимоги немає: батьківська може підтвердитися без дочірньої. [3] [5]
Візьмімо простий приклад без інших непідтверджених попередників. Батьківська транзакція має розмір 200 vB і комісію 200 sat. Віртуальний байт, vB, — міра розміру, отримана з ваги транзакції; sat/vB показує, скільки сатоші пропонують за таку одиницю. Дочірня займає 100 vB, і Анна платить за неї 2 800 sat. Якщо дочірня має лише один вихід, зі 100 000 sat надходження в Анни залишиться 97 200 sat. Разом транзакції платять 3 000 sat за 300 vB, тобто 10 sat/vB. Сама дочірня пропонує 28 sat/vB, але майнеру потрібно включити й батьківську транзакцію з низькою комісією. Якщо дивитися лише на високу ставку дочірньої, ця залежність губиться. Це навчальний розрахунок, а не рекомендована ставка на сьогодні; реальні розміри й потрібну загальну комісію перевіряє гаманець. Інші необхідні попередники змінять розрахунок. Деталь для поглибленого вивчення: під час локального приймання пакета вже прийняті транзакції не враховують повторно, а вузол — програма, що перевіряє та передає транзакції, — може використовувати скориговані комісії. Тому показана там ставка не обов’язково збігається з простим спільним розрахунком для майнера. Скоригована комісія тут є локальним значенням для рішень вузла; вона не змінює суму, яку транзакція фактично сплачує. [3]
CPFP — не кнопка, за допомогою якої будь-хто може прискорити чужу транзакцію. Потрібно мати змогу витратити один із виходів батьківської та виконати його умови, зокрема надати підписи. Анна може це зробити як одержувачка; відправник іноді може використати вихід із рештою власних коштів, який називають change. Просто бачити суму в оглядачі або Watch-only Wallet недостатньо. Watch-only Wallet дозволяє стежити за платежами, але сам не зберігає приватних ключів, потрібних для витрачання коштів. Гаманець також має підтримувати витрачання непідтвердженого виходу. Перед підписанням перевір, який вихід витрачаєш, куди підуть кошти, скільки залишиться та якою буде загальна комісія. Якщо вихід малий, комісія може поглинути значну частину його вартості. [5]
Replace-by-Fee (RBF) створює нову конфліктну транзакцію, яка має замінити початкову. Вона витрачає щонайменше один спільний вхід, але весь набір входів не зобов’язаний бути однаковим. CPFP залишає початковий платіж та його ідентифікатор і додає ще одну транзакцію. Для RBF потрібно виконати умови входів заміни; для звичайного CPFP — умови виходу початкового платежу. Тому одержувач може мати змогу використати CPFP, хоча не може підписати заміну відправника. Інший незалежний платіж із великою комісією не допоможе: дочірня транзакція має справді залежати від платежу, що очікує. [3]
Вища спільна ставка дає майнеру більше підстав узяти обидві транзакції, але не бронює місця в наступному блоці. Можуть надійти транзакції з вищими комісіями, або пакет не дійде до деяких майнерів. Тому стеж за підтвердженнями початкового платежу й дочірньої транзакції. Повідомлення вузла про прийняття ще не означає підтвердження в блоці. Якщо відправник замінить початковий платіж через RBF, дочірня транзакція з посиланням на старий вихід не зможе сама приєднатися до іншої нової транзакції; ситуацію доведеться оцінити заново. Створення дочірньої також не перетворює непідтверджене надходження на гарантований платіж. [3]
Наступні розділи пояснюють правила для поглибленого читання та роботи з власним вузлом. Mempool — список транзакцій, що очікують у конкретному вузлі, а не спільна черга всієї мережі. Пакет — група транзакцій, поданих разом. Важливо розрізняти три рішення: чи є транзакція дійсною, чи прийме її вузол і чи вибере її майнер. Консенсус визначає чинність транзакцій і блоків. Політика mempool визначає локальне прийняття та ретрансляцію; правила майнера — відбір до кандидатного блоку. CPFP не змінює консенсус. Економічно вигідний пакет може не відповідати місцевим правилам, а прийняття одним вузлом не зобов’язує інших вузлів чи майнерів. [3] [5]
Способи спільного передавання батьківської та дочірньої транзакцій розвиваються. Package CPFP означає оцінювання пов’язаних транзакцій як пакета. RPC — команда для взаємодії з вузлом; minrelaytxfee позначає його мінімальну ставку для звичайного поширення. TRUC — особливий режим транзакцій з обмеженими зв’язками між попередниками та нащадками. Наведена нижче історія стосується зазначених версій Bitcoin Core. Bitcoin Core 26 додав RPC submitpackage і package CPFP: дочірня могла допомогти батьківській зі ставкою нижче динамічного мінімуму mempool, але тоді не нижче мінімальної ставки ретрансляції. Це обмеження не є незмінним. Core 31 дозволяє в підтримуваній ретрансляції пакета з однією батьківською та однією дочірньою батьківську транзакцію зі ставкою нижче minrelaytxfee, навіть із нульовою комісією, також поза TRUC; інші непідтверджені батьківські транзакції дочірньої вже мають бути в mempool. Локальне прийняття й далі не гарантує однакового поширення всією мережею. [1] [2]
Вузол не може приймати мережі залежностей довільного розміру. Попередник потрібен перед іншою транзакцією, а нащадок витрачає виходи далі в цьому ланцюжку залежностей. WU означає одиниці ваги транзакції, а топологія описує її зв’язки з іншими. Ці технічні межі належать до політики відповідної версії вузла. Ліміти захищають пам’ять, ресурси процесора і пропускну здатність. Старі версії Core обмежували кількість і розміри предків та нащадків; Core 31 замінив ці ліміти mempool лімітами зв’язаних кластерів. Окремі пакетні ліміти залишилися: документація Core 31 вказує максимум 25 транзакцій і загальну вагу 404000 WU. Вага — не віртуальний розмір. Неправильна топологія, конфлікт чи невідповідність місцевим правилам щодо прийнятних форм транзакцій (стандартності) можуть заблокувати CPFP навіть за достатньої комісії. [2] [3]
Пов’язані непідтверджені транзакції не завжди можна економічно оцінювати окремо. Cluster Mempool дозволяє вузлу розглядати їхні зв’язані групи. Cluster — уся зв’язана група; менша група, яку обробляють під час відбору транзакцій, називається chunk. Це не частини вже підтверджених блоків. Bitcoin Core 31 використовує Cluster Mempool: кластер складається з транзакцій, пов’язаних відносинами батьківська–дочірня в будь-якому напрямку. Типові ліміти — 64 транзакції та 101 kB віртуального розміру на кластер; їх можна налаштувати. Порядок враховує групи, які майнять разом, — chunks — та їхні ставки. Історичний CPFP carveout дозволяв обмежений виняток із ліміту нащадків; Core 31 його скасував, і так обійти ліміт кількості транзакцій кластера не можна. [2] [4]
Команди в цьому розділі не взаємозамінні. Тест може лише описати результат; подання пакета вже може справді прийняти й поширити підписані транзакції. Поле vsize показує віртуальний розмір. Звичайний гаманець може подбати про ці деталі за користувача. У Core 31 RPC getmempoolentry для транзакції в mempool цього вузла показує комісії, vsize, залежності та дані chunk; getmempoolcluster показує пов’язаний кластер. RPC testmempoolaccept виконує локальну перевірку без прийняття й розсилання; для кількох транзакцій предки мають передувати нащадкам, а транзакції не повинні конфліктувати між собою чи з mempool. RPC submitpackage справді подає підтримуваний пакет для прийняття до mempool і поширення, а не лише тестує. Перевіряй результати окремих транзакцій, версію та конфігурацію; жоден результат не гарантує включення транзакції до блоку. [2] [6] [7] [8] [9]
Для повної картини прочитайте також Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, Транзакція, UTXO. На цю статтю також посилаються Change Address, Підтвердження, Подвійна витрата, Fee Rate.