+++++++++
DAG как обобщение блокчейна (
by CfB)
Идея вытекает из блокчейна вот таким естественным образом:
1. Отмените транзакции, генерирующие награду майнеру из ниоткуда;
2. Разрешите одну транзакцию на блок;
3. Разрешите блоку ссылаться на несколько произвольных предыдущих блоков.
Конечно, эта идея, как и все очевидные вещи, не особо привлекала внимания.
+ 2017.09.03 [10:06 AM] by
CfBDoublespending is prevented by a "demon" which derives network topology/activity from tangle topology.
MCMC algo is such a demon.
People didn't get used to that concept yet, because they used to blockchain where information about network topology is destroyed (unintentionally) by explicit degradation of DAG into a blockchain.
Here is a simple example:
Start issuing blocks very fast. If there is only one miner then the chain will be kept as a chain. If there are 2 miners then you'll be seeing orphans forming a double-chain looking like DNA helix. If there are a lot of miners you'll see Tangle.
+++++++++
консенсус, основанный на интуиции (by
mthcl)
Конечно, было бы здорово иметь доказательство безопасности Ёты. Поверьте, мне бы очень хотелось его получить. Но иногда сложность зашкаливает. Поэтому всё что у меня есть пока - это интуиция о
Цепях Маркова, которая, по моему скромному мнению, заслуживает некоторого уважения. Кроме того, вы же понимаете, что вся современная криптография открытых ключей основана на недоказанных утверждениях? Что нам теперь, прекратить её использование, пока не будет доказано, что P≠NP ?
+++++++++
IOTA consensus and how it can be achieved if we are using Monte Carlo algorithm (by
CfB)
Here green color squares are referenced (directly or indirectly) by ALL gray squares.
The main question that arises: - How can you achieve a consensus if Random Walk Monte Carlo algo gives different gray squares?
We see that green squares are referenced no matter what gray square was picked by the Monte Carlo
This is the nuance which some people don't see (and we don't emphasize because it's too obvious)
We come to consensus on the status of green squares only
More time passes - more transactions added - and eventually those white squares will be colored with green too
We don't know if young transactions are legit or not, but old ones are legit with very high probability (if they are referenced by the majority of tips returned by Monte Carlo)
+++++++++
double-spending (by CfB)
Most of time a node receives and shares transactions with neighbors. It cares about tangle topology only when it's time to generate a transaction or to accept a payment.
Imagine that now it's 16:04 and Bob decides to send a message
He creates a transaction that reference 2 transactions:
- one deposits 1 iota to Alice address
- the other spends 1 iota from Alice address
This doesn't lead to a double-spending so at 16:07 he stops creating a transaction containing his message
90 minutes later bad guy Charlie decides to reference Bob's transaction and another transaction that spends 1 iota from Alice address
At 17:44 he finishes generating a transaction that references a subtangle with an illegal state (ledger)
None of us cares about that, we don't know about bad guy Charlie because our nodes keep receiving all transactions and sharing them among us
At 19:15 good girl Diana decides to send a message to her mother, she analyzes Tangle and sees that she shouldn't reference Charlie's transaction so she references Bob's transaction instead.
Her transaction is not special, so it's not shown in the picture
Few minutes later smart girl Eva decides to send a message to her boyfriend. She is good but she is also smart and decides to troll bad guy Charlie...
She finds a transaction that deposits 1 iota to Alice address. She references that transaction and also the transaction of Charlie. We see Eva's transaction at 19:21
Later someone else generating a transaction will reference Eva's transaction without any issues because she "fixed" the problem created by Charlie.
As we can see in this scenario during a short period of time ledger can be inconsistentEverything will be fine as long as 67%+ of hashing power is controlled by benevolent users.
PS: It's worth emphasizing that in IOTA we don't care about the
order of transactions. For ledger validation we can traverse the transactions in any order. This boosts performance and helps to scale to much higher TPS than a ledger with ordering would allow.
+++++++++
http://www.tangleblog.com/2017/07/10/is-double-spending-possible-with-iota/+++++++++
Markov chain Monte Carlo Random Walk tips selection (by mthcl)
The basic idea is: if you want to be accepted by others, do what they expect you to do. You know there is a complicated probability distribution on the set of tips, according to which the "honest" nodes choose their tips to reference. This probability distribution is effectively concentrated on "good tips", but there seem to be no way to discover which tips are (slightly) better other than running the MCRW many times. However, if a node is so selfish that he wants to really reference the tips whose weight (according to that distribution) is maximized, he would need to run MCRW really many times, and even then the gain would be marginal. However, running MCRW many times requires time/resources; after you spend some time on it, the state of the tangle will already change, so you'll have to start anew. In a way, it's like playing blitz in chess: if you want to win, you don't have to always play best moves; you need to play (reasonably) good moves, but
fast ...
+++++++++ "Путаница для чайников" by Johann
В биткоине и других блокчейновых криптовалютах "доказательство работой" (POW) применяется к блокам,
при этом блоки имеют определённую транзакционную ёмкость. То есть вы вынуждены комиссией мотивировать майнеров на включение в блок вашей транзакции.
В Ёте же POW применяется к самим транзакциям. С каждой добавленной в Путаницу (tangle) транзакцией Ёто-сеть получает больше POW и больше безопасности. Поэтому мотивацией для нод на принятие вашей транзакции является сама ваша транзакция.
Каждая транзакция должна подтвердить две другие. С очередными подтверждениями транзакция получает всё больше POW, и всё больше страховки от двойной траты.
+++++++++ (не)безопасность(?) Ёты:
https://bitcointalk.org/index.php?topic=1298661.msg19626898#msg19626898+++++++++ Вот такая она, Путаница, внезапная и противоречивая ...
https://bitcointalk.org/index.php?topic=1298661.msg22146165#msg22146165+++++++++ оборотная сторона swarm-интеллекта Ёты:
https://bitcointalk.org/index.php?topic=1298661.msg19819473#msg19819473Избранноеа что за алгоритм? кто по русски объяснить может?
Алгоритм PoW. Самодельная хэш-функция "SaM" (Split-and-Merge). Награды за блок нет. И блоков тоже нет. Соответственно, и времени между блоками нет - ёты можно отправлять беспрерывно. Комиссий за транзакции, конечно, нет. Простота, значит простота.
Есть Путаница (Tangle). Или, может, "Плетёнка", или "Косичка".
Есть только транзакции (пачки транзакций, bundle). Чтобы вставить свою пачку транзакций в нити Халы, узел должен выполнить некоторую работу. PoW.
Свежая пачка - в "белой книге" ещё называемая "тип" (tip) - должна сослаться на две предыдущие пачки.
Вся хитрость в алгоритме выбора этих двух пачек.
Нужно, чтобы Путаница не слишком росла вширь, но и не превращалась в тонкую верёвку.
То есть по сравнению с Биткоином всё перевёрнуто с ног на голову. Отправить транзакцию стоит работы, но не требует комиссии. Майнинга нет, блокчейна нет, полные узлы не нужны(?). Поскольку нет блоков - нет и межблоковых интервалов, узлы отправляют транзакции постоянно (встраивают их в Путаницу). И работу пир выполняет не двоичную, как во всех компьютерах, а троичную:
https://ru.wikipedia.org/wiki/Трит Зато защищённую от квантовых компьютеров.
!!!!!!!!!
старые Ёто-адреса:
http://188.138.57.93/addressgenerator.html (раскопал alittle)
!!!!!!!!!
perl-библиотека:
http://github.com/ifinta/IOTAstrip пример:
https://bitcointalk.org/index.php?topic=1216479.msg14306700#msg14306700!!!!!!!!!
IOTA Bundle:
https://bitcointalk.org/index.php?topic=1298661.msg14291162#msg14291162:) :) :) Ёта в лицах:
https://bitcointalk.org/index.php?topic=1298661.msg19555270#msg19555270
Предыдущие версии IRI (Iota Reference Implementation)
Публикую версию 0.9.0. Она содержит референсный клиент "Nostalgia". Он без дизайна, и выглядит как гость из 90-х. Не пугайтесь, это просто референсный клиент только для тестирования.
Первое что вам нужно сделать - перейти со старого адреса на новый. Для этого нужно нажать кнопку [Claim iotas] и подождать несколько минут.
Nostalgia отображает только транзакции с вашими адресами. Если вы кому-то переводили ёты, то увидите только те адреса, с которых ёты ушли. Чтобы увидеть адреса получателей, нажмите [Show bundle]. Bundle - это пачка транзакций. Обычный перевод требует 4-х транзакций: одна для получателя (+), одна для сдачи (+), одна для траты всего баланса (-), и одна дополнительная транзакция с нулём ёт для обеспечения 162-х тритной безопасности. 243-х тритная безопасность требует две дополнительные транзакции, а 81-но тритная безопасность вообще их не требует.
Версия референсная, алгоритм не оптимизирован, поэтому генерация транзакций требует много времени. Также требуется примерно 30 секунд на получение последних изменений от координатора. Обратите внимание, что IP адрес координатора изменился (указан в configuration.iri и nodes.iri).
NB: За один раз можно затребовать до 92-х ТераЁт, у кого их больше - запрашивайте дважды.
Кроме того, один адрес вмещает не более 3.8 ТераЁт.
Не используйте адрес повторно <для отправкит ёт>!
Это снижает безопасность с начальных 256-ти бит до, скажем, 64-х. Простой компьютер сможет взломать такой адрес за несколько дней.
Получать несколько платежей на один адрес можно.
После первой отправки ёт с этого адреса безопасность остаётся высокой.
Но как только вы повторно отправите ёты с того же адреса, безопасность резко падает.
Правило простое: если с адреса уже отправлялись ёты, больше на него не перечисляйте.
Если кто-то погорячится и всё же перечислит, срочно переведите ёты на другой свой адрес. Но все очередные поступления после этого 2-го перевода будут крайне уязвимы.
Также злоумышленник, анализирующий все новые транзакции, увидит что вы переводите с адреса второй раз, и пересоздаст транзакцию на свой адрес. Единственная надежда, что ваша транзакция подтвердится первой.
"Ностальгия". Для тех, у кого компьютеры как в 90-х, т.е. без NAT-а и файервола.
1. Скачать
последний JRE
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html 2. Скачать IRI
http://188.138.57.93/IRI-0.9.1.zip 3. Разархивировать IRI
4. В разархивированной папке отредактировать 'configuration.iri', удалив последнюю строчку редактировать и удалять нужно было только в версии 0.9.0, из-за недосмотра разработчика. 5. Открыть окно команд на разархивированной папке (правая кнопка на папке удерживая Shift -> 'Открыть окно команд')
6. Проверить версию Джава (
д.быть > 8u66): в окне команд ввести "java -version" (добавить JRE в системный путь если нужно)
7. В окне команд вести: "java -jar IRI.jar"
8. Открыть (даблклик) "nostalgia.html" в браузере
9. Ввести свой IPO-пароль в поле "Seed" и нажать Enter
10. Нажать кнопку [Claim IOTAs]
11. Нажать OK в первом всплывающем окне, ждать второе окно 'packet received', снова OK
12. Ждать 10 минут
13. Нажать кнопку [Refresh page] (НЕ браузерный F5)
14. Проверить ваши ёты в поле Total
15. Завершить IRI.jar по Ctrl+C в окне команд.
Если на 9-м шаге что-то пошло не так..
8.1 Открыть (даблкликом) "console.html" в браузере
8.2 Ввести команду {"command":"getNodeInfo"} (включая фигурные скобки)
8.3 Если в конце зелёного текста вы видите "tips":
[] - значит, ваш компьютер не из 90-х. Он либо за NAT-ом, либо за файерволом. Пробрасывайте 999 UDP порт, и goto 15, и снова на 7.
8.4 Если у вас есть VPS с сервером Ёты, можете в файле nostalgia.html заменить 'localhost' на его IP-адрес.
предыдущие версии:пре-бета версия Ёты - только серверная, графического интерфейса пользователя пока нет
скачать можно здесь:
https://s3-us-west-1.amazonaws.com/contattafiles/iota/GbdmGnYQJa5D516/IRI-0.8.0.zipклиентская часть есть в виде командной строки в окне
локально запущенного браузера
клиент написан на javascript и поставляется в виде файла console.html
ещё раз для тех кто не понял: клиента console.html нужно запускать
локально даблкликом из локальной папки на компьютере а не вызывать в браузере с ремоут сервера.
Почему появляются непонятливые - они путают локальный клиент Ёты с веб-клиентами
таких крипто-валют как NEM или NXT у которых веб-клиент вызывается с сервера.
По словам разработчика Ёта не применяет удаленный веб-клиент из соображений безопасности
поскольку сервер может быть взломан, удаленный веб-клиент на нем изменен и пароль Ёты перехвачен.Уже применяет.
Для запуска сервера нужно проинсталлировать Java 8 jre последней версии (старше u66),
распаковать поставочный архив ёты, заполнить файлы nodes.iri и configuration.iri
и выполнить команду java -jar IRI.jar
у сервера должен быть статический IP и должны быть открыты порты UDP 999 и TCP 999
в файле configuration.iri можно изменить iri.apiPassword - указать свой пароль на api запросы
но на период бета-тестирования лучше пока пароль не задавать.
В файл nodes.iri нужно построчно записать IP адреса нескольких других серверов Ёты,
но это чтобы получать/отправлять транзакции, если просто посмотреть консоль, то можно не записывать
узнавать эти адреса пока нужно личными запросами к другим ётоводам
и нигде не публиковать эти адреса, чтобы враги Ёты не заддосили молодую сеть
и еще чтобы даже молодая сеть получилась достаточно распределенная
особенно нужны ноды из южной америки, австралии и антарктиды.
После запуска сервера, например, на VPS/VDS, на него можно посылать команды
со своего
локального клиента, т.е. на своем компьютере нужно даблкликнуть console.html
затем можно написать help и получить список команд.
Из них самая важная -
setapi <url>она позволяет установить связь со своим удаленным сервером
формат команды такой -
setapi http://myIP_or_mydomain:999в ответ консоль напишет OK, но это ещё не значит что связь с сервером установлена
далее нужно направлять запросы в формате JSON:
https://ru.wikipedia.org/wiki/JSON простейший запрос - {} - ответом будет жёлтое
{"error": "Incorrect 'password'"}но это уже будет означать, что сервер работает. Можно узнать его состояние запросом:
{"password":"myPassswwwooorrrddd","command":"getNodeInfo"} - ответом будет зелёная строка типа
{"appName": "IRI", "appVersion": "0.6.1", "jreAvailableProcessors": 1, "jreFreeMemory": 8193632, "jreMaxMemory": 127729664, "jreTotalMemory": 28213248, "neighbors": 13, "seenTransactions": 310, "tips": 3, "unseenTransactions": 0}Как при помощи своего ёто-сервера пересылать
наноёты:
https://bitcointalk.org/index.php?topic=1216479.msg14241272#msg142412721. Используйте console.html 0.4.0 из
https://s3-us-west-1.amazonaws.com/contattafiles/iota/GbdmGnYQJa5D516/IRI-0.8.0.zip2. Введите
{"command": "getTransactionsToApprove"}3. Введите
{"command": "generateBundle", "outputs": [{"address": "XXX", "value": "123"}, {"address": "YYY", "value": "456"}], "inputs": ["key": "ZZZ", "value": "-579"], "messages":[], "signaturesSecurityLevel": 40, "approvedTransactions": [<result of the previous command>], "weight": 10}4. Через 5 минут после шага 3 введите
{"command": "broadcastTransactions", "trytes": [<result of the previous command>]}Обратите внимание, что 123 + 456 = 579, но 579 имеет знак "-" потому, что это "вход".
XXX замените адресом того, кому вы пересылаете 123
наноёты.
YYY замените другим вашим адресом (сдачи), который может быть сгенерирован при помощи
579 - это баланс на вашем генезисном адресе hash(ZZZ).
"signaturesSecurityLevel" в следующей версии будет заменено на "signaturesSecurity".
мануал по созданию своего VPS для ёты на AWS:
https://s3-us-west-1.amazonaws.com/contattafiles/iota/ycNCtiOwXRMtXM4/iota_noob.pdfмануал по запуску ётосервера на DigitalOcean:
https://knarz.github.io/notes/iota-node-do/
