Bitcoin: A Peer-на-Peer Электронные Кассовые системы

Сатоси Накамото
satoshin@gmx.com
www.bitcoin.org

Аннотация. Вариант чисто равный-равному электронной наличности позволит онлайн

платежи , которые будут отправлены непосредственно из одной партии в другую , минуя

финансовое учреждение. Цифровые подписи обеспечивают часть решения, но основные

преимущества теряются , если доверенная третья сторона по - прежнему требуются для предотвращения двойных расходов.

Мы предлагаем решение проблемы двойного расходов с использованием сети равноправных узлов ЛВС.

Сеть метки времени транзакции путем хэширования их в постоянной цепи на

основе хэш-доказательство правильности работы, образуя запись , которая не может быть изменена без переделывания

Доказательство-оф-работы. Самая длинная цепь не только служит доказательством последовательности

событий очевидцев, но доказательство того, что он пришел от самого большого пула мощности процессора. Как

долго , как большая часть мощности процессора управляются узлами, которые не сотрудничает , чтобы

атаковать сеть, они будут генерировать длинные цепи и опережать нападавшие.

Сеть сама по себе требует минимальной структуры. Сообщения передаются на максимальных усилий

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

1.
Введение
Торговля в Интернете пришла полагаться исключительно на финансовых учреждениях , выступающих в качестве
доверенные третьи стороны для обработки электронных платежей. В то время как система работает достаточно хорошо для

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

Определенный процент мошенничества принимается как неизбежное. Эти расходы и оплата неопределенность
можно избежать человека с помощью физической валюты, но не существует никакого механизма для осуществления платежей

по каналу связи без доверенной стороны.

Что необходимо , так это электронная платежная система , основанная на криптографических доказательства вместо доверия,

позволяя любые две стороны , готовые непосредственно совершать сделки друг с другом без необходимости доверенной

третьей стороны. Сделки, которые вычислительно непрактичным реверс бы защитить продавцов

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

этой статье мы предлагаем решение проблемы двойных расходов с использованием одноранговых к распределенному
Отметка времени сервера для создания вычислительного доказательства хронологических порядка операций.
Система безопасна до тех пор , как честные узлы совокупности контролируют больше мощности процессора , чем любая
взаимодействующей группа атакующих узлов.

1
2.
Сделки
Мы определяем электронную монету в виде цепочки цифровых подписей. Каждый владелец передает монету
следующий путем цифровой подписи хэш предыдущей транзакции и открытый ключ следующего владельца
и добавление их к концу монеты. Ремитентом может проверять подписи для проверки цепочки
владения.

Transaction Transaction транзакции

Владелец 1 - х Владелец 2 - х Владелец 3 в

Public Key Public Key Public Key

Hash Hash Hash

Проверка Проверка

Владелец 0 По Владелец 1 по Владелец 2 в

Signature Signature Signature

Зарегистрировать
Войти

Владелец 1 по Владелец 2 в Владелец 3 в

Private Key Private Key Private Key

Проблема, конечно , является получателем платежа не может подтвердить , что один из владельцев не дважды тратить

монету. Общее решением является введение доверенной центральной власти, или мяты, который проверяет каждый
сделку для двойных расходов. После каждой операции, монета должна быть возвращена на монетный двор , чтобы
выпустить новую монету, и только монеты , выпущенные непосредственно из мяты доверенные не быть дважды израсходовано.

Проблема с этим решением является то , что судьба всей денежной системы зависит от
компании работает мяту, с каждой транзакции, чтобы пройти через них, так же , как в банке.
Нам нужен способ для получателя платежа , чтобы узнать , что предыдущие владельцы не подписывать какие - либо ранее

сделки. Для наших целей, самая ранняя сделка является тот , который подсчитывает, поэтому мы не заботимся
о последующих попытках двойных расходов. Единственный способ подтвердить отсутствие транзакции, чтобы
быть в курсе всех сделок. В модели мяты основы мята была осведомлена о всех сделках и
решила, прибывшие первый. Для достижения этой цели без доверенной стороны, операции должны быть
публично объявлены [1], и нам нужна система для участников договориться о единой истории
порядок , в котором они были получены. Потребности PAYEE доказательства того, что во время каждой сделки,
большинство узлов согласилось , что это было первым получило.

