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]