Забір грошей через Інтернет за допомогою Bitcoin - так, як це було розроблено

Ще в 2009 році Bitcoin використовував функцію, яка дозволяла здійснювати обмін інформацією IP-IP. Гаманець 2009 року був не лише підтвердженням концепції, і багато кращих аспектів Bitcoin були відключені, оскільки ті, хто розробляє програмне забезпечення, не змогли його зрозуміти.

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

PKI-сертифікати - процес

Такий - не майнінг - є одноранговим аспектом Bitcoin, і це одне з перших речей, яке видалили розробники Core.

У 2009 році ще потрібно було багато роботи.

У 2009 році система ще не була завершена. Необхідно перевірити кілька можливих методів, і метод, який використовується у клієнта 2009 року, залишив бажати кращого. Потім знову це було лише доказом концепції.

Щоб виправити такі проблеми, нам потрібно почати з розуміння того, що вузли та гаманці є окремими. Вузли - це шахтарі, а гаманці - це те, що користувач використовує для здійснення транзакції P2P. У сьогоднішньому дописі я поясню, як веб-сертифікат на базі ECDSA, сертифікат SSL / TLS-сервера, який дозволяє безпечно користуватися Інтернетом, може бути основою торговельної платіжної системи - системи, яка залишається захищеною та приватною, і але також побудований таким чином, що він лише один раз надсилає плату за певною адресою.

Іншими словами, він ніколи не використовує ключі.

Є два способи відправити гроші. Якщо одержувач в Інтернеті, ви
можна ввести їх IP-адресу, і вона підключиться, отримає нову публіку
ключ та надіслати транзакцію із коментарями. Якщо одержувач є
не в Інтернеті, можна надіслати їхню адресу Bitcoin, яку
це хеш їх відкритого ключа, який вони вам дають. Вони отримають
транзакції наступного разу, коли вони підключаться і отримують блок, це
в. Цей метод має той недолік, що немає коментарів
буде відправлено, і трохи конфіденційності може бути втрачено, якщо адреса буде використана
кілька разів, але це корисна альтернатива, якщо обидва користувача не можуть
бути одночасно в Інтернеті або одержувач не може отримувати вхідні дані
з'єднання.

Сертифікат - це те, що можна використовувати як у S / MIME, так і в HTTPS.

Якщо ми візьмемо ключ, пов’язаний із сертифікатом, зареєстрованим CA, ми можемо створити публічний запис про всі монети, що надсилаються продавцю, і в той же час зберігати конфіденційність.

Ми почнемо з Аліси, споживача, та Боба, веб-продавця, який має веб-сертифікат на базі ECDSA для свого сайту HTTPS://www.bob.com.

Аліса має головний ключ Bitcoin. Головний ключ не використовується для надсилання або отримання біткойна, і може бути методом створення ідентифікаційного ключа (і навіть може бути на смарт-картці). Такий ключ, який ми будемо називати Р (Аліса).

На веб-сайті Боба (я залишаю його іншим, щоб подумати, як просто розширити механізм в електронній пошті за допомогою S-MIME) має головний ключ P (Bob).

Аліса має набір монет (тобто посилання на UTXO), які можуть бути абсолютно не пов'язані з P (Аліса) і які взагалі не мають відношення до її основного ключа. Назвемо це P (A-1-i); тут (i) позначається номер використовуваної монети.

Аліса може створити загальну таємницю (s1), використовуючи процес, задокументований у наступному документі:

ВИЗНАЧЕННЯ СПІЛЬНОГО СЕКРЕТУ ДЛЯ БЕЗПЕЧНОЇ ОБМІНІ ІНФОРМАЦІЙНО-ІХЕРАРХІЧНИХ, ДЕТЕРМІНІСТИЧНИХ КРИПТОГРАФІЧНИХ КЛЮЧІВ

Щоб використати такий механізм (один із багатьох прикладів), Аліса переходить до веб-магазину Боба і тепер прагне платити. Аліса може обчислити спільний секрет з Боб. Для більш безпечної безпеки Аліса може використовувати ідентифікатор веб-сесії, яким вона ділиться з Боб, номер рахунку-фактури чи будь-що інше. Її можна використовувати в значенні на основі HMAC для додаткової безпеки та конфіденційності, але на сьогоднішній день я буду використовувати простий хеш, щоб зробити процес простішим для розуміння.

