Крипто-анархия: насилие невозможно потому, что нельзя установить настоящие имена участников и место их физического нахождения.
Для эффективного сотрудничества необходимо средство обмена (деньги). Традиционно эти услуги предоставляет правительство (банки) и только для юридических лиц. В этой статье я описываю протокол, с помощью которого эти услуги могут быть предоставлены анонимно неопределенному кругу лиц.
Предполагается существование неотслеживаемой (untraceable) сети, где отправители и получатели определены только цифровым псевдонимом (т.е. открытыми ключами), а сообщения подписываются отправителем и расшифровываются получателем.

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

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

2. Перевод денег. Если Алиса, владелец псевдонима K_A, хочет передать X единиц денег Бобу, владельцу псевдонима K_B, она передает сообщение: «Я даю Х единиц денег на счет K_B» с подписью K_A . Получив это сообщение, участники проверяют остаток на счете K_A. Если операция не создаст отрицательный баланс на счете K_A, участники списывают с него Х единиц и увеличивают на эту сумму счет  K_B. Если на счете  K_A  нет Х единиц, это сообщение игнорируется.

3. Выполнение договоров (контрактов). В исполняемом (valid) контракте должны быть указаны (максимальные) суммы обеспечения для каждого из участников в случае неисполнения условий договора (default). Договор должен предусматривать участие третьей стороны, арбитраж. До начала действия договора все стороны, включая арбитра, должны его подписать. После публикации (broadcast) подписанного договора каждый участник системы списывает со счета каждой из сторон сумму его (максимального) обеспечения и зачисляет эту сумму на специальный счет «Контракт с SHA-1 хэш H», определенный именно для этого контракта (a secure hash of the contract). Договор вступает в силу, если со счета каждого участника можно списать указанную сумму, не получив  в результате отрицательный баланс, в противном случае контракт игнорируется и счета откатываются.
Образец договора может выглядеть следующим образом:
K_A соглашается отправить K_B решение некоторой задачи до 01.01.2000.
K_B обязуется оплатить K_A 100 MU (денежные единицы) до 01.01.2000. K_C
принимает решение провести арбитраж в случае возникновения спора. K_A соглашается оплатить максимум 1000 MU в случае дефолта. K_B обязуется оплатить максимум 200
MU в случае дефолта. K_C обязуется оплатить максимум 500 MU в случае умолчанию.

4. Завершение (conclusion) договоров. Если договор успешно выполнен (завершился без спора), каждая из сторон передает подписанное сообщение «Контракт с SHA-1 хэш H завершился без возмещения ущерба». В ином случае: «Контракт с SHA-1 хэш H завершен со следующими неустойками: ***».  При получении всех сигнатур (подписей), каждый участник системы возвращает обеспечение на счета каждой из сторон, удаляет учетную запись контракта и начисляет на счет (или списывает со счета) каждого участника контракта сумму в соответствии с договором.
 5. Принудительное завершение (enforcement) контрактов. Если стороны договора не приходят к соглашению даже с помощью арбитра, каждая сторона передает свои предложения по штрафным санкциям (распределению обеспечения) и какие-либо аргументы или доказательства. Все участники (Each participant) выносят определение о том, как следует распорядиться обеспечением, и соответственно изменяют счета.

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

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

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

Приложение. Вариант способа создания электронных денег (b-money)

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

Я предлагаю альтернативный подпротокол создания денег, в котором количество денег, создаваемых за период, и цена их создания определяются не согласованием между участниками (всеми – в первом протоколе, или только серверами – во втором), а на аукционе. Каждый период создания денег делится на четыре фазы, а именно:

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

2. Торги. Любой, кто хочет создать b-money, передает предложение в виде <Х,У> где Х – количество денег, которое он хочет создать, и У – нерешенная задача из предопределенного класса задач. Для каждой такой задачи предварительно должна быть определена номинальная стоимость в единицах производительности компьютера.

3. Вычисление. После публикации предложения  <Х,У>, разместивший ее участник может приступить к решению задачи и, получив решение, разослать его.

4. Создание денег. Каждый участник принимает (accepts) максимальные (highest) предложения из тех, что были, по номинальной стоимости созданной единицы  b-money и зачисляет их на счет автора решения.

**
Если вы сочли возможным поощрить скромные усилия переводчика:
1CvxwqpCJA3uc9G3w8pSSS125CYXzNwMrZ