Взимане на пари по интернет, използвайки Bitcoin - по начина, по който е проектиран

Още през 2009 г. Bitcoin използва функция, която позволява обмен на информация IP-IP. Портфейлът от 2009 г. не беше нещо повече от доказателство за концепция и много от най-добрите аспекти на Bitcoin бяха деактивирани, тъй като тези, които разработват софтуера, не успяха да го разберат.

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

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

Такъв - а не майнинг - е аспектът на връстници на биткойн и е едно от първите неща, които Core разработчиците премахнаха.

През 2009 г. все още се изискваше много работа.

През 2009 г. системата все още не беше завършена. Няколко възможни метода трябваше да бъдат тествани и методът, използван в клиента от 2009 г., остави много да се желае. След това отново беше просто доказателство за концепция.

За да отстраним подобни проблеми, трябва да започнем с разбирането, че възлите и портфейлите са отделни. Възлите са миньори, а портфейлите са това, което се използва от потребителя, за да позволи P2P транзакция. В днешната публикация ще обясня как базиран на ECDSA уеб сертификат, SSL / TLS-сертификат, който ви позволява да сърфирате безопасно в интернет, може да бъде основата на търговската система за разплащане - система, която остава защитена и частна, и но също така е конструиран така, че изпраща плащане до определен адрес само веднъж.

С други думи, никога не използва повторно клавиши.

Има два начина за изпращане на пари. Ако получателят е онлайн, вие
могат да въведат IP адреса им и той ще се свърже, ще получи нова публичност
ключ и изпратете транзакцията с коментари. Ако получателят е
не онлайн, е възможно да се изпрати на техния биткойн адрес, който
е хеш на техния публичен ключ, който ви дават. Ще получат
транзакцията следващия път, когато се свържат и получат блока
инча. Този метод има недостатъка, че няма информация за коментари
се изпраща и може да се загуби малко поверителност, ако се използва адресът
многократно, но това е полезна алтернатива, ако и двамата потребители не могат
бъдете едновременно онлайн или получателят не може да получава входящи
връзки.

Сертификатът е нещо, което може да се използва както в S / MIME, така и в HTTPS.

Ако вземем ключа, който е свързан със сертификат, регистриран от СА, можем да създадем публичен запис на всички монети, които се изпращат на търговеца и в същото време да запазим поверителността.

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

Алиса има главен ключ на Bitcoin. Главният ключ не се използва за изпращане или получаване на биткойни и може да бъде метод за създаване на идентификационен ключ (и дори може да бъде на смарт карта). Такъв е ключът, който ще наречем P (Алиса).

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

Алиса има набор от монети (тоест UTXO препратки), които могат да бъдат напълно несвързани с P (Alice) и които изобщо нямат отношение към основния й ключ. Ще го наречем P (A-1-i); тук (i) се отнася номерът на използваната монета.

Алиса може да създаде обща тайна (s1), използвайки процеса, документиран в следния документ:

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

За да използва такъв механизъм (един от многото примери), Алис отива в уеб магазина на Боб и сега се стреми да плати. Алиса може да изчисли споделена тайна с Боб. За да бъде по-сигурна, Алиса може да използва идентификационния номер на уеб сесията, който споделя с Боб, номера на фактурата или нещо друго. Може да се използва в стойност, базирана на HMAC, за да добавя допълнителна сигурност и поверителност, но за днес ще използвам обикновен хеш, за да направя процеса по-лесен за разбиране.

Алис и Боб могат да изчислят стойност S, която е свързана с ключове, които Алис и Боб използват в мрежата. Алиса може да има ключ за самоличност и удостоверяване, който не свързва публично с нейните покупки, но гарантира всичките й комуникации с Боб.

Алис изпраща съобщение до Боб, което е криптирано в транзакция с биткойн. Сделката може да бъде завършена с използване на офлайн или онлайн процес. Ако Боб е онлайн, той може да съхранява стойността на nonce от Alice като част от онлайн касата.

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

Алис изпраща на Боб транзакция на P (Bob). Боб не използва такъв адрес, така че плащането е малко; без ограничението за прах само един сатоши ще е достатъчен. Алис изпраща съобщението за плащането до P (Bob) адреса, а Боб не го използва за средства. Можем да кажем, че Боб САМО ще похарчи от адреса (този, свързан с публичния ключ P (Bob)), когато сертификатът е маркиран като изтекъл. Процесът действа като форма на разпределен „списък за отмяна“, където Боб може да контролира собствения си ключ. Нещо повече, ако ключът и сертификатът на Боб бъдат атакувани някога и транзакциите за прах тук се харчат от нападател, той действа като автоматичен сигнал. Боб би могъл да запази малко количество средства в акаунта като средство, което да позволи на хакерите да мислят, че това е валиден адрес за използване (напр. 2000 долара), който ще бъде загубен само ако акаунтът е хакнат, но това също сигнализира за всички клиенти на Боб към атаката.

Боб може да направи акаунта по-личен с помощта на под ключ - вижте фиг. 9 в патента:

Фиг. 9 от патент 42

Боб дори може да има процес, при който номерът на фактурата е свързан с под ключ.

Сега Алис изпраща до адреса, свързан с P (Bob) - и в скрипта или като стойност OP_RETURN включва стойност, която е била криптирана (например с използването на алгоритъм за криптиране AES). Използвайки описания по-горе метод, Боб може да изчисли (S). Данните в съобщението до Боб, изпратено с един-единствен сатоши (плюс такси за добив), съдържат всичко, което Боб трябва да знае, за да намери къде Алис е изпратила плащането. Боб използва симетричния ключ (S), за да декриптира данните в съобщението:

  • Encrypt (S) [М]

