Bitcoin Development Philosophy

Пропозиція може послабити систему, навіть не маючи програмної помилки. Наприклад, вона спрощує користування, передаючи частину перевірки сторонньому сервісу. Книга допомагає назвати, що ми отримуємо в такому обміні й кому починаємо довіряти. Автори поєднують пояснення з історичними дискусіями та думками досвідчених розробників. Читач учиться оцінювати аргументи, а не обирати сторону через відоме ім’я. [2]

Потрібно розуміти Proof of Work, тобто роботу, яку підтверджують під час майнінгу, утворення блоків і шлях транзакції від поширення до включення в ланцюг. Далі йдуть 9 основних розділів: децентралізація, Trustlessness, приватність, обмежена пропозиція, оновлення, Adversarial thinking, відкрита розробка, масштабування та реагування на інциденти. Це не перший посібник із купівлі bitcoin. Книга спирається на основи й пояснює, чому окремі правила та практики важливі. [2] [1]

Trustlessness не означає більше ніколи нікому не довіряти. Як пояснює цитований Pieter Wuille, йдеться про можливість роботи протоколу без довіреного посередника. Full Node, тобто вузол із повною перевіркою, сам встановить, чи отриманий блок не створює недозволених монет і не витрачає ту саму суму двічі. Без власної перевірки ви доручаєте цю роботу іншим. Проте вузол усе одно працює на конкретному програмному забезпеченні й обладнанні, які можуть мати вади. [3]

Уявіть платіж у блоці, який згодом замінює інша допустима гілка ланцюга. Така зміна історії називається реорганізацією й може змінити стан платежу. Посилаючись на David Harding, розділ відокремлює перевірку правил від захисту проти цього ризику. Більше підтверджень означає, що після відповідного блока додано нові, а це зазвичай ускладнює його заміну. Але це не обіцянка, що власний вузол зупинить будь-яке переписування історії. [3]

Ще до перевірки платежів виникає запитання: чи відповідає завантажена програма опублікованому вихідному коду? Відтворювана збірка дає різним людям змогу отримати однаковий файл із тих самих матеріалів. Порівняння допомагає перевіряти програму, яку поширюють. Але розділ також нагадує пояснення Carl Dong: важливе походження інструментів, якими її зібрали. Однакові файли не доводять безпомилковості коду, компілятора чи комп’ютера. [3]

Adversarial thinking означає розглядати пропозицію з погляду противника. Питання не лише в тому, чи працює вона за чесної поведінки, а й у тому, що зловмисник може отримати через її використання проти інших. Розділ звертається до Andrew Poelstra та Jameson Lopp, пояснюючи припущення безпеки. Серед прикладів — ізоляція вузла від чесної мережі та навмисне перешкоджання відкритій співпраці. Дотеперішня робота системи сама по собі не є формальним доказом безпеки цілого. [4]

Цитована аксіома стійкості Eric Voskuil виходить із припущення, що система може протистояти державному контролю. Аксіома тут — відправна точка міркування, а не результат перевірки, яка довела невразливість Bitcoin. Різниця важлива й для звичайного читача: сенс шукати стійке рішення не означає, що кожне наше рішення витримає все. Книга підказує, як виявляти такі припущення й зменшувати сліпі плями. [4]

Для кожного твердження запитуйте, що перевіряється, що лишається припущенням і яку зручність користувач отримує від зміни. Автори посилаються на статті й виступи; копії статей із зазначенням походження зберігають окремо в репозиторії. Цей огляд ґрунтується на повному вступі та повних текстах Trustlessness і Adversarial thinking. Решту розділів описано за змістом. Це не рецензія на всю книгу та всі її посилання й не проведений аудит безпеки. [2] [3] [4]