Посторонним в

Блог-форум Винни Пуха
 
ФорумФорум  ЧаВоЧаВо  ПоискПоиск  ПользователиПользователи  ГруппыГруппы  РегистрацияРегистрация  ВходВход  

Поделиться | 
 

 Начало криптовалют / Вэй Дай, Сатоши Накамото

Предыдущая тема Следующая тема Перейти вниз 
АвторСообщение
Winnie
Admin


Сообщения : 676
Дата регистрации : 2015-06-10

СообщениеТема: Начало криптовалют / Вэй Дай, Сатоши Накамото   2017-11-18, 04:42

Первое описание протокола крипто-валюты / Вэй Дай (1998)
http://tango.ucoz.de/load/perevod_pervogo_opisanija_protokola_kripto_valjuty/1-1-0-1
http://tango.ucoz.de/_ld/0/1_Wei_Dai.txt

Идеи криптовалюты «b-money» описал в 1998 году Вэй Дай (англ. Wei Dai) в рассылке шифропанков. Также свои предложения сделал Ник Сабо (англ. Nick Szabo) под названием «Bitgold».

Оригинальный текст на английском языке находится по адресу
http://www.weidai.com/bmoney.txt
а также приведён ниже.

Перевод на русский язык выполнен в 2013 году tango.

-------