което дава на Боб посланието от Алис, М.

  • Decrypt (S) [М]

Боб вече може да изчисли ключов адрес от извлечения ключ:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • Ключът за съобщение е P (Споделено съобщение) = HMAC (M ~ S) xG

САМО Боб и Алиса ще знаят новия секретен HMAC (M ~ S).

Алиса може да докаже, че е изпратила плащане на Боб. Боб може да намери парите от Алис и да потвърди транзакцията.

В същото време никоя външна страна не може да определи адреса, от който Алис е изпратила плащането си от - P (A-1-i) до Боб на P (Bob-Paid).

Тъй като Боб има запис в blockchain на P (Bob), и има пълен одитен следа на всички получени адреси за плащане. Записът може да бъде свързан с фактури, поръчки за покупка и други, което позволява на Боб да изгради пълен одитен път на всички борси и такъв, който не може да бъде изтрит, променен или манипулиран. Методът отговаря на всички необходими законодателни счетоводни проблеми за Боб и той може да има разделен адрес, където ДДС и други данъци върху продажбите се изпращат на правителството, докато той е платен. С други думи, Боб няма нужда да изпитва скъпи одити и данъчният орган може да бъде платен незабавно без забавяне.

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

Използвайки протокол като Tokenized или един от различните, за които nChain е подал патенти, Алис и Боб могат също да обменят токенизиран фиат. Това означава, че Алис би могла да плати на Боб с помощта на маркер GBP, издаден от банка във Великобритания. Такъв жетон се предава чрез описания по-горе процес, което позволява на Алис и Боб безопасно и сигурно да осъществяват транзакции, използвайки цифрови пари в местната си валута по избор, докато все още използват Bitcoin като „водопровод“ за размяната.

Свързване на метанет

Като такъв, дори ако Боб използва офлайн уебсайт - тоест опростена система без база данни, записите, получени срещу клавиша P (Bob), вече могат да действат като форма на неизменим хранилище на данни.

Съобщението, че Алиса криптира на Боб, може да бъде пълният ред.

Тя може да бъде завършена с помощта на съществуващи типове съобщения EDI. За разлика от EDI, методът е безопасен, сигурен и частен.

По-добре, записът е неизменен. Няма място за счетоводни измами. Можете да обърнете транзакции, но това изисква връщане на средства към първоизточника.

Алис и Боб могат да запишат целия търговски процес.

Боб може да държи поредица от йерархични адреси, които записват всички етапи от поръчката - от фактуриране и плащане до изпращане и доставка. Ако Боб сега има под-главен ключ за всеки клиент (вижте патента по-горе и фиг. 9), той също може да конструира отделен под ключ, който е известен на самия него, клиента и данъчния орган за целите на одита, но не други, което му позволява да запази абсолютно ниво на поверителност, където други клиенти и доставчици дори не знаят колко транзакции прави. Нещо повече, той може да конструира плащания по начин, който му позволява да изолира вътрешните служители и да ги накара да знаят само информацията, свързана със собствените им отдели.

Докато ключът, свързан с CA, не се докосва, акаунтите могат да бъдат изпратени на стария адрес. Ключът на под-CA може да бъде свързан със счетоводната година и също така да се предава всеки данъчен период. Затваряте сертификата, събирате всякакви плащания като прах и в същото време затваряте книгите, готови за новата счетоводна година.

EDI съобщение

EDI е съществуваща схема за кодиране за търговия.

Можем да видим форматите на съобщения ANSI и EDIFACT на изображението по-долу:

ANSI срещу EDIFACT

В нашата система използваме ключа за криптиране за данните в съобщението (а не плащането) като „групово съобщение“. Няма нужда от съобщение за обмен. Такъв би бил среден човек и в Биткойн сме премахнали нуждата от него.

Стандартна EDI

Новият модел за търговия е този, при който всички записи са неизменни, не могат да бъдат загубени и позволяват на Алис и Боб да търгуват насаме.

Обмен на данни с биткойн

И инструментите за свързване на EDI към транзакция с биткойн просто биха изглеждали като инструменти на EDI, каквито са днес.

Дори вграден в транзакция с биткойн, криптираният EDI XML формат може просто да бъде извлечен и показан или отпечатан като всяка друга фактура или поръчка:

Показана фактура

В съществуващия свят на EDI, клиентите се таксуват с помощта на модели, които работят в рамките на ценови диапазони въз основа на очакваните обеми от Kilo-символи (KC) или документи. Има и скрити такси, като минимална дължина на записа с много доставчици, посочваща дължина на записа от 128 до 512 знака. Резултатът е, че ако изпратите 12 документа с 12 знака, ще бъдете таксувани до 5 120 знака, въпреки че изпращате само 144 знака.

За търговци с голям обем малки транзакции те могат да добавят значителна сума към месечната ви такса.

Подобно нещо не е проблем с Bitcoin.

Въпреки че максималният размер на съобщенията, допустим за съобщенията на NACCS EDI, е 500 000 байта, реалността е, че EDI и други свързани съобщения обикновено са от порядъка на 150 байта. Изпращането на неизменна, частна, сигурна система за фактуриране и счетоводство за фракции от сто процента на фактура - сравнете това с 2 до 3 долара за някои EDI решения и дори 0,20 долара за обикновена транзакция с Visa и… време е да започнете да преосмисляте. как правиш бизнес.

В такъв модел не трябва да се използва нито един биткойн адрес повече от веднъж и плащанията и фактурите са свързани частно - което дори може да бъде псевдоним, тъй като идентификационният номер не трябва да бъде в потребителски сертификат.