3. Отметка сервера

Решение , которое мы предлагаем начинается с сервером отметок времени. Сервер работает временная метка, беря

хэш из блока элементов , чтобы быть датируемым и широко публикация хэша, например, в
газете или Usenet посте [2-5]. Отметка доказывает , что данные должны существовать в
момент, очевидно, для того , чтобы попасть в хэш. Каждая временная метка включает в себя предыдущую временную метку в

его хэш, образуя цепочку, с каждым дополнительным армирующим метки времени те , перед ним.

Hash Hash

Блок Блок

Item товара ... Item товара ...

2
4. Доказательство-оф-Work

Для реализации распределенного сервера временных меток на основе равноправных узлов ЛВС, нам нужно будет использовать proof-

из-работы системы похожа на Адама Назад в HashCash [6], а не газеты или сообщений Usenet.
Работа доказательства правильности включает в себя сканирование на значение , которое при хэшированном, например, с помощью SHA-256, то

хэш начинается с числом нулевых бит. Средняя работа требуется экспоненциально зависит от числа
нулевых бит , необходимых и может быть проверена путем выполнения одного хэша.

Для нашей временной метки сети, мы реализуем доказательство правильности работы приращения случайного слова в

блоке , пока значение не будет установлено , что дает хеш блока необходимой нулевой бит. После того , как CPU
усилий было потрачено , чтобы она удовлетворяла доказательство правильности работы, блок не может быть изменен

без переделывания работы. В последующих блоки прикованы после него, работы , чтобы изменить блок
будет включать в себя переделку всех блоков после него.

Блок Блок

Prev Hash Нонс Prev Hash Нонс

Tx Tx ... Tx Tx ...

Доказательство правильности работы также решает задачу определения представительства в принятии большинства

решений. Если большинство были основаны на один-IP-адрес-один голос, это может быть сорвано , кто
сможет выделить много IP - адресов. Proof-оф-работы, по существу , один-CPU-один голос. Большинство
решение представлено самой длинной цепью, которая имеет наибольшее усилие корректуры из-работ инвестированы
в нем. Если большинство мощности процессора контролируется честными узлами, честная цепочка будет расти
быстро и опережать любые конкурирующие цепи. Для того, чтобы изменить прошлое блока, злоумышленник должен
повторить доказательство правильности работы блока и все блоки после него , а затем догнать и перегнать
работу честных узлов. Позже мы покажем , что вероятность более медленной атакующим догоняет
экспоненциально убывает по мере добавления последующих блоков.
Для того, чтобы компенсировать увеличение скорости аппаратной и варьируя интерес в управлении узлами в течение долгого времени,

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

5.
Сеть
Стадии для запуска сетей являются следующим:

1) Новые операции транслируются на все узлы.

2) Каждый узел собирает новые транзакции в блок.
3) Каждый узел работает на поиск трудного доказательства из-за работу этого блока.
4) Когда узел находит доказательство из-работы, он передает блок ко всем узлам.
5) Узлы принимает блок только тогда , когда все транзакции в ней действуют и уже не проводится.
6) Узлы выражают согласие блока, работая над созданием следующего блока в
цепочке, используя хэш принятого блока в качестве предыдущего хэша.

Узлы всегда считают самую длинную цепочку , чтобы быть правильным и будет продолжать работать над
его продления. Если два узла транслировать различные версии следующего блока одновременно, некоторые
узлы могут получить один или другой первый. В этом случае они работают на первых они получили,
но сохранить другую ветвь в случае оно становится больше. Связь будет нарушена , когда следующий proof-

из-работы найдена и одна ветвь становится длиннее; узлы , которые работали на другой
ветке будет затем переключиться на более длинный.

3
 Новые вещает сделки не обязательно должны дойти до всех узлов. До тех пор , как они достигают
много узлов, то они попадают в блок , прежде чем долго. Блок трансляция также терпима отброшенные
сообщений. Если узел не получает блок, он будет просить его , когда он получает следующий блок и
понимает , что пропустил один.

6.
Стимул
По соглашению, первая сделка в блоке специальная операция , которая начинает новую монету , принадлежащий