Крипто-анархия: насилие невозможно потому, что нельзя установить настоящие имена участников и место их физического нахождения.
Для эффективного сотрудничества необходимо средство обмена (деньги). Традиционно эти услуги предоставляет правительство (банки) и только для юридических лиц. В этой статье я описываю протокол, с помощью которого эти услуги могут быть предоставлены анонимно неопределенному кругу лиц.
Предполагается существование неотслеживаемой (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 и зачисляет их на счет автора решения.
Вернуться к началу Перейти вниз
Посмотреть профиль http://free.userboard.net
Winnie
Admin


Сообщения : 676
Дата регистрации : 2015-06-10

СообщениеТема: Re: Начало криптовалют / Вэй Дай, Сатоши Накамото   2017-11-18, 04:56

-------

I am fascinated by Tim May's crypto-anarchy. Unlike the communities traditionally associated with the word "anarchy", in a crypto-anarchy the government is not temporarily destroyed but permanently forbidden and permanently unnecessary. It's a community where the threat of violence is impotent because violence is impossible, and violence is impossible because its participants cannot be linked to their true names or physical locations.

Until now it's not clear, even theoretically, how such a community could operate. A community is defined by the cooperation of its participants, and efficient cooperation requires a medium of exchange (money) and a way to enforce contracts. Traditionally these services have been provided by the government or government sponsored institutions and only to legal entities. In this article I describe a protocol by which these services can be provided to and by untraceable entities.

I will actually describe two protocols. The first one is impractical, because it makes heavy use of a synchronous and unjammable anonymous broadcast channel. However it will motivate the second, more practical protocol. In both cases I will assume the existence of an untraceable network, where senders and receivers are identified only by digital pseudonyms (i.e. public keys) and every messages is signed by its sender and encrypted to its receiver.

In the first protocol, every participant maintains a (seperate) database of how much money belongs to each pseudonym. These accounts collectively define the ownership of money, and how these accounts are updated is the subject of this protocol.

1. The creation of money. Anyone can create money by broadcasting the solution to a previously unsolved computational problem. The only conditions are that it must be easy to determine how much computing effort it took to solve the problem and the solution must otherwise have no value, either practical or intellectual. The number of monetary units created is equal to the cost of the computing effort in terms of a standard basket of commodities. For example if a problem takes 100 hours to solve on the computer that solves it most economically, and it takes 3 standard baskets to purchase 100 hours of computing time on that computer on the open market, then upon the broadcast of the solution to that problem everyone credits the broadcaster's account by 3 units.

2. The transfer of money. If Alice (owner of pseudonym K_A) wishes to transfer X units of money to Bob (owner of pseudonym K_B), she broadcasts the message "I give X units of money to K_B" signed by K_A. Upon the broadcast of this message, everyone debits K_A's account by X units and credits K_B's account by X units, unless this would create a negative balance in K_A's account in which case the message is ignored.

3. The effecting of contracts. A valid contract must include a maximum reparation in case of default for each participant party to it. It should also include a party who will perform arbitration should there be a dispute. All parties to a contract including the arbitrator must broadcast their signatures of it before it becomes effective. Upon the broadcast of the contract and all signatures, every participant debits the account of each party by the amount of his maximum reparation and credits a special account identified by a secure hash of the contract by the sum the maximum reparations. The contract becomes effective if the debits succeed for every party without producing a negative balance, otherwise the contract is ignored and the accounts are rolled back. A sample contract might look like this:

K_A agrees to send K_B the solution to problem P before 0:0:0 1/1/2000.
K_B agrees to pay K_A 100 MU (monetary units) before 0:0:0 1/1/2000.
K_C agrees to perform arbitration in case of dispute. K_A agrees to pay a maximum of 1000 MU in case of default. K_B agrees to pay a maximum of 200 MU in case of default.
K_C agrees to pay a maximum of 500 MU in case of default.

4. The conclusion of contracts. If a contract concludes without dispute, each party broadcasts a signed message "The contract with SHA-1 hash H concludes without reparations." or possibly "The contract with SHA-1 hash H concludes with the following reparations: ..." Upon the broadcast of all signatures, every participant credits the account of each party by the amount of his maximum reparation, removes the contract account, then credits or debits the account of each party according to the reparation schedule if there is one.

5. The enforcement of contracts. If the parties to a contract cannot agree on an appropriate conclusion even with the help of the arbitrator, each party broadcasts a suggested reparation/fine schedule and any arguments or evidence in his favor. Each participant makes a determination as to the actual reparations and/or fines, and modifies his accounts accordingly.

In the second protocol, the accounts of who has how much money are kept by a subset of the participants (called servers from now on) instead of everyone. These servers are linked by a Usenet-style broadcast channel. The format of transaction messages broadcasted on this channel remain the same as in the first protocol, but the affected participants of each transaction should verify that the message has been received and successfully processed by a randomly selected subset of the servers.

Since the servers must be trusted to a degree, some mechanism is needed to keep them honest. Each server is required to deposit a certain amount of money in a special account to be used as potential fines or rewards for proof of misconduct. Also, each server must periodically publish and commit to its current money creation and money ownership databases. Each participant should verify that his own account balances are correct and that the sum of the account balances is not greater than the total amount of money created. This prevents the servers, even in total collusion, from permanently and costlessly expanding the money supply. New servers can also use the published databases to synchronize with existing servers.

The protocol proposed in this article allows untraceable pseudonymous entities to cooperate with each other more efficiently, by providing them with a medium of exchange and a method of enforcing contracts. The protocol can probably be made more efficient and secure, but I hope this is a step toward making crypto-anarchy a practical as well as theoretical possibility.

-------

Appendix A: alternative b-money creation

One of the more problematic parts in the b-money protocol is money creation. This part of the protocol requires that all of the account keepers decide and agree on the cost of particular computations. Unfortunately because computing technology tends to advance rapidly and not always publicly, this information may be unavailable, inaccurate, or outdated, all of which would cause serious problems for the protocol.

So I propose an alternative money creation subprotocol, in which account keepers (everyone in the first protocol, or the servers in the second protocol) instead decide and agree on the amount of b-money to be created each period, with the cost of creating that money determined by an auction. Each money creation period is divided up into four phases, as follows:

1. Planning. The account keepers compute and negotiate with each other to determine an optimal increase in the money supply for the next period. Whether or not the account keepers can reach a consensus, they each broadcast their money creation quota and any macroeconomic calculations done to support the figures.

2. Bidding. Anyone who wants to create b-money broadcasts a bid in the form of <x, y> where x is the amount of b-money he wants to create, and y is an unsolved problem from a predetermined problem class. Each problem in this class should have a nominal cost (in MIPS-years say) which is publicly agreed on.

3. Computation. After seeing the bids, the ones who placed bids in the bidding phase may now solve the problems in their bids and broadcast the solutions.

4. Money creation. Each account keeper accepts the highest bids (among those who actually broadcasted solutions) in terms of nominal cost per unit of b-money created and credits the bidders' accounts accordingly.

Wei Dai, 1998
http://www.weidai.com/bmoney.txt
Вернуться к началу Перейти вниз
Посмотреть профиль http://free.userboard.net
Winnie
Admin


Сообщения : 676
Дата регистрации : 2015-06-10

СообщениеТема: Re: Начало криптовалют / Вэй Дай, Сатоши Накамото   2017-11-18, 05:01

Биткойн: система цифровой пиринговой наличности / Сатоши Накамото (2008)
https://bitnovosti.com/2012/12/22/bitcoin-genesis/
https://bitcoin.org/bitcoin_ru.pdf
https://bitcoin.org/files/bitcoin-paper/bitcoin_ru.pdf
http://bitcoinwhitepaper.info/bitcoin_ru.pdf

Оригинальный текст на английском языке
Bitcoin: A Peer-to-Peer Electronic Cash System / Satoshi Nakamoto (2008)
https://bitcoin.org/bitcoin.pdf

Перевод на русский язык выполнен в 2012 году arvicco, grich.
Вернуться к началу Перейти вниз
Посмотреть профиль http://free.userboard.net
Спонсируемый контент




СообщениеТема: Re: Начало криптовалют / Вэй Дай, Сатоши Накамото   

Вернуться к началу Перейти вниз
 
Начало криптовалют / Вэй Дай, Сатоши Накамото
Предыдущая тема Следующая тема Вернуться к началу 
Страница 1 из 1
 Похожие темы
-
» Методы тренировки спортивных голубей.
» Начало сезона.

Права доступа к этому форуму:Вы не можете отвечать на сообщения
Посторонним в :: Социум :: Вектор постгосударства-
Перейти: