Випущено Bitcoin Core 24.0: ось що нового

Нова версія оригінального програмного забезпечення Bitcoin, запущена Сатоши Накамото у 2009 році було випущено.

Над Bitcoin Core 24.0 працювали 112 розробників протягом приблизно семи місяців, щоб внести відчутні покращення в гаманець Bitcoin Core, одноранговий зв’язок (P2P), графічний інтерфейс користувача (GUI) та багато іншого.

У цій статті розглядаються деякі з основних змін.

Оновлення гаманця

Початкова підтримка Miniscript

Bitcoin Core 24.0 представляє підтримку Miniscript шляхом розширення wsh() вихідний дескриптор. Хоча це початкова і рудиментарна інтеграція, цей крок прокладає шлях для більш складних сценаріїв, які можна розгортати в біткойнах простішим — і безпечнішим — способом.

Мінісценарій можна розглядати як основу (або шаблон) для Біткойн сценарій, рідна мова програмування Bitcoin. Bitcoin Script відповідає за включення всіх функцій програмування, доступних для Bitcoin, включаючи, наприклад, те, що є, мабуть, найпростішим із них: визначення, кому дозволено витрачати певну монету. Для кожної транзакції біткойнів відправник запитує адресу одержувача та на основі цієї інформації створює сценарій, який блокує надсилання біткойнів таким чином, що лише одержувач зможе їх витратити. Хоча створити прості сценарії, такі як наведені вище, за допомогою Bitcoin Script досить легко, чим складнішим стає сценарій, тим більша ймовірність людської помилки. Тут грає роль Miniscript.

Miniscript дозволяє писати підмножину біткойн-скриптів у a структурований спосіб. Це дає змогу аналізувати, компонувати та загальне підписування, серед іншого, дозволяючи розробникам безпечніше писати розширені сценарії. Іншими словами, Miniscript «містить» певну функціональність попередньо встановлених сценаріїв Bitcoin для очікуваної моделі поведінки, обмежуючи можливі ризики, оскільки несподівана поведінка зведена до мінімуму. На практиці це надає «набір інструментів» для розробників, з якими вони можуть працювати та створювати просунуті та складні сценарії для Bitcoin замість того, щоб робити все це вручну через Bitcoin Script.

Починаючи з Bitcoin Core 24.0, користувачі тепер можуть створювати гаманець, що містить сценарій Miniscript, створювати адреси для цього гаманця та фінансувати їх за допомогою біткойнів. Проте витрати з цих адрес ще не підтримуються гаманцем Bitcoin Core, що означає, що гаманці з підтримкою Miniscript на Bitcoin Core поки що доступні лише для перегляду.

Незмінні транзакції

Введено новий RPC, sendall, що дозволяє користувачам витрачати конкретні невитрачені вихідні дані транзакцій (UTXO) повністю. RPC надішле суму, що зберігається в указаних UTXO, одному або декільком одержувачам без створення змін. (За замовчуванням, sendall витратить кожен UTXO в гаманці.)

Така поведінка може бути бажаною в кількох ситуаціях. По-перше, природно, користувач може захотіти спорожнити свій гаманець. Виклик нового RPC із налаштуваннями за замовчуванням зробить це простим способом. По-друге, користувач може захотіти покращити свою конфіденційність, відмовившись від змін.

Змінити адреси є складними, оскільки користувачі часто втрачають уявлення про те, звідки вони походять, і тому можуть змішувати їх з іншими UTXO як вхідні дані в майбутній транзакції. Це може викликати занепокоєння щодо конфіденційності через евристика спільного введення-власності, широко використовувана передумова в ланцюжковому аналізі, яка передбачає, що всі вхідні дані в транзакції належать одному користувачеві. У прикладі результату зміни користувач створив би це посилання, фактично ризикуючи деанонімізацією кількох своїх монет, оскільки аналітик ланцюга міг би кластеризувати деякі адреси цього користувача як гаманець.

Беззмінний платіж бореться з цією проблемою, створюючи транзакцію, яка витрачає весь вибраний UTXO. Оскільки змін немає, користувач не може зробити згадану вище помилку. Більше того, незмінний платіж викликає розумні сумніви у аналітика ланцюга, який цікавиться, чи належить новим результатом тій самій організації, яка надіслала платіж (просте переміщення коштів на нову адресу), чи насправді тепер належить іншому користувачеві.

Змініть рандомізацію виводу, щоб уникнути відбитків пальців

Як було пояснено вище, зміни виходів можуть бути витоком конфіденційності. У той час як sendall повністю пом’якшує використання зміни адреси, насправді буде кілька випадків, коли користувач матиме UTXO точного розміру платежу, який потрібно здійснити. Переконавшись, що спостерігач не може помітити, який із виходів є адресою зміни, користувач отримує трохи конфіденційності, оскільки не буде тривіально зв’язати новостворену адресу (вихід зміни) із уже витраченим введенням у цю транзакцію .

Зазвичай, коли немає UTXO з точною сумою платежу, більшість гаманців і користувачів інтуїтивно обирають той, який найближче до цього числа. Як наслідок, спостерігач, який спостерігає за блокчейном, може побачити, який результат є платежем (більший), а який — зміною (менший). Це призводить до багатьох вищезгаданих ризиків.

Щоб зменшити ймовірність того, що спостерігач зможе виділити вихідні дані змін і адреси користувачів кластера, Bitcoin Core тепер рандомізує вихідні значення змін.

Починаючи з версії 24.0, гаманець Bitcoin Core вибиратиме випадкове число між розміром платежу та потрійним розміром платежу. Цей номер буде інформувати про вибір UTXO для витрат. Фактично це означає, що іноді алгоритм вибирає UTXO, значення якого ближче до платежу, а в інших випадках він вибирає UTXO, значення якого ближче до верхньої межі потрійної суми платежу. Перший сценарій призведе до типового сценарію зміни результату, нижчого за оплату, тоді як другий призведе до зворотного — результат зміни, який перевищує платіж. З огляду на те, що спостерігач блокчейну не може визначити, коли кожен сценарій відбувається в певний час, користувач повинен мати можливість насолоджуватися більшою гарантією конфіденційності.

Оновлення для заміни платно

RBF надає користувачеві біткойн додаткові можливості, коли він надсилає транзакцію в мережу. Часто користувач не хоче переплачувати за комісію майнера, тому може вибрати «золоту середину» між сплаченою комісією та швидкістю, з якою транзакція потрапляє в блок. Але якщо розмір комісії, вибраний користувачем, занизький або mempool перевантажений, може знадобитися занадто багато часу для включення транзакції в блок (або вона може взагалі застрягти в mempool). RBF дозволяє користувачеві «збільшити» комісію за свою транзакцію в такому випадку, що найчастіше забезпечує швидший розрахунок.

Під капотом RBF фактично не збільшує плату. Що відбувається у фоновому режимі, так це те, що програмний клієнт транслюватиме a new транзакція з однаковими входами та більшістю однакових виходів. (Деякі вихідні значення змінюються; вартість комісії природно змінюється відповідно до нового числа, і зазвичай ця різниця вираховується із суми, яка надсилається на змінену адресу.)

Історично вузли ретранслювали лише першу версію транзакції, яку вони побачили. З появою RBF було запроваджено механізм, який дозволяє користувачам позначати, що вони надсилають транзакцію, яка згодом може бути збільшена, тобто замінена версією з вищою комісією. Це послужило попередженням для вузлів, даючи їм знати, що версії цієї транзакції з вищою комісією можуть бути надіслані пізніше та що їх також слід ретранслювати. Імовірно, варіант транзакції з вищою комісією буде більш привабливим для майнерів і тому буде обраний першим. Щойно це станеться і його буде включено до блоку, транзакція з нижчою комісією буде видалена з mempool вузлів, оскільки це буде спроба подвійного витрачання.

Bitcoin Core 24.0 представляє два оновлення функціональності RBF.

По-перше, тепер він дозволяє користувачам налаштовувати свої вузли так, щоб передавати замінні транзакції без застосування прапора RBF. Це можна зробити за допомогою нового mempoolfullrbf варіант. Буде встановлено значення від за замовчуванням, але ті, хто бажає ввімкнути його, можуть увімкнути його.

По-друге, RBF тепер встановлено як стандарт у гаманці Bitcoin Core. Трансакції тепер підключаються до RBF за замовчуванням і -walletrbf Параметр запуску за умовчанням має значення true. Користувачі можуть відмовитися від RBF, налаштувавши певну транзакцію в процесі створення або налаштувавши -walletrbf параметр запуску на false.

Дескриптор Wallet Міграція

Bitcoin Core 23.0 зробив дескрипторні гаманці стандартом. Дескриптори полегшують життя користувача у створенні резервної копії свого гаманця та подальшому відновленні цієї резервної копії в стандартному форматі.

До появи дескрипторів користувачі повинні були знати шлях отримання свого гаманця, який визначає, як головний ключ гаманця отримує адреси для отримання та надсилання біткойнів. Оскільки гаманці можуть мати різні шляхи отримання, недостатньо, щоб резервна копія містила лише вихідні фрази. Іноді користувачеві може пощастити і він спробує відновити резервну копію за допомогою гаманця, який використовує той самий шлях деривації, але, враховуючи низьку ймовірність цього, створюються цілі веб-сайти, які допомагають користувачам визначити, який шлях деривації використовувати для старих і нових гаманців. з'явився.

Дескриптор вирішує цю проблему, будучи описовий про те, який шлях виведення використовує резервний гаманець, що значно покращує взаємодію з користувачем. Ідея полягає в тому, що резервна копія гаманця дескриптора містить всю необхідну інформацію для її правильного відновлення будь-яким програмним клієнтом (за умови, що клієнт увімкнено дескриптор).

