Bitcoin і раніше створені системи анонімних електронних грошей

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

За основу я візьму статтю «Універсальний 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 не зробити. Більше того: їх навіть не зробити швидко, так як для підтвердження транзакції необхідно, щоб вона опинилася в декількох блоках найдовшою ланцюжка (хоча факт появи транзакції видно швидко). У разі оплати якихось дрібниць (ну там бутерброда) можна піти на ризик і навіть якщо транзакція не буде дійсною — не велика втрата. Тобто знову на практиці тільки мікроплатежі.

  гроші Банківські картки PayPal Bitcoin schneiercash
Децентралізованого Немає Немає Немає Немає Немає
Незалежність від фізичних умов Немає Немає Так Так Так
Безпека Так Так Так Немає Так
Анонімність Так Немає Немає Немає Так
Offline платежі Так Так Немає Немає Так
Передача грошей користувачам Так Немає Немає Немає Немає
Дроблення Немає Так Так Так Немає


В даній таблиці мається на увазі, що банківські картки чипованы і з ними можна робити 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 і виявленням того, хто спробував ошукати банк, протокол вже досить складний. Але він ще не дає можливість дробити гроші (чеки атомарны і доведеться робити запит в банк на поповнення рахунку, та запиту двох окремих чеків на менші необхідні суми) і передавати безпосередньо користувачам, минаючи спілкування з банком (тобто користувачеві доведеться зіграти роль продавця, який повинен поповнити свій рахунок). Існують набагато більш складні реалізації, які вирішують ці проблеми, що залишилися… крім ніким не вирішеної проблеми децентралізації.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.