Bitcoin и ранее созданные системы анонимных электронных денег

В данной публикации я сделаю сравнение Bitcoin, о котором многие уже слышали, с ранее созданными системами электронных денег, основу которых положил David Chaum ещё в начале 1980-х. Bitcoin в большинстве информационных источников представляется как нечто революционные, из ряда вон выдающееся. Продемонстрирую, что это просто навсего всего-лишь ещё одна система платежей, не сильно лучше PayPal, WebMoney и подобных, а во многом даже отстающая от них.

За основу я возьму статью «Universal Electronic Cash», в которой криптографы дают чёткие требования к идеальной системе электронных платежей (в этой работе не ставятся условия создания децентрализованной системы):

• Независимость от каких-либо физических условий. Деньги должны представлять только информационные потоки, чтобы можно было пользоваться ими по компьютерным сетям;
• Безопасность. Возможность повторного использования, копирования денег должна быть исключена;
• Приватность, непрослеживаемость, анонимность. Возможность отслеживания взаимосвязи между пользователем и его покупками должна быть исключена;
• Offline платежи. При недоступности сети магазин всё-равно должен смочь принять деньги от пользователя;
• Возможность передачи денег другим пользователям, минуя связь с банком или какой-то подобной централизованной службой;
• Возможность дробления, размена купюр заданного достоинства на более мелкие части, без участия банка напрямую.

Например, бумажные деньги, монеты, «наличка» безопасны: использование купюры ведёт к тому, что вы её лишаетесь, теряете нечто материальное. Трудозатраты на создание купюр (их подделку) чересчур велики из-за сложности технологий. Для создания золотых монет нужно золото. Наличные же деньги дают приватность пользователю. И анонимность. Отдавая купюру магазину или получая сдачу, ни я, ни магазин не знают, в чьих руках эти купюры побывали раньше. Связать мои покупки по купюрам они уже не могут. Их можно передавать другим людям (без участия банков), делать оплату в offline режиме.

Не будем вдаваться в подробности реализации Bitcoin: на эту тему есть колоссальное количество материалов. У каждого пользователя имеется кошелёк, являющийся парой асимметричных ключей. Каждая транзакция — это набор подписанных асимметричными ключами данных, в которых говорится, какая сумма и куда передаётся. Передающиеся транзакции от пользователя к пользователю (коими могут быть и магазины) образуют связанную по времени цепочку. Эта цепочка является единой для всех базой данных, по которой все могут проверить, не были ли использованы деньги повторно. Добавлять транзакции/данные к этой (или множеству других) цепочек можно только сделав ресурсоёмкие вычисления (proof of work).

Вся суть Bitcoin основана на предположении, что всегда используется самая длинная цепочка данных, так как на неё затрачено больше всего ресурсов, а больше всего ресурсов затрачивают доброжелатели, честные пользователи. Открыв whitepaper по Bitcoin видим, что чётко говорится: система работает до тех пор, пока у злоумышленника не будет 51% (чуть больше половины) вычислительных ресурсов. В этом случае он сможет создавать альтернативные цепочки транзакций и делать так, что, например, сегодня магазин видит и доверяет моему платежу, а завтра в самой длинной цепочке его уже не будет, хотя товар мне запросто мог быть уже отгружен. Кроме того, тот, кто в праве создавать действительную доверяемую цепочку, может вводить и цензуру: не позволяя появляться в ней определённым кошелькам. Он может и не включать транзакции, за которые не была внесена минимальная пошлина. Всё это не запрещено протоколом.

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

Задумка Bitcoin могла бы работать, если бы вычислительные ресурсы были действительно сильно рассредоточены между пользователями. Однако мы знаем, что на простых CPU бесполезно пытаться делать mining, даже GPU уже всё меньше и меньше вариант. Строят огромные mining датацентры. То есть чем дальше, тем больше и больше вычислительной мощности перекочёвывает в малочисленные центры. Сеть ghash.io уже преодолела порог в 51%.

Имеются другие реализации электронных платежей, где хэш-функция SHA256 из Bitcoin заменяется на алгоритмы — ещё и требовательные по памяти, чтобы уменьшить разрыв между дешёвыми ASIC mining чипами и дорогими, но малоэффективными CPU. Всё это крутится всё-равно вокруг идеи proof of work и потому это лишь отсрочка неизбежной централизации вычислительных ресурсов. Proof of work известен давно, со времён появления спама в электронной почте. И за десятилетия люди должны были уяснить, что это не средство предотвращения появления спама (альтернативных цепочек транзакций в контексте Bitcoin), а лишь инструмент его уменьшения. Исключить спам полностью невозможно: тогда порог входа, количество необходимых ресурсов растёт настолько, что простым смертным невозможно будет пользоваться системой и опять же всё придёт к малочисленным огромным мощным провайдерам услуг. В контексте денег их можно назвать самыми обычными банками, теми, кто обладает развитой дорогой инфраструктурой. Деньги делают самые богатые.

Когда речь идёт о безопасности денег, когда речь о транзакции на миллионы или миллиарды условных единиц, тогда не до надежды о том, что никто не подменит самую длинную цепочку блоков транзакций Bitcoin. На такой риск никто не пойдёт. Поэтому proof of work в целом не применим для работы с деньгами, разве что только когда речь о мелочах (микроплатежах), где риск не так страшен.

Таким образом, уже на данный момент Bitcoin — это централизованная система.

Если деньги или обычный банковские транзакции обладают безопасностью, то в Bitcoin об этом речи не идёт: цепочку можно изменить. Люди, продавшие что-то за большую сумму, будут крайне разочарованы завтра, не увидев в своём кошельке оплаченную сумму (так как транзакция на их публичный ключ в другой цепочке, не доверяемой).

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

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

Offline платежи в Bitcoin не сделать. Более того: их даже не сделать быстро, так как для подтверждения транзакции необходимо, чтобы она оказалась в нескольких блоках самой длинной цепочки (хотя факт появления транзакции виден быстро). В случае оплаты каких-нибудь мелочей (ну там бутерброда) можно пойти на риск и даже если транзакция не окажется действительной — не велика потеря. То есть опять на практике только микроплатежи.

В данной таблице подразумевается, что банковские карты чипованы и с ними можно делать offline платежи. Под PayPal подразумевается просто веб-интерфейс, с которым можно как-то управлять денежными потоками, это может быть и веб-интерфейс вашего банка. Под schneiercash подразумевается пример создания анонимной электронной валюты, описанной в книге Брюса Шнайера «Прикладная криптография». Об этой валюте будет написано ниже.

Готовые разработки по анонимным (действительно, а не в узком, практически не применимом в жизни, контексте Bitcoin) и безопасным электронным деньгам, как, например, schneiercash, уже были созданы в 80-х годах. Много криптографов занимались проблемами криптовалют, но ни один не смог придумать децентрализованного решения. Анонимные, безопасные, offline и прочие вещи придумали (между прочим, там довольно сложная математика и реализация), про proof of work все знают, но только Сатоши Накамото смог сделать децентрализованную криптовалюту, применив тривиальные инженерные знания (любой инженер-программист в состоянии с нуля дойти до идеи с цепочками транзакций связанных по времени хэшами с proof of work-ом)? Само собой, так быть не может. Если средства массовой информации и даже некоторые государства рекомендуют развивать эту систему, советуют её поддерживать, это гарантированно кому-то выгодно. Если бы система была честная, анонимная, безопасная, без подвохов, децентрализованная, то никому не выгодно тратить время СМИ на рекламу о ней. Это было уже понятно и до того, как вычислительные ресурсы сети сосредоточились в одних датацентрах.

Другой очевидный факт: ни одно государство в здравом уме не позволит развиваться анонимной денежной системе. Государство сделает всё, чтобы не потерять свою власть, которая держится на армии и экономике, скорее полностью на экономике, её контроле. Анонимные системы — это невозможность контролировать и даже отслеживать и наблюдать транзакции. Дэвид Чаум создавал компании, воплощающие его наработки, но все они были задавлены и закрыты. Про способность людей объединятся вокруг доброй идеи, что их не сломить, у них в руках есть же Интернет и прочее — всё это утопия, не более. Если государства не имеют ничего против Bitcoin, то значит они его могут контролировать, значит он не анонимен, не цензуроустойчив. То, что Bitcoin запрещают, например, в России, это, безусловно, разумно, так как зачем разрешать спонсирование сторонних недружественных стран?

Bitcoin на данный момент имеет пару преимуществ перед теми же online системами оплаты, такими как PayPal: отсутствие обязательных дорогих комиссий (только пока); нет возни с банковской бюрократией, привязкой карт, счетов, их обслуживания. То есть его можно рассматривать как более удобную с точки зрения интерфейса альтернативу.

schneiercash

Поэтапно рассмотрим, как можно сделать систему электронных денег.

Первый подход к снаряду прост: имеется банк, публичный ключ которого известен всем. У пользователей имеются счета в нём. Перед покупкой в магазине пользователь делает запрос в банк на определённую сумму. Банк проверяет, есть ли такая сумма на счету, вычитает её, подписывает своим приватным ключом значение этой суммы, этот чек. Технически это действительно может быть просто текстовый файл с «100.56» и подписью. Данный файл/чек отправляется пользователю. Пользователь отправляет этот подписанный чек магазину. Магазин убеждается, используя публичный ключ банка, что подпись, соответственно и чек, действительны и отпускает товар. Данный чек магазин в любое удобное время может отправить банку и тот, проверив подпись, увеличит значение денежного счёта магазина.

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

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

Само собой, банк не будет подписывать совершенно неизвестно что. Поэтому чтобы получить подписанный замаскированный чек от банка например на сумму в 100 у.е. мы делаем следующее:

• Создаём тысячу запросов на снятие «100», в каждом из которых какой-то свой уникальный идентификатор, случайное число. Каждый запрос маскируем (помещаем в конверт). И все их отправляем банку;
• Банк случайным образом выбирает 999 замаскированных запросов и просит нас выдать ему демаскирующее значение для них. Мы предоставляем эту информацию и банк демаскирует эти запросы, вскрывает конверт;
• Банк убеждается, что абсолютно во всех 999 запросах указано одно и то же число и идентификаторы чеков разные. Проверяет, есть ли эти деньги на нашем счету. Ставит подпись на единственный оставшийся замаскированный запрос и отправляет его нам;
• Мы демаскируем запрос и получаем на руках действительный подписанный чек идентификатор, которого никто ещё не видел;
• Дальше этот чек, как и прежде, отправляем магазину, тот банку, банк проверяет подпись, заносит идентификатор в базу данных (чтобы проверить, что подобный чек не использовался ни разу) и увеличивает счёт магазина.

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

Мы получаем анонимность, действительную. Банк может обнаружить факт попытки его обмана: либо пользователь два раза отправил чек, либо магазин. Банк не знает кто попытался это сделать, а наказать надо. Чтобы узнать, кто из них двоих виноват, усложним протокол: когда магазин принял чек от пользователя и проверил банковскую подпись, то он просит пользователя оставить случайную строку на его же чеке. Этот чек с случайной строкой отправляется в банк, где тот сохраняет её вместе с идентификатором чека в своей базе данных. Предполагается, что магазин/продавец не в состоянии подменить эту строку (если взять аналогию из материального мира, то, например, это бумага, в которой вырезаны квадратики, которые можно проткнуть — назад на место уже не вставишь). Банк при проверке наличия идентификатора чека в БД ещё и смотрит на сохранённую случайную строчку: если она совпадает при попытке двойного использования чека, то виноват магазин, а если она другая, то виноват покупатель.

Если виноват пользователь, то он всё-равно остаётся анонимен для банка. Если бы была возможность его деанонимизировать в момент попытки двойного использования чека, но не в штатных, честных случаях, то это дало бы возможность делать уже и offline платежи, как это происходит с чипованными банковскими картами: если пользователь попытался обмануть кассовый аппарат и воспользовался тем что у того не было связи с банком, то банк всё-равно позже узнает кто это был по журналу транзакций кассового аппарата и пользователь будет наказан. Нет необходимости его моментально «брать» на месте.

Это можно сделать используя такие приёмы криптографии как разделение секрета (secret splitting) и bit commitment. Продолжим дальше усложнять текущий протокол:

• К каждому чеку перед запросом его подписи добавляет N строк идентификации. Строка идентификации это ФИО, номер счёта, место жительства: в общем необходимая банку деанонимизирующая информация. Каждая из N строк идентификации разделяется на две части так, что получить её оригинал можно только совместив эти и только эти две части. Например, у нас имеется строка идентификации длиной в 40 байт. Мы генерируем случайную строку (шум) такой же длины и применяем XOR к этой строке и строке идентификации. На выходе получаем тоже случайную строчку. Это сродни одноразовому шифроблокноту и доказано что только имея эти две половинки (случайную строку и результат после XOR) мы можем получить оригинал;
• Каждая половинка строк идентификации шифруется пользователем разными симметричными ключами;
• Банку в итоге отсылается 1000 замаскированных конвертов в которых кроме суммы, идентификатора чека, ещё и содержится N зашифрованных пар строк идентификации;
• После демаскировки 999 конвертов банк также просит пользователя предоставить ключ дешифрования для каждой половинки всех строк идентификации и убеждается, что все они равны между собой и что в них написана вся нужная банку информация (хотя бы просто какой-то идентификатор пользователя). При этом банк ещё автоматом убеждается в том, что у пользователя действительно корректно зашифрованы и разбиты на половинки все эти строки;
• Банк подписывает оставшийся конверт, отдаёт пользователю, тот демаскирует его, отправляет продавцу. Подменить строки идентификации пользователь уже не может, так как это сделает банковскую подпись недействительной;
• Продавец после проверки подписи банка, записи случайной строки, также просит его предоставить N ключей дешифрования правой или левой части (случайным образом) каждой из строк;
• Пользователь предоставляет ключи дешифрования и продавец вместе с чеком их также отправляет в банк, который их сохранит вместе с идентификатором чека и случайной прописанной в нём от пользователя строкой.

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

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

Автор: stargrave2

Источник