Тепер Bitcoin Core 24.0 представляє новий інструмент для перенесення застарілих гаманців на дескрипторний формат гаманця, що дозволяє користувачам скористатися перевагами цього нового стандарту для кращого захисту своїх дорогоцінних біткойнів. Хоча все ще експериментальний, новий RPC (migratewallet) було введено. Цей документ надає більш детальну інформацію про його функціональність.

Зміни графічного інтерфейсу

Графічний інтерфейс Bitcoin Core відомий тим, що не надає такого рівня функціональності, якого можуть досягти віддалені виклики процедур (RPC) і інструменти командного рядка. Bitcoin 24.0 робить деякі кроки, щоб трохи змінити це.

Найновіша версія Bitcoin Core містить новий пункт меню в графічному інтерфейсі користувача, який дозволяє користувачам відновлювати гаманець із резервної копії, що спрощує відновлення резервних копій для нетехнічних людей. Раніше цей параметр існував лише в командному рядку.

Ще один недолік графічного інтерфейсу порівняно з інтерфейсом RPC був пов’язаний з налаштуваннями клієнта Bitcoin Core. Знаменитий bitcoin.conf є святим Граалем конфігурації Bitcoin Core, але знову ж таки його можна було налаштувати в основному через командний рядок. Існував варіант налаштування налаштувань у графічному інтерфейсі користувача, але попередження чітко це показало bitcoin.conf мав пріоритет над графічним інтерфейсом користувача у випадку, якщо і файл, і графічний інтерфейс намагалися встановити дані для однієї конфігурації. Таким чином, хоча графічний інтерфейс забезпечував просту можливість змінити налаштування, файл конфігурації все ще був найнадійнішим способом налаштування клієнта Bitcoin Core.

Bitcoin Core 24.0 змінює це. Нове оновлення об’єднує сторінку налаштувань графічного інтерфейсу користувача з bitcoin.conf файл. Тепер, коли користувач відкриває параметри клієнта в графічному інтерфейсі користувача, показані параметри витягуються з файлу конфігурації. Подібним чином зміни конфігурації, внесені в GUI, тепер відображаються в bitcoin.conf. (Варто зазначити, що зв’язок є непрямим, оскільки зміни в графічному інтерфейсі фактично встановлені на settings.json, файл, який має пріоритет над bitcoin.conf.)

Зміни в P2P-зв'язку

Нова логіка для завантаження заголовків

Bitcoin Core 24.0 оновлює спосіб, у який однорангові мережі в мережі наздоганяють кінець ланцюга, оскільки вони завантажуються вперше або тривалий час не підключаються до мережі Bitcoin.

До цього випуску новий пір, який приєднується до біткойна, починав шукати пір, з якого можна завантажити заголовки блоків. Одноранговий вузол спочатку не завантажує цілі блоки, тому що перед завантаженням блоків для цього ланцюжка він має стимул перевірити, чи дотримується він правильного ланцюжка. Інакше існує ризик завантаження блоків для неправильного ланцюжка, тим самим витрачаючи ресурси.

Хоча завантаження заголовків допомагає заощадити час і ресурси, все одно може статися атака з вичерпанням ресурсів, коли зловмисник надсилає партнеру спам мільйонами підроблених заголовків блоків. Оскільки клієнту необхідно завантажити та зберегти заголовки на диску, досить великий обсяг даних може вивести з ладу апаратне забезпечення однорангового пристрою.

Щоб пом'якшити цю загрозу, Bitcoin Core представив концепцію контрольно-пропускні пункти багато років тому. Контрольні точки визначають, які блоки повинен бути присутнім у ланцюжку, щоб він був дійсним. Однак це рішення також представляє проблему, оскільки контрольними точками можна зловживати для ефективного відкоту найдовшого ланцюжка. Така можливість небажана для біткойнів, тому довелося знайти інше рішення. Введіть це нове оновлення.

З Bitcoin Core 24.0 однорангові пристрої тепер завантажують заголовки блоків двічі. Під час першого запуску заголовки завантажуються та відкидаються (не зберігаються на диску), доки не буде знайдено достатній обсяг роботи — це означає, що ланцюжок, за яким слідував одноранговий вузол, дійсний. У цьому випадку одноранговий вузол перезапускає процес, але тепер, крім завантаження, одноранговий вузол також зберігає заголовки блоків на диску. Зберігаючи заголовки на диск лише після того, як одноранговий вузол переконається, що він є частиною ланцюга з значним доказом роботи, одноранговий вузол уникає використання великого обсягу пам’яті під час можливої ​​атаки, такої як вичерпання ресурсу. Це також усуває потребу в контрольних точках і, мабуть, є більш елегантним рішенням, оскільки визначення дійсності ланцюжка не залежить від людського введення.

Дякуємо Аарону ван Вірдуму за відгук.

Додаткову інформацію та інші зміни див. у Bitcoin Core 24.0 Примітки до випуску. Щоб завантажити Bitcoin Core 24.0, перейдіть тут. Подробиці про Bitcoin Core 24.0 також пояснюються аудіо в подкасті Bitcoin, Explained епізод 65.