413 / 736HEARN

Mike Hearn

Розробник bitcoinj і автор мережевих та платіжних пропозицій

Mike Hearn долучився до розробки bitcoinj і запропонував способи спілкування гаманців із вузлами та продавцями. Його робота допомагає зрозуміти, що відбувається за звичайною оплатою біткоїном і чому різні повідомлення про її отримання означають різні речі.

Mike Hearn — розробник Bitcoin і співавтор кількох BIP, документів з описом запропонованих технічних рішень. Він працював над бібліотекою bitcoinj та способами перевірки з’єднань, відбору потрібних транзакцій і обміну повідомленнями під час оплати. Щоб зрозуміти його внесок, простежмо шлях від гаманця в телефоні до магазину, який очікує на платіж.

Розробникові біткоїн-гаманця не потрібно самостійно писати весь код для зв’язку з мережею. Можна взяти бібліотеку — набір готових функцій, на основі яких будують застосунок. Одна з таких бібліотек — bitcoinj. Її файл AUTHORS називає Mike Hearn серед багатьох учасників і посилається на історію змін у Git. Так можна знайти конкретні внески. Це не означає, що Hearn одноосібно написав усі функції або нині керує всім проєктом. [1]

bitcoinj — бібліотека мовою Java для керування гаманцем, надсилання й отримання транзакцій без локально встановленого Bitcoin Core. Для телефона привабливий режим SPV, скорочення від Simplified Payment Verification: він працює із заголовками блоків і потрібними гаманцю транзакціями замість повної перевірки кожної транзакції. Це заощаджує трафік і ресурси пристрою. Документація також описує експериментальну повну перевірку. Це різні режими: менше навантаження не означає ту саму перевірку всіх правил, лише швидшу. [2]

Уявімо ноутбук, що прокинувся після сну. З’єднання з іншим вузлом може виглядати відкритим, хоча вже не працює. BIP 31 від Hearn дозволяє надіслати ping із nonce — тут це число для розпізнавання конкретного запиту. Інший вузол повертає те саме число в повідомленні pong. Для версій протоколу понад 60000 це дає змогу зіставляти запити з відповідями й вимірювати час відгуку. Перевіряється зв’язок: сама відповідь не доводить чесності вузла або дійсності платежу. [3]

Навіщо телефону транзакції, які його не стосуються? BIP 37, написаний Hearn і Matt Corallo, описує фільтр Bloom — компактний засіб відбору можливих збігів. filterload установлює фільтр, filteradd додає елемент, а filterclear видаляє фільтр. Крізь нього може пройти стороння транзакція; це хибнопозитивний результат. Точніший відбір скорочує трафік, але може полегшити іншому вузлу зв’язування транзакцій з IP-адресою гаманця. Отже, економія даних не забезпечує приватності автоматично. [4]

Телефон має з’ясувати, чи справді отримана транзакція належить до певного блока. Повідомлення merkleblock із BIP 37 надає дані для доказу Merkle: кілька відбитків даних, тобто хешів, дозволяють перевірити зв’язок транзакції зі спільним відбитком у заголовку блока. Завантажувати весь блок для цього не потрібно. Однак доказ не виключає, що інший вузол приховав решту транзакцій. SPV також не замінює повної перевірки їхньої дійсності. Документація bitcoinj пояснює небезпеку ситуації, коли нападник контролює всі з’єднання гаманця і вирішує, що йому показати. [4] [5]

Під час купівлі потрібно знати суму й одержувача. Для цього BIP 70 від Gavin Andresen і Hearn запроваджує PaymentRequest. Повідомлення містить деталі платежу: виходи, що визначають, куди транзакція має спрямувати кошти, суму та необов’язковий строк дії запиту. Особу продавця можна засвідчити сертифікатами X.509, подібно до вебсерверів. Але протокол дозволяє і pki_type none — запит без такого засвідчення. Сам формат платіжного запиту тому ще не доводить підтвердженої особи магазину. [6]

Якщо запит указує платіжний сервер, після вашої згоди гаманець надсилає туди повідомлення Payment. Відповідь PaymentACK може означати, що магазин прийняв платіж до обробки. Для покупця це корисно, проте залишається заявою сервера продавця, а не доказом підтвердження транзакції в блоці. Так само refund_to лише вказує, куди магазин може надіслати повернення; саме поле не повертає гроші. Застосунок має розрізняти повідомлення про платіж і фактичний рух коштів. [6]

Старий посібник може створити враження, ніби описаний спосіб працює всюди. У реєстрі BIP 70 має статус Deployed, тобто впроваджений. Водночас примітки до Bitcoin Core 0.20.0 фіксують повне вилучення його підтримки з цієї програми. Суперечності немає: специфікацію, яку використовували раніше, не обов’язково підтримує кожен сучасний клієнт. Робота Hearn допомагає зрозуміти розвиток гаманців; для практичного використання потрібно також перевірити можливості конкретної програми та її версії. [6] [7]

Для повної картини прочитайте також Jeff Garzik, Gloria Zhao, Merkle Tree. На цю статтю також посилаються Jeff Garzik, Gloria Zhao.

DOC · 001bitcoinj — recorded contributorsДокументація DOC · 002bitcoinj — library and verification modesДокументація DOC · 003BIP 31 — Pong messageДокументація DOC · 004BIP 37 — connection Bloom filteringДокументація DOC · 005bitcoinj — security modelДокументація DOC · 006BIP 70 — Payment ProtocolДокументація DOC · 007Bitcoin Core 0.20.0 — BIP70 removalДокументація
Переглянуто: Спочатку джерела · Не інвестиційна порада