Topic: [ETH] Ethereum - мировой компьютер - page 711. (Read 1886096 times)

... и монеты майнить бесконечно

Ну сделали бы гибрид POS+POW, чтоб майнеров с экосистемы не выкидывать. Без POW такой суеты вокруг Эфира ИМХо не будет

Давайте закончим эту тему.
Есть много способов написать программу правильно.
К сожалению, есть значительно больше способов написать её неправильно.
Мы рассматривали конкретный пример - скачать страницу с сайта, распарсить её и выполнить определенное
действие. Я утверждаю, что для решения этой задачи не нужно слушать лекции и смотреть вебинары.
Надо сесть и сделать "как-нибудь". И если это "как-нибудь" будет говнокодом, будет работать только
с одним сайтом и только по пятницам - то это всё равно будет решением задачи.

Мы говорили о том, захочу ли я кого-то платно обучать и свалились на это унылое обсуждение
про регулярки. Я повторяю свою точку зрения - обучить вас я не смогу ни за деньги, ни бесплатно,
если вы сами не сделаете первые шаги.

В том то и дело, что разные там методики направлены на то, чтобы уменьшить влияние человеческого фактора.
Если программа кишит потоками с семафорами, то как бы вы не умели их готовить - баги либо в виде гонок, либо deadlockов, либо livelockow,либо starvation будут обязательно. Есть еще гонки высшего порядка, это когда отдельные ресурсы защищены, но не защищена совокупность ресурсов.

Очереди тоже имеют свои проблемы, но с ними багов меньше. Еще плюс асинхронного кода - баги быстрее вылазят наружу по статистике.

А я привык мозгами думать, а не слушать кого попало в интернете Никто же не предлагает регулярки в чистом виде для парсинга. Я сразу сказал, что сначала учим FSM, а потом уже регулярки. И эта связка отлично годится для парсигна HTML. Есть еще прикольная программа - ragel называется. Это компилятор FSM-ов, основан на регулярках. Им можно быстро и просто распарсить все, что хочешь

Тут дело не в кирпичиках. Да хоть и кипричики - regex или FSM - тоже кирпичики

и это тоже - человеку нужно найти библиотеку, которая умеет работать с http(S?). Или на браузер что-то навесить. А для этого уже каки-то знания нужны. Иначе ему придется вручную из браузера сохранять страницу и потом кормить ее своей проге

Ой, ну вот не надо пугать.
Как по приватному ключу вычислить публичный ключ я лично знаю весьма приблизительно.
И чем отличаются DSA от ECDSA понятия не имею. Ни в теории, ни в практике.
Это для меня уже готовые "кирпичи".
Архитектору небоскреба не обязательно знать как именно готовится бетон и арматура.
Он может взять уже готовые изделия.

Мы с чего начинали? Человек хотел как-то автоматизировать свой ручной труд, когда он
в браузере скачивает страницу, смотрит что на ней написано и в зависимости от этого
выполняет какие-то действия.

Если он хочет решить эту задачу
- ему не нужно изучать весь протокол HTTP
- ему не нужно знать как работают TCP, IP, DNS, NAT, PPPoE и прочая херня
- ему не нужно изучать регулярные выражения
- ему не нужно овер 9000 разных знаний.
- ему не нужны лекции платные и бесплатные

Ему нужно желание и знание основ какого-нибудь простого языка, турбо-паскаля например.

Это отдельная вещь, которую не стоит упускать из виду.
Блин. Ну как вы не понимаете? Надежность - это метрика. То есть число.
Вы решили, что надежность вашего "неважно чего" должна быть 99.99
И тут вдруг в мире происходят какие-то изменения. Вам следует определить -
изменения увеличили вашу надежность или уменьшили?

Блядь. Где вообще вы решили что прикладной задачей является
парсинг самого хэтэмэля и построение DOM-модели? Человеку, допустим,
надо найти на загруженной странице курс. Ему не надо для этого парсить
весь загруженный фрагмент. Но регулярка вида (я утрировано) /Курс: %d+/
подойдет чуть менее, чем всегда.

FSM полезная штука. А от регулярок я ничего кроме головной боли не получал. Ну есть в природе любители секса в гамаке, чё уж.

Такое ощущение, что вы с Амаклином рядом сидите и по очереди комментарии пишете... Я как-то привык, если написано "пальцы в розетку не совать" слушать умных людей и таки не совать. В случае сомнений, можно сходить в гугл и написать "что будет, если сунуть пальцы в розетку?" Я уж, так и быть, загуглил специально для вас:
"Entire HTML parsing is not possible with regular expressions, since it depends on matching the opening and the closing tag which is not possible with regexps.

Regular expressions can only match regular languages but HTML is a context-free language. The only thing you can do with regexps on HTML is heuristics but that will not work on every condition. It should be possible to present a HTML file that will be matched wrongly by any regular expression."

Там же есть время по-моему через которое сложность сети пересчитывается? Так что для того чтобы понимать отвалились майнеры или нет нужно постоянно мониторить сеть. А так зашел через неделю и ничего необычного не обнаружишь. Блоки через 10 мин как и прежде майнятся, а сложность в 2 раза упала.

Вы не любите кошек? Вы просто не умеете их готовить.
Никаких плохих последствий тут не бывает. Если один поток ждет когда другой
поток отпустит семафор, а второй поток его не отпускает - это проблема в вашем
коде, а не в том, что семафоры плохо работают.

Рандом мы учитывать не можем. На то он и рандом.
Значит если блоки идут быстрее - это следствие того, что к сети подключились еще
майнеры и сеть стала надежнее. А если блоки идут с большими задержками... Вывод
сами сделаете?