создателем блока. Это добавляет стимул для узлов для поддержки сети, а также предоставляет
возможность изначально распределять монеты в обращение, так как нет центральной власти выдать их.
Устойчивое добавление постоянной количества новых монет аналогично золотодобывающих затрачивая
ресурсы , чтобы добавить золото в обращении. В нашем случае, это процессорное время и электроэнергия, которая расходуется.

Стимул может также финансироваться за счет сборов сделки. Если выходное значение транзакции
меньше , чем его входное значение, разность является плата за сделку , которая добавляется к значению стимулирующего

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

Стимул может помочь стимулировать узлы остаться честным. Если жадный злоумышленник может
собрать больше мощности процессора , чем все честные узлы, ему придется выбирать между использованием его
чтобы обмануть людей путем кражи назад свои платежи, или использовать его для создания новых монет. Он должен
найти более выгодно играть по правилам, такие правила , которые благоприятствуют его с большим количеством новых монет , чем

все остальные вместе взятые, чем подорвать систему и обоснованность своего собственного богатства.

7. Регенерационного дискового пространства

После того, как последняя транзакция в монете похоронена под достаточно блоков, затраченные сделки до
него можно отказаться , чтобы сэкономить дисковое пространство. Чтобы облегчить это , не нарушая хэш блока, в

операции хэшируются в Merkle дереве [7] [2] [5], только с корнем , включенной в хэш - блока.
Старые блоки могут быть уплотнены гася от ветвей дерева. Внутренние хэши делать
не нужно хранить.

Блок Блок
Блок заголовка (блок Хэш) Блок заголовка (блок Хэш)

Пред Хэш Нонс Пред Хэш Нонс

Корень Хэш Корень Хэш

Hash01 Hash23 Hash01 Hash23

Hash0 hash1 hash2 Hash3 hash2 Hash3

Tx0 TX1 TX2 Tx3 Tx3

Операции Хэшировано в Merkle дереве после обрезки Tx0-2 от блока

Блок заголовок без каких - либо сделок будет составлять около 80 байт. Если мы предположим , блоки
генерируются каждые 10 минут, 80 байт * 6 * 24 * 365 = 4.2MB в год. С компьютерными системами , как
правило , продают с 2 Гб оперативной памяти , как в 2008 году, и закон Мура прогнозирования текущего роста
1.2GB в год, хранение не должно быть проблемой , даже если заголовки блоков должны быть сохранены в
памяти.

4
8. Упрощенная Оплата проверка

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

Longest Proof-оф-Work Chain

Блок заголовок Блока заголовок Блок заголовок

Предыдущего Hash Нонс Предыдущего Hash Нонс Пред Hash Нонса

Merkle Root Merkle Root Merkle Root

Hash01 Hash23

Merkle Отделение для Tx3

hash2 Hash3

TX3

Таким образом , проверка является надежным , так долго , как честные узлы управления сетью, но более

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

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

9. Объединение и разделение Value

Хотя можно было бы обрабатывать монеты по отдельности, было бы громоздким , чтобы сделать
отдельную транзакцию для каждого цента в передаче. Чтобы разрешить значение должны быть разделены и объединены,

транзакции содержат множество входов и выходов. Обычно там будет либо один вход
из большего предыдущей операции или несколько входов , объединяющих меньшие суммы, и не более двух
выходов: один для оплаты, а также один возвращение изменения, если таковые имеются, обратно отправителю.

транзакций

В Out

...
в

...

Следует отметить , что вентилятор-аут, где транзакция зависит от нескольких сделок, и эти
операции зависят многие другие, не проблема. Там никогда не бывает необходимо извлечь
полную автономную копию истории транзакции.

5
10. Конфиденциальность

Традиционная банковская модель достигает уровня конфиденциальности путем ограничения доступа к информации о

вовлеченных сторон и доверенной третьей стороны. Необходимость объявить все сделки публично
исключает этот метод, но конфиденциальность все еще может быть сохранена путем разрыва потока информации в
другом месте: сохраняя открытые ключи анонимными. Общественность может видеть , что кто - то посылает

сумму кому - то другому, но без информации , связывающей сделку с кем - либо. Это
похоже на уровне информации , опубликованной фондовых биржах, где время и размер
отдельных сделок, то «лента», будет обнародована, но , не говоря , кто стороны были.

Традиционная модель конфиденциальности

Trusted
идентификаторов контрагент Public
Сделка Third Party

Новая политика конфиденциальности Модель

идентификаторы Transactions Public

В качестве дополнительного брандмауэра, новая пара ключей должна использоваться для каждой транзакции , чтобы держать их

от быть связанно с общим владельцем. Некоторое сшивание еще неизбежное с несколькими входами
операциями, которые обязательно показывают , что их входы принадлежали одному владельцу. Риск в
том , что если обнаруживается владелец ключа, сшивание может выявить другие сделки , которые принадлежали
тому же владельцу.

11. Расчеты
Мы рассматриваем сценарий злоумышленника пытается сформировать альтернативную цепь быстрее , чем честному
цепь. Даже если это будет сделано, он не бросает систему , открытую для любых изменений, таких
как создание ценности из воздуха или брать деньги , которые никогда не принадлежал к атакующему. Узлы
не собирается принимать недопустимую операцию в качестве оплаты, а честные узлы никогда не смирится блок ,
содержащий их. Злоумышленник может только попытаться изменить одну из своих собственных сделок , чтобы забрать
деньги , которые он недавно потратил.

Гонка между честной цепочкой и атакующей цепи можно охарактеризовать как биномиального
Random Walk. Событие успеха честная цепь расширяется на один блок, увеличивая его
ведущую роль на +1, и событие неудачи цепи атакующей быть продлена на один блок, уменьшая
зазор на -1.

Вероятность того , что злоумышленник догоняет из данного дефицита аналогичен картежник в

задаче о разорении. Предположим , что игрок с неограниченным кредитом начинается дефицит и играет потенциально
бесконечное число попыток , чтобы попытаться достичь безубыточности. Мы можем вычислить вероятность того, что он никогда не

достигнет безубыточности, или что злоумышленник когда - либо догоняет честной цепи, следующим образом [8]:

р = вероятность честный узел находит следующий блок

Q = вероятность злоумышленник находит следующий блок
д = вероятность того , злоумышленник будет когда - нибудь догонит из г блоков за
г

1, если
p≤q
д = {
г г , }
q / если
p pq

6
Учитывая наше предположение о том, что р> д, вероятность экспоненциально падает как число блоков
злоумышленник должен догнать увеличивается. С шансами против него, если он не делает удачный
выпад вперед на ранней стадии, его шансы стать исчезающе малы , как он падает дальше позади.
Рассмотрим теперь , как долго получатель новой потребности сделки ждать , прежде чем
достаточно уверен отправитель не может изменить транзакцию. Мы предполагаем , что отправитель злоумышленник ,
который хочет , чтобы получатель поверить , что он заплатил ему за некоторое время, а затем включите его , чтобы окупить к

себе после того, как прошло некоторое время. Приемник будет извещение , когда это произойдет, но
отправитель надеется , что это будет слишком поздно.

Приемник генерирует новую пару ключей и дает ключ общественности к отправителю незадолго до
подписания. Это предотвращает отправитель от подготовки цепочки блоков загодя, работая над
ней непрерывно , пока он не повезло достаточно , чтобы получить достаточно далеко вперед, то выполнение сделки на

данный момент. После того , как сделка будет отправлена, нечестный отправитель начинает работать в тайне от
параллельной цепи , содержащей альтернативный вариант его сделки.
В ожидает получателей , пока транзакция была добавлена к блоку и Z блоки были
связаны после него. Он не знает точное количество прогресса злоумышленник сделал, но
предполагая , что честные блоки взял среднее ожидаемое время на блок, потенциал атакующего
прогресс будет распределение Пуассона с ожидаемым значением:

д
=г
р

Чтобы получить вероятность того , злоумышленник может еще догнать теперь, мы умножить плотность Пуассона для

каждой суммы прогресса он мог бы сделать вероятностью он мог догнать от точка:

к
∞
 й - q / p z-k если
k≤z
Σ ⋅ { }
1, если
к! kz
к=0

Перегруппировка , чтобы избежать суммирования бесконечного хвоста распределения ...

г к
 е -
1 Σ 1-q / p
z-k


к!
к=0

Преобразование кода C ...

#include <math.h>
двойной AttackerSuccessProbability (двойной д, Int г)
{

двойной р = 1,0 - д;
двойная лямбда = Z * (Q / P);
двойная сумма = 1,0;
INT I, K;
для (к = 0, К <= г; к ++)
{
двойной пуассоновский = ехр (-lambda);
для (I = 1; я <= к; я ++)
пуассоновский * = лямбда / я;
сумма - = пуассоновский * (1 - пау (д / р, г - к));

}
Вернуть сумму;
}

7
Запуск некоторых результатов, мы можем видеть вероятность упасть экспоненциально с г.

д = 0,1

г = 0 Р = 1,0000000
г = 1 Р = 0,2045873
г = 2 Р = 0,0509779
г = 3 Р = 0,0131722
г = 4 С = 0,0034552
г = 5 Р = 0,0009137
г = 6 Р = 0,0002428
г = 7 Р = 0.0000647
г = 8 Р = 0,0000173
г = 9 Р = 0,0000046
г = 10 Р = 0,0000012

д = 0,3

г = 0 Р = 1,0000000
г = 5 Р = 0,1773523
г = 10 Р = 0,0416605
г = 15 Р = 0,0101008
г = 20 Р = 0.0024804
г = 25 Р = 0,0006132
г = 30 Р = 0,0001522
г = 35 Р = 0,0000379
г = 40 Р = 0,0000095
г = 45 Р = 0,0000024
г = 50 Р = 0,0000006

Решение для P менее 0,1% ...

Р <0,001
д = 0,10 г = 5
д = 0,15 г = 8
д = 0,20 г = 11
кв = 0.25 г = 15
кв = 0.30 г = 24
кв = 0.35 г = 41
кв = 0.40 г = 89
кв = 0,45 г = 340

12. Заключение

Мы предложили систему электронных транзакций , не полагаясь на доверии. Мы начали с

обычными рамками монет , сделанных из цифровых подписей, что обеспечивает сильный контроль над
собственностью, но является неполным без того , чтобы предотвратить двойные расходы. Чтобы решить эту проблему, мы
предложили использовать сеть одноранговой сети , используя доказательство правильности работы , чтобы записать публичную историю сделок ,

которые быстро становятся вычислительно непрактичным злоумышленник изменить , если честные узлы
контролировать большую часть мощности процессора. Сеть надежна в неструктурированной простоте. Узлы
работать сразу с небольшим количеством координации. Они не должны быть идентифицированы, поскольку сообщения
не направляются на какое - либо конкретное место , и только должны быть поставлены на основе максимальных усилий. Узлы могут

уйти и присоединиться к сети по желанию, принимая цепь корректуры из-работы в качестве доказательства того , что

произошло , когда они исчезли. Они голосуют их мощность процессора, выражая свое согласие с
действующими блоками, работая над расширением их и отклонять недействительные блоки, отказываясь работать на
них. Любые необходимые правила и стимулы могут быть осуществлены с этим механизмом консенсуса.

8
Список литературы

[1] В. Dai, "б-деньги" http://www.weidai.com/bmoney.txt, 1998.

[2] H. Massias, XS Avila, и Ж.-Ж. Quisquater, «Проектирование безопасной службы меток времени с минимальными
требованиями доверия,» В двадцатом симпозиум по теории информации в странах Бенилюкса, май 1999 г.

[3] S. Haber, WS Stornetta, «Как раз-печать цифрового документа,» В Журнал криптологии, том 3, №
2, страницы 99-111, 1991.

[4] Д. Байер, С. Хабер, WS Stornetta, «Повышение эффективности и надежности цифровых времени штамповки,»
в последовательностях II: методы в Связь, безопасность и компьютерные науки, страницы 329-334, 1993.

[5] С. Хабер, WS Stornetta, «Безопасные имена для битовых строк,» Труды 4 - й ACM конференции
по компьютерной и коммуникационной безопасности, страницы 28-35, апрель 1997 г.

[6] А. Назад, «Hashcash - отрицание служба контрмера,»

http://www.hashcash.org/papers/hashcash.pdf, 2002.

[7] RC Merkle, "Протоколы для криптосистем с открытым ключом," В Proc. 1980 Симпозиум по безопасности и
конфиденциальности, IEEE Computer Society, стр 122-133, апрель 1980.

[8] В. Феллер, «Введение в теорию вероятностей и ее приложения,» 1957.