Аліса та Боб можуть обчислити значення S, яке пов'язане з ключами, якими Аліса та Боб користуються в Інтернеті. Аліса може мати ключ посвідчення та автентифікації, який не посилається публічно на її покупки, але забезпечує всі її зв’язки з Бобом.

Аліса надсилає Бобу повідомлення, яке зашифроване в трансакції Bitcoin. Операція може бути завершена за допомогою офлайн або онлайн-процесу. Якщо Боб в Інтернеті, він може зберігати цінність нотаток від Аліси як частина веб-каси.

Якщо Боб не в Інтернеті і має досить простий сайт, він може використовувати блокчейн для запису інформації про платіж і перевірки.

Аліса посилає Бобу транзакцію на P (Bob). Боб не використовує таку адресу, тому оплата невелика; без обмеження пилу достатньо лише одного сатоші. Аліса надсилає повідомлення про оплату на адресу P (Bob), а Боб не використовує її для отримання коштів. Можна сказати, що БОБ ТІЛЬКИ витрачатиметься з адреси (тієї, що пов’язана із відкритим ключем P (Bob)), коли сертифікат позначений як закінчений. Процес діє як форма розподіленого "списку відкликань", де Боб може керувати власним ключем. Більше того, якщо ключ і сертифікат Боба коли-небудь атакуються, а зловмисники тут проводять пилові транзакції, це діє як автоматичне попередження. Боб міг би зберегти на рахунку невелику кількість коштів як засіб, щоб хакери могли вважати, що це дійсна адреса для використання (наприклад, 2000 доларів), яка втрачається лише у тому випадку, якщо обліковий запис був зламаний, але це також попереджає всіх клієнтів Боба до нападу.

Боб може зробити обліковий запис більш приватним за допомогою підрозділу - див. Рис. 9 в патенті:

9 з патенту 42

У Боба навіть може бути процес, коли номер рахунку-фактури асоціюється з підрозділом.

Тепер Аліса надсилає на адресу, пов'язану з P (Bob) - і в сценарій або як значення OP_RETURN включає значення, яке було зашифровано (наприклад, за допомогою алгоритму шифрування AES). Використовуючи метод, зазначений вище, Боб може розрахувати (S). Дані у повідомленні Бобу, надісланому за допомогою одного сатоші (плюс збори за видобуток), містять усі необхідні відомості Боба, щоб знайти, куди Аліса надіслала платіж. Боб використовує симетричний ключ (S) для розшифрування даних у повідомленні:

  • Шифрування (S) [M]

що передає Бобу повідомлення від Аліси, М.

  • Розшифрувати (S) [M]

Тепер Боб може обчислити ключову адресу з похідного ключа:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • Клавіша повідомлення P (Спільне повідомлення) = HMAC (M ~ S) xG

ТІЛЬКИ Боб та Аліса дізнаються про новий секретний HMAC (M ~ S).

Аліса може довести, що вона надіслала виплату Бобу. Боб може знайти гроші від Аліси і підтвердити транзакцію.

У той же час жодна сторона не може визначити адресу, з якої Аліса надіслала їй платіж - P (A-1-i) до Боба на P (Bob-Paid).

Оскільки Боб має запис на блокчейні в P (Bob), і має повний слід аудиту всіх отриманих ним платіжних адрес. Запис може бути пов’язаний з рахунками-фактурами, замовленнями на купівлю тощо тощо, що дозволяє Боб створити повний аудиторський слід усіх бірж і той, який не може бути видалений, змінений або маніпульований. Метод відповідає всім необхідним питанням законодавчого обліку для Боба, і він може мати роздільну адресу, де ПДВ та інші податки з продажу надсилаються уряду, коли він сплачується. Іншими словами, Бобі не потрібно проводити дорогі перевірки, і податковий орган може бути сплачений негайно без зволікань.

Токени та біткойн

Використовуючи такий протокол, як Tokenized або один з різних протоколів, на які nChain подав патенти, Аліса і Боб також можуть обмінятися токенізованим фіат. Це означає, що Аліса могла заплатити Бобу за допомогою маркера GBP, виданого банком у Великобританії. Такий маркер передається за допомогою перерахованого вище процесу, що дозволяє Алісі та Боб безпечно та надійно здійснювати транзакції за допомогою цифрових готівкових коштів у місцевій валюті за вибором, в той час як Біткойн як "сантехніка" для обміну.