чем меньше времени между блоками, тем меньше времени для майнинга второй цкпочки. Там формулы наверное есть, но просто логически если у атакующего менее50% мощностей то за 2 часа словить 6+ подтверждений быстрее остальных выше вероятность чем за 15мин

Да, есть такое. Но очень много задач вообще без теории решить не получится, например DSP или криптография.

wait/notify, иными словами это обычный семафор - действительно через жопу. Применять то может он их умеет(а может и нет), но специально не использует, тк это приводит к плохим последствиям.
Синхронизацию между потоками надо делать на очередях(пусть сами очереди и будут внутри содержать те же wait/notify). А вообще надо по-меньше потоков использовать и привыкать писать асинхронный код, гы Там рулят только очереди.
Поток нужен там, где действительно нужно что-то параллельно или конвейерно вычислять.
Но ява она такая, иначе не умеет, вернее не она такая, а библиотеки такие.

Да, если учесть, что майнеры могут вернуться то да, ответ неправильный.
Но тут получается, что хешрейт - не показатель надежности. Вдруг есть еще один крупный незасвеченный майнер, у которого лежать асики на готове, и как только ему будет нужно - он их запустит и начнет даблспендить(пусть и с какой-то вероятностью)?
В битка вроде был скачек хешрейта когда-то давно, вроде тогда еще и на gpu не майнили

Тут что-то я не понял. Если рандом не учитывать, то если привалило за 15 минут, значит к сети подключились еще майнеры. А если 15 минут вышло из за рандома, то почему это безопаснее?
Можно как-то это в цифрах расписать, а то на пальцах я чет-то не могу вьехать?

В принципе, верно резюмировали. Да, я именно предлагал пойти первым путем.
Неважно какое решение. Если задача решена, а вы не знаете, что для её решения
есть более простые пути - ваше решение не будет являться для вас лично "решением через жопу".
Потому что (повторюсь) другого решения вы не знаете.

На втором способе вы рискуете "застрять в теории". У меня есть знакомый, который не
проходит мимо любой новинки в программировании и любую библиотеку о которой
есть положительные отзывы пытается присобачить к нашему рабочему проекту,
потому что "так теперь модно". С другой стороны обычная синхронизация двух потоков
на жаве с помощью wait ( ) + notify ( ) вызывает у него испуг и панику - он считает
этот метод "через жопу" и отказывается его понимать. То есть в теории он знает,
а на практике применить не может.

Неправильный ответ.
Вообще говоря, если исключить рандомную составляющую, выходит, что увеличение
интервала между блоками может произойти только в случае уменьшения мощности сети
относительно какого-то локального экстремума. То есть сеть стала менее надежной
в плане иммутабельности. И следует ждать больше подтверждений. Не шесть, а семь.

Сингулярность получается в случае падения хэшрейта вдвое.
То есть если в биткойн-сети блоки идут с интервалом 20 минут вместо 10 - значит
отвалилась половина мощностей. То есть, вас не спасет в общем случае ни 12, ни 18
подтверждений для заданной гарантии от даблспенда. Потому что вы не знаете -
эта отвалившаяся половина мощностей просто выключена или майнит альтернативную
цепочку.

Разумеется, на коротких интервалах все сильно зависит от рандома. Но выводы,
грубо говоря, те же самые. Вам прислали транзакцию, вы решили ждать 6 подтверждений,
но пять подтверждений пришли за 15 минут. Можете 6-го не ждать.

Ну это переходной процесс. В сети же ООС заведена, все равно блоки должны идти раз в 10 минут.

По идеи тоже 6, тк переходной процесс, работы на нахождения 6 блоков потратится столько же.

Ну есть 2 варианта научиться:
1. Который предлагаете вы - взять конкретную задачу и не имея знаний попытаться решить ее через жопу
2. Который предлагаю я - сначала выучить теорию, а потом решать задачу, применяя уже кем-то ранее придуманную теорию.

Я предпочитаю второй вариант. Но первый тоже имеет право на существование.

Здесь о другом. Рассматриваем одну сеть, но в разные периоды. Биткойн или кефир, или любой говнофорк.
Фиксируем какую-то надежность. Допустим, хотим чтобы вероятность даблспенда была бы 0.00001%
Зафиксировали. Теперь посчитаем сколько надо подтверждений. Посчитали - выяснили,
что нам надо ждать 6 подтверждений.

Прошло два месяца...
Сеть работает с другим хэшрейтом, блоки идут не раз в 10 минут, а раз в 15 минут.
Мы по-прежнему хотим вероятность даблспенда не более 0.00001%
Внимание, вопрос: нам больше 6 подтверждений теперь ждать или меньше? Насколько?

Ого, а я то дурак наоборот думал
В кефире блок идет раз в 15 сек примерно, значит достаточно подождать 1го подтверждения, а можно вообще не ждать  

Это не значит, что вы освоили FSM и регулярки (но и не значит, что не освоили)

Можно по-подробнее, на примере? А то та хуета, на которую вы дали ссылку не содержит ни одного толкового примера.

да вот новость пролетала в форклоге:



Ожидаемый Ethereum-сообществом переход на Proof-of-Stake в 2017 году может не состояться. По словам специального корреспондента ForkLog Андрея Великого, такое предположение основатель Ethereum Виталик Бутерин высказал в кулуарах в конференции Event Horizon 2017 в Вене.

http://forklog.com/perehod-ethereum-na-proof-of-stake-v-2017-godu-mozhet-ne-sostoyatsya/

говорят не успевают они в этом году на пос перейти, до конца лета мб появится более точная инфа.

Что там слышно о грядущем переходе на POS, есть какие то новости, актуально ли еще?
Просто думаю стоит ли закупаться или еще подождать, кто что подскажет?