Watch-only Wallet дає змогу переглядати платежі й баланс, не зберігаючи приватних ключів для витрачання. Він також може підготувати платіж, який має підписати інший пристрій або програма. Це зручно, коли потрібен огляд на телефоні чи комп’ютері, а ключі ви тримаєте окремо. Сам напис watch-only не пояснює, хто володіє ключами і чи правильні показані дані.
Аліса зберігає ключі в апаратному гаманці й хоче перевірити надходження з телефона. Вона переносить у телефон публічну конфігурацію гаманця, а не слова відновлення. Завдяки їй застосунок розпізнає потрібні адреси та знаходить їхні платежі в мережі. Аліса бачить надходження 20 000 sat, найменших одиниць біткоїна, і його підтвердження, хоча пристрій підпису лежить удома вимкнений. Телефон не отримав права витрачати ці кошти. Так само продавець може надати бухгалтерці огляд платежів, не передаючи їй ключів. Важливо, що саме було імпортовано: введення Seed Phrase, тобто слів для відновлення ключів, скасувало б це розділення. [12]
До застосунку спостереження можна додати й чужу публічну адресу. Сума на екрані не доводить, що користувач може її витратити, тим більше сплатити всі свої борги. Застосунок підсумовує знайдені UTXO — виходи попередніх платежів, які ще не витрачені. Але знаходить лише те, що відповідає імпортованим даним і доступній історії. Пропущені адреси, незавершений пошук або ненадійний сервер можуть показати неповну картину. Нуль на екрані сам собою не означає втрату біткоїнів: спершу перевірте обсяг спостереження та джерело даних. [8] [9]
Коли Аліса хоче заплатити, застосунок обирає доступні UTXO та вказує одержувача, суму й комісію. Невикористана частина входу може повернутися до її гаманця як решта, або change. Ці відомості можна передати у PSBT — форматі частково підписаної біткоїн-транзакції за BIP174. Окремий пристрій отримує потрібні для підпису дані без власної бази UTXO. Аліса має перевірити на його надійному екрані справжнього одержувача, суму, комісію та решту. Зламаний застосунок може запропонувати не той платіж, який вона задумала. Важливий і sighash: він визначає, які частини транзакції охоплює підпис. Лише після перевірки й підписання кінцеву транзакцію, що відповідає схваленому задуму та правилам гаманця, передають у мережу. [2] [10]
Розширений публічний ключ xpub дає змогу вивести інші публічні ключі в певній гілці гаманця; сам він платіж не підпише. Однак той, хто отримає його разом із правилами гаманця, може пов’язати доступні адреси, минулі й майбутні платежі та баланси. Це значно більше інформації, ніж одна адреса для одного надходження. Сторонній сервер може скласти подібну картину з повторних запитів застосунку. Власний Full Node, який сам перевіряє блокчейн, обмежує таке розкриття; зашифроване чи інше приватне з’єднання не приховає запити від кінцевого сервера. Експортуйте лише потрібний обліковий запис, обмежуйте копії та захищайте мітки, що пов’язують адреси з іменами й призначенням платежів. [1] [13] [14]
Наступні розділи — технічна довідка з налаштування й відновлення. Скрипт задає умови витрачання; Output Descriptor записує ці правила та дані для виведення адрес. HD Wallet створює дерево ключів із seed — секретних початкових даних для їх виведення. Виведення non-hardened дозволяє отримувати нові публічні ключі з xpub, тоді як hardened потребує приватного ключа. Multisig додає визначену кількість необхідних підписів. Імпорт адреси стежить лише за її скриптом, а не за майбутніми адресами отримання та решти. Публічний ключ охоплює різні типи скриптів лише тоді, коли програма явно їх виводить. xpub облікового запису дозволяє отримувати нащадків non-hardened, але не визначає P2PKH, SegWit, Taproot, внутрішню гілку чи поріг підписів Multisig. Це доповнює дескриптор. Експортуйте його з правильного облікового запису пристрою підпису, з відповідною мережею й типом скрипту; не вгадуйте шлях деривації, тобто послідовність кроків від початкового ключа. [1] [4] [7]
HD-гаманці зазвичай відділяють гілку отримання /0/* від внутрішньої /1/* для change, тобто решти. Без внутрішньої гілки кошти після витрати можуть здаватися зниклими. Замалий range, тобто діапазон виведених адрес, може приховати надходження. next_index визначає наступну адресу для створення; неузгоджені значення у двох програмах можуть призвести до повторного використання адреси. Узгоджуйте активні дескриптори, діапазони й індекси. Адресу отримання перевіряйте на екрані пристрою підпису: шкідлива програма може підмінити її навіть за правдоподібного балансу. [6] [9]
У Bitcoin Core importdescriptors використовує timestamp для початку повторного сканування. now пропускає стару історію, а 0 запитує пошук від Genesis Block. Важливі також діапазон range і доступність старих блоків. active визначає, чи використовується дескриптор для створення нових адрес; internal позначає внутрішні виходи гаманця, наприклад решту. Вузол зі скороченою історією може не мати потрібних даних. Rescan лише знаходить наявні транзакції. Збережіть дату чи висоту першого використання й порівнюйте відновлення з відомими адресами та транзакціями, а не тільки з нулем на екрані. [9] [10]
BIP380 описує мову множин скриптів виходів. Приклад wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum містить тип скрипту, відбиток головного ключа, шлях походження, публічний ключ облікового запису, гілку, змінний індекс і контрольну суму. Цей приклад не можна безпосередньо імпортувати. Taproot використовує tr() за BIP386; BIP389 дозволяє кілька шляхів в одному виразі. Контрольна сума виявляє помилки копіювання, але не встановлює автора. Дескриптор із xprv містить секретний ключ і не повинен потрапляти до координатора спостереження. [4] [5] [6] [7]
BIP32 описує важливий виняток: батьківський xpub разом із приватним ключем нащадка, отриманого лише кроками non-hardened, дозволяє обчислити батьківський приватний ключ. Самого xpub недостатньо; небезпечна ця комбінація. Крок hardened над експортованим обліковим записом не дає атаці перейти цю межу. Ніколи не додавайте xprv, seed чи приватні ключі до гаманця спостереження, його бази або супровідних файлів PSBT. [1]
Спостереження за Multisig вимагає порогу підписів, типу скрипту, xpub кожного співпідписувача, походження й порядку ключів та обох адресних гілок. Одного xpub замало. Втрата дескриптора ускладнює відновлення навіть зі збереженими seed; інший порядок або обгортка скрипту може створювати інші адреси. Перевірте правила й зразкову адресу на всіх пристроях підпису. Збережіть дескриптор із контрольною сумою або стандартну конфігурацію, пам’ятаючи, що вона розкриває зв’язки співпідписувачів. [4] [11]
Окремо від приватних ключів збережіть дескриптори обох гілок, походження ключів, мережу, дату чи висоту створення, діапазони, індекси, мітки й правила Multisig. BIP329 передає мітки, але не замінює дескриптор чи історію. Перевірте відновлення в окремому профілі або тестовій мережі: імпортуйте публічну конфігурацію, проскануйте історію, порівняйте старі адреси обох гілок і очікувані UTXO, підготуйте PSBT та підпишіть призначеним пристроєм. Перед передаванням перевірте результат. Watch-only допомагає спостерігати й готувати, але не надає права витрачати. [3] [9] [12]
Для повної картини прочитайте також Extended Public Key (xpub), Гаманець, Cold Storage, Output Descriptor, PSBT, Bitcoin. На цю статтю також посилаються HD Wallet, Cold Storage, Extended Public Key (xpub), Output Descriptor.