Метанетне посилання

Таким чином, навіть якщо Боб працює офлайн-веб-сайт - тобто проста система без резервної бази даних - записи, отримані проти клавіші P (Bob), тепер можуть виступати формою незмінного сховища даних.

Повідомлення про те, що Аліса шифрує до Боба, може бути повним замовленням.

Його можна виконати за допомогою існуючих типів повідомлень EDI. На відміну від EDI, метод є безпечним, захищеним та приватним.

Краще, запис непорушний. Тут немає місця для бухгалтерських шахрайств. Ви можете скасувати транзакції, але для цього потрібно повернути кошти першоджерелу.

Аліса і Боб можуть записати весь комерційний процес.

Боб може містити ряд ієрархічних адрес, які фіксують усі етапи замовлення - від виставлення рахунків та платежів до відправлення та доставки. Якщо у Боб зараз є підмайстер-ключ для кожного клієнта (див. Патент вище та рис. 9), він також може побудувати окремий підрозділ, відомий йому, клієнту та податковому органу для цілей аудиту, але ні інші, що дозволяє йому зберігати абсолютний рівень конфіденційності, коли інші клієнти та постачальники навіть не знають, скільки угод він робить. Більше того, він може конструювати виплати таким чином, що дозволяє йому ізолювати внутрішніх службовців і давати їм знати лише інформацію, що стосується власних підрозділів.

Якщо клавіша, пов'язана з CA, не торкається, акаунти можна надсилати на стару адресу. Ключ суб-ЦС може бути пов’язаний із звітним роком та згорнутий кожен податковий період. Ви закриваєте сертифікат, збираєте будь-які платежі, зроблені як пил, і в той же час закриваєте книги, готові до нового звітного року.

Повідомлення EDI

EDI - це існуюча схема кодування для комерції.

Формати повідомлень ANSI та EDIFACT ми бачимо на зображенні нижче:

ANSI проти EDIFACT

У нашій системі ми використовуємо ключ шифрування для даних у повідомленні (а не платіж) як "групове повідомлення". Повідомлення про обмін не потрібно. Такий був би чоловік середнього віку, і в біткойнах ми усунули потребу в ньому.

Стандартний EDI

Нова модель комерції - це така модель, де всі записи незмінні, не можуть бути втрачені, і дозволяють Алісі та Боб торгувати приватно.

Обмін даними Bitcoin

І інструменти для встановлення EDI для трансакції Bitcoin просто виглядатимуть як інструменти EDI, як є сьогодні.

Навіть вбудований у транзакцію Bitcoin, зашифрований формат EDI XML може бути просто вилучений та відображений або надрукований як будь-який інший рахунок-фактура чи замовлення:

Відображений рахунок-фактура

У існуючому світі EDI клієнтам стягується плата за допомогою моделей, що працюють в межах цінових діапазонів на основі передбачуваних обсягів кіло-символів (KC) або документів. Існують також приховані плати, такі як мінімальна довжина запису, у багатьох постачальників послуг вказана довжина запису від 128 до 512 символів. Результат полягає в тому, що якщо ви надішлите 12 документів з 12 символів, вам буде нараховано до 5120 символів, навіть якщо надіслали лише 144 символи.

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

Така річ не є проблемою для Bitcoin.

Хоча максимальний розмір повідомлення, дозволений для повідомлень NACCS EDI, становить 500 000 байт, реальність полягає в тому, що EDI та інші пов'язані повідомлення зазвичай складають порядку 150 байт. Надсилання незмінної, приватної, захищеної системи виставлення рахунків та рахунків для фракцій відсотків за рахунок-фактура - порівняйте це з 2 до 3 доларів за деякі рішення EDI і навіть 0,20 доларів за просту операцію Visa, і… пора почати переосмислення. як ти ведеш бізнес.

У такій моделі жодну біткоїнову адресу не потрібно використовувати більше одного разу, а платежі та рахунки-фактури пов’язані приватно - що може бути навіть псевдонімом, оскільки ідентифікатор не повинен містити сертифікат користувача.