Miniscript

Анна хоче звично користуватися монетами за допомогою власного ключа. Цифровий підпис підтверджує дозвіл на платіж за допомогою приватного ключа — секретного числового значення, яке при цьому не розкривається. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Водночас Анна хоче передбачити шлях для Петра: він зможе витратити їх своїм ключем після 144 блоків від підтвердження цього виходу. Такий задум називають spending policy — правилами витрачання. Miniscript допомагає надати йому точного вигляду, з яким працюватиме гаманець. Петру все одно потрібен ключ; очікування його не замінює. Це простий приклад альтернативних шляхів доступу, а не автоматичний переказ чи виявлення того, що Анна втратила ключ. [1] [2] [10]

Правило, висловлене словами, ще не є програмою для перевірки мережею. Компілятор може вибрати конкретний Miniscript і перетворити його на Bitcoin Script. Output Descriptor описує отримані скрипти разом із ключами та, за потреби, шляхами їх виведення; він також може містити контрольну суму для виявлення помилок копіювання. Під час витрачання мережа перевіряє скрипт і надані дані, а не початкове речення. Miniscript не додає інструкцій і не змінює консенсус — спільні правила дійсності. Він не може виразити будь-який можливий Bitcoin Script. [1] [3] [6]

Блок об’єднує транзакції в пакет, який додають до спільної історії. У прикладі Петра 144 блоки відлічуються від підтвердження виходу — конкретної суми з умовами витрачання. Це не рівно доба й не час від створення гаманця. Відносне очікування Miniscript записує як older(n), використовуючи CSV і поле nSequence входу, який витрачає цей вихід. BIP 68 визначає значення цього поля для перевірки віку. Натомість after(n) використовує CLTV та абсолютний nLockTime — фіксовану висоту або часову межу. Гаманець має правильно встановити поля транзакції й виконати решту умов. Обмеження за висотою та часом не можна поєднувати несумісним способом; саме очікування нічого не надсилає. [1] [7] [8] [9] [11]

Показати опис правил недостатньо. Гаманець має надати дані, які виконують один із дозволених шляхів: наприклад, підписи або секрет із потрібним хешем, його preimage. Хеш — цифровий відбиток даних; тут перевіряють, чи дає наданий секрет саме потрібний відбиток. Таке виконання називається satisfaction; необхідні вхідні дані входять до witness транзакції. Поєднання гілок іноді потребує коректно зробити окрему підумову хибною, щоб використати інший шлях. Це dissatisfaction, а не недійсність усього платежу. Програма може підготувати відповідний шлях, але не вигадати відсутній приватний ключ чи невідомий секрет. [1] [12]

PSBT — формат передавання підготовленої транзакції та додаткових даних між гаманцем і пристроями підпису. Самої підтримки PSBT замало: програма й Hardware Wallet мають розуміти descriptor та його умови. Bitcoin Core додав спостереження за Miniscript у P2WSH у версії 24, підписування — у версії 25, а використання в Taproot descriptors — у версії 26. Бачити монети не означає вміти їх витратити. Під час налаштування перевірте на довіреному дисплеї ключі, потрібні підписи, строки очікування та всі альтернативні шляхи, зважаючи на можливості конкретного пристрою. [3] [4] [5]

Seed Phrase відновлює ключі, але для власних складних умов може не пояснювати, як їх поєднали з іншими ключами та скриптом. Це резервна копія у вигляді послідовності слів, з якої гаманець може вивести свої ключі. Збережіть точний descriptor із контрольною сумою, відповідність ключів, шляхи виведення та розмежування адрес отримання і решти. Окремо запишіть мережу, діапазон адрес і початкову точку пошуку в історії. Публічний descriptor не є приватним ключем, але може розкрити історію платежів. Перед використанням перевірте відновлення гаманця для спостереження та кожен передбачений шлях витрачання в тестовому середовищі Regtest або Signet. [5] [6]

pk(), older(), after() і sha256() позначають підпис, очікування або вимогу секрету. and_v(), or_d() і thresh() поєднують умови. Обгортки на кшталт v: змінюють спосіб обчислення, зберігаючи зміст підвиразу. Типи B, V, K і W визначають, як частини передають елементи на стеку — робочому просторі скрипту; не кожна пара сумісна. Перевірка типів може виявити несумісну конструкцію. Проте вона не вирішить за Анну, кому довіряти й чи розумно обрано запасний шлях. [1] [2]

Структура дає змогу наперед проаналізувати розміри скрипту й witness, кількість операцій, перевірок підписів та елементів стека. Це допомагає оцінити вартість різних шляхів і виявити перевищення дозволених меж. Важливе середовище: P2WSH задає умови в SegWit, а Tapscript позначає скрипти, використані в Taproot. Їхні обмеження не в усьому однакові. Поряд із консенсусом діють звичайні правила передавання транзакцій. Отже, результат аналізу не гарантує, що кожен гаманець виконає задуманий порядок дій. [1]

Відкритий ключ використовують для перевірки підписів; його не потрібно тримати в таємниці. Аналіз malleability перевіряє, чи може стороння особа перетворити одну дійсну satisfaction на іншу, також дійсну. Гарантії мають конкретні передумови: зловмисник не володіє приватними ключами учасників, не знає більше preimages, ніж чесний користувач, і бачить лише одну satisfaction. Також передбачаються неповторювані публічні ключі та звичайні правила приймання; майнер може мати можливості, яких немає у звичайного вузла ретрансляції. Це не захист від усіх недобросовісних учасників, втрати резервних копій чи поганої схеми зберігання. Такі питання слід перевіряти окремо. [1]

Компілятор може виразити ті самі правила різними способами з різними розмірами скрипту й witness. Вибір залежить від моделі вартості. Позначка 9@ біля гілки в мові політик підказує відносну ймовірність її використання; це не кількість підписів і не дозвіл мережі. Інша компіляція може створити інший скрипт, а отже, інші адреси. Для відновлення недостатньо знову описати правила своїми словами й скомпілювати їх. Потрібні точний збережений запис, перевірка виведених адрес і випробуваний шлях підписування. [2] [5]