Сложность! Действительно ли нам это нужно? | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Сложность! Действительно ли нам это нужно?

14 октября 2014, 3:56:54 PM	# 1
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: ~~Не волнует~~ Реальная картина зависит от сложности Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других.

Как заработать Биткоины?
Без вложений. Не майнинг.

14 октября 2014, 4:54:31 PM	# 2
btchris Сообщения: 672 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Получил 1806 Биткоинов Реальная история. Хэш это просто большое число (в данном контексте), нет необходимости делать что-то это сложный, если все, что вы после того, как изменяется хэш-целевой схемы к схеме точно-один-блок-за единицу времени. Просто сравните целые значения хэш-, и значение ближе к нулю, выигрывает. Тем не менее вы думаете, что это хорошая идея для сети Bitcoin затопить себя с одной или двух сто полностью решенных блоков каждые 10 минут? Как бы реализовать анти-DOS схему, чтобы предотвратить атакующим от наводнения сети с тысячами или миллионами решенных-с низким уровнем сложности блоков?

14 октября 2014, 5:36:09 PM	# 3
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Спасибо за ответ. Затопление с поддельными блоками или сделок, не зависит от формы хэша. Что мне мешает генерации 1000-х фальшивых блоков, начиная с нулями? Положив узел также количество битовых переходов замедляет желаемое поколение хэш и может помочь против ASICs монополии. Если хэш-это нормально, вместо того, чтобы идти прямо к проверке Merkle дерева вы также проверить количество переходов. [редактировать] Если подсчет битовых переходов проще, чем оценки хэш-то, как только у вас есть на самом деле «хорошо» правильный блок, он делает это быстрее падать поддельные блоки путем простого подсчета битовых переходов

14 октября 2014, 6:54:02 PM	# 4
btchris Сообщения: 672 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 5:36:09 PM Спасибо за ответ. Затопление с поддельными блоками или сделок, не зависит от формы хэша. Что мне мешает генерации 1000-х фальшивых блоков, начиная с нулями? Узел не отправляет недавно принятый блок (или, скорее, не уведомляет подключенные узлы, что он не имеет новый блок для отправки) до тех пор, после того, как он полностью проверил блок, в том числе целевого хэша, так что единственный способ затопить сеть с блоками, если вы можете создавать их (с текущим трудом). Как я понимаю, в вашем предложении, каждые Х минут, все узлы должны видеть все возможные блоки, прежде чем консенсус может быть достигнут, который, кажется, открыт для атак DoS. Цитата: qdoop от 14 октября 2014 года, 5:36:09 PM Положив узел также количество битовых переходов замедляет желаемое поколение хэш и может помочь против ASICs монополии. Добавление нового ограничения на целевой хэш приведет к замедлению генерации хэша, но у нас уже есть способ замедлить генерацию хеш: усложняют. Имейте в виду, что трудность не является подсчетом немного, это более мелкозернистая, чем это. Цитата: qdoop от 14 октября 2014 года, 5:36:09 PM [редактировать] Если подсчет битовых переходов проще, чем оценки хэш-то, как только у вас есть на самом деле «хорошо» правильный блок, он делает это быстрее падать поддельные блоки путем простого подсчета битовых переходов Боюсь, я не понимаю, что вы говорите здесь.

14 октября 2014, 7:49:43 PM	# 5
Rannasha Сообщения: 728 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Проблема здесь лежит "через определенные промежутки времени", Как вы убедитесь, что все шахтеры синхронизированы часы? И как вы будете иметь дело с сетевыми задержками, когда шахтер представляет свой блок, но это занимает много времени, чтобы пересечь сеть. Как долго ждать, другие узлы собирать хэши от шахтеров, прежде чем они определяют победителя? И как Вы поддерживаете, что все узлы принимают решение в то же время? В настоящее время система работает, потому что она не зависит от всех игроков, имеющих свои часы правильно синхронизированы и существуют четкие правила, устанавливающие, что происходит, когда, например, из-за плохого подключения к сети или какой-либо другой причине, существует несколько конкурирующих ветвей blockchain.

14 октября 2014, 8:12:29 PM	# 6
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Во-первых, я хочу, чтобы было ясно, что я с вами согласен, что подсчет размера доминирующие нули / целое число в хэш гораздо проще и быстрее. Точка A) Очевидно, что ты ничего получил, прежде чем дважды проверить его и сравнить его в случае блок хэша с вашим собственным лучшим результатом не вперед. Таким образом, скромный узел производительности может только затопить небольшие узлы производительности. Извините, если я не упомянул, что, но я знал об этой практике и не должен изменить его. Точка B) Да, вы можете установить минимальную трудность в обоих случаях, но только, чтобы установить минимальный уровень производительности, поэтому вам не придется много спама. Я do't рассмотреть проблему есть каждый узел проверить несколько блоков каждый раунд на самом деле может быть полезным для дырочной системы вместо тратить всю вычислительную мощность, чеканка лучший блок. Точка C) Каков максимальный диапазон возможных битовых переходов? 128 Легко ли создавать их? не так прямо Легко подсчитать их? да проще, чем генерации случайных один из них или вычисления хэш

14 октября 2014, 8:23:20 PM	# 7
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: Rannasha от 14 октября 2014 года, 7:49:43 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Проблема здесь лежит "через определенные промежутки времени", Как вы убедитесь, что все шахтеры синхронизированы часы? И как вы будете иметь дело с сетевыми задержками, когда шахтер представляет свой блок, но это занимает много времени, чтобы пересечь сеть. Как долго ждать, другие узлы собирать хэши от шахтеров, прежде чем они определяют победителя? И как Вы поддерживаете, что все узлы принимают решение в то же время? В настоящее время система работает, потому что она не зависит от всех игроков, имеющих свои часы правильно синхронизированы и существуют четкие правила, устанавливающие, что происходит, когда, например, из-за плохого подключения к сети или какой-либо другой причине, существует несколько конкурирующих ветвей blockchain. Я думаю, что есть свободное время обслуживание общедоступно на http://time.gov/ Многие вещи через Интернет зависит от него, так вы не можете закрыть его так легко Современные компьютерные часы дрейфовать всего несколько секунд в день. Таким образом, даже если служба идет вниз, как только синхронизироваться с ним узел может продолжать функционировать в течение нескольких часов или дней без проблем.

14 октября 2014, 8:29:49 PM	# 8
Rannasha Сообщения: 728 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 8:23:20 PM Цитата: Rannasha от 14 октября 2014 года, 7:49:43 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Проблема здесь лежит "через определенные промежутки времени", Как вы убедитесь, что все шахтеры синхронизированы часы? И как вы будете иметь дело с сетевыми задержками, когда шахтер представляет свой блок, но это занимает много времени, чтобы пересечь сеть. Как долго ждать, другие узлы собирать хэши от шахтеров, прежде чем они определяют победителя? И как Вы поддерживаете, что все узлы принимают решение в то же время? В настоящее время система работает, потому что она не зависит от всех игроков, имеющих свои часы правильно синхронизированы и существуют четкие правила, устанавливающие, что происходит, когда, например, из-за плохого подключения к сети или какой-либо другой причине, существует несколько конкурирующих ветвей blockchain. Я думаю, что есть свободное время обслуживание общедоступно на http://time.gov/ Многие вещи через Интернет зависит от него, так вы не можете закрыть его так легко Современные компьютерные часы дрейфовать всего несколько секунд в день. Таким образом, даже если служба идет вниз, как только синхронизироваться с ним узел может продолжать функционировать в течение нескольких часов или дней без проблем. А что, если кто-то добровольно не использует этот конкретный сервер NTP, для того, чтобы какое-то этап атаки или сорвать сеть? Или если кто-то по какой-то прирост причина контроля time.gov? Ваше решение требует доверия в центральный орган, который является противоположностью Bitcoin.

14 октября 2014, 8:56:03 PM	# 9
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Вы знаете теорему CAP. Говорит, что PARTITIONED система не может одновременно быть последовательны и ВЕРСИИ. Так Bitcoin сеть должна периодически применять некоторые правила для узлов, чтобы стать CONSISTENT как согласования общего времени. Иначе в конце концов, система всегда будет разделена на два с высокой степенью готовности, но не согласующимися деталей (блок цепи вилкой) Bitcoin просто отлично, но говорить о том, как улучшить его расслабляя некоторые требования в пользу более простого поведения (например, с помощью некоторых внешних ссылок времени широко доступны через Интернет) я думаю, всегда помогает. Например, есть постоянная дискуссия по повышению объема операций

14 октября 2014, 9:27:23 PM	# 10
cr1776 Сообщения: 1736 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 8:56:03 PM Вы знаете теорему CAP. Говорит, что PARTITIONED система не может одновременно быть последовательны и ВЕРСИИ. Так Bitcoin сеть должна периодически применять некоторые правила для узлов, чтобы стать CONSISTENT как согласования общего времени. Иначе в конце концов, система всегда будет разделена на два с высокой степенью готовности, но не согласующимися деталей (блок цепи вилкой) Bitcoin просто отлично, но говорить о том, чтобы улучшить его расслабляя некоторые требования в пользу более простого поведения (например, с помощью некоторых внешних ссылок времени широко доступны через Интернет) Я думаю, что всегда помогает. Например, есть постоянная дискуссия по повышению объема операций Я думаю, что многие не согласятся с предпосылкой утверждения, что с помощью центрального сервера является улучшение, будь то время или что-нибудь еще. Кроме того, наиболее нравится обсуждать хорошо продуманные предложения, которые могут быть использованы. Централизация открывает больше векторов атаки и является противоположностью дизайна протокола, поэтому я думаю, вы увидите большое сопротивление всему, что централизует вещи и многие люди не будут переключаться на вилку, которая включает в себя централизацию дизайна. 🙂

14 октября 2014, 9:31:19 PM	# 11
btchris Сообщения: 672 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 8:56:03 PM Bitcoin просто отлично, но говорить о том, как улучшить его расслабляя некоторые требования в пользу более простого поведения (например, с помощью некоторых внешних ссылок времени широко доступны через Интернет) я думаю, всегда помогает. Я не согласен с вами, но эта часть является предметом мнения. Я думаю, что Bitcoin должны стремиться быть максимально децентрализованной, насколько это возможно. Это не совсем децентрализована, но я не вижу причин, чтобы добавить дополнительные потенциальные точки отказа или точек контроля. Скорее всего, я бы предпочел наоборот - убрать то, что немногие оставшиеся централизованные пункты остались. Цитата: qdoop от 14 октября 2014 года, 8:12:29 PM Очевидно, что ты ничего получил, прежде чем дважды проверить его и сравнить его в случае блок хэша с вашим собственным лучшим результатом не вперед. Таким образом, скромный узел производительности может только затопить небольшие узлы производительности. Извините, если я не упомянул, что, но я знал об этой практике и не должен изменить его. Я подозреваю, что большинство узлов сети не шахтеры, и, следовательно, не имею ни малейшего понятия о лучшем блоке-так далеко-в-моем бассейн, и по-прежнему восприимчив к DoS. Цитата: qdoop от 14 октября 2014 года, 8:12:29 PM Каков максимальный диапазон возможных битовых переходов? 128 Легко ли создавать их? не так прямо Легко подсчитать их? да проще, чем генерации случайных один из них или вычисления хэш Я думаю, что вы только что описали военнопленную систему ... трудно создавать и легко проверить. Как это дополнение является любое ПР улучшение уже используется ПР?

14 октября 2014, 10:51:25 PM	# 12
deepceleron Сообщения: 1512 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. SHA256 хэш имеет длину 256 бит. 256 бит может представлять собой число в диапазоне от 0 -а также- 115792089237316195423570985008687907853269984665640564039457584007913129639935. Хэш произвольных данных возвращает хеш со значением в пределах этого интервала, казалось бы, случайным образом, с равномерным распределением. Сложность определяет, что пороговое значение меньшего количества требуется "выиграть", Что найденное значение хэш должно быть значительно меньше, чем максимум. Если мы делаем порог в 100 раз меньше, только один в 100 хэшей победит. Отправной точкой с Bitcoin на сложности 1 requres хэш-значение 4295032833,000015 меньше максимума, то есть только 1 в ~ 4,3 млрд хэшей встретится с трудностью 1 вызов. Фактическая разница между шагами может быть легко вычислен. Bitcoin кодирует трудности цель с почти шесть значащих цифр в шестнадцатеричном формате. Я не буду пытаться объяснить, как это на самом деле закодированы. Здесь мы покажем следующую возможную разность приращения после трудностью 1 трудность +1,000015259254738: >>> (0xFFFF * 2,0 ** 208) / (0xFFFE * 2,0 ** 208) +1,000015259254738 Текущая целевая трудность заключается в: 0x00000000000000001F6973000000000000000000000000000000000000000000 что трудности +35002482026,13323 Следующая возможная цель трудности инкремент 0x00000000000000001F6972000000000000000000000000000000000000000000 что трудности +35002499029,10224 Соотношение между этими двумя 1,0000004857646665, что достаточно точностью, что даже разница в одну секунды при измерении периода горна двухнедельный приведет к различной сложности.

14 октября 2014, 10:54:26 PM	# 13
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: cr1776 от 14 октября 2014 года, 9:27:23 PM Цитата: qdoop от 14 октября 2014 года, 8:56:03 PM Вы знаете теорему CAP. Говорит, что PARTITIONED система не может одновременно быть последовательны и ВЕРСИИ. Так Bitcoin сеть должна периодически применять некоторые правила для узлов, чтобы стать CONSISTENT как согласования общего времени. Иначе в конце концов, система всегда будет разделена на два с высокой степенью готовности, но не согласующимися деталей (блок цепи вилкой) Bitcoin просто отлично, но говорить о том, чтобы улучшить его расслабляя некоторые требования в пользу более простого поведения (например, с помощью некоторых внешних ссылок времени широко доступны через Интернет) Я думаю, что всегда помогает. Например, есть постоянная дискуссия по повышению объема операций Я думаю, что многие не согласятся с предпосылкой утверждения, что с помощью центрального сервера является улучшение, будь то время или что-нибудь еще. Кроме того, наиболее нравится обсуждать хорошо продуманные предложения, которые могут быть использованы. Централизация открывает больше векторов атаки и является противоположностью дизайна протокола, поэтому я думаю, вы увидите большое сопротивление всему, что централизует вещи и многие люди не будут переключаться на вилку, которая включает в себя централизацию дизайна. 🙂 Как обнаружить узлы доступны для подключения? С помощью некоторых стандартных местоположений хорошо известных узлы Это то же самое, возможно, более централизованы, чем пик времени из различных мест по всему интернету?

14 октября 2014, 11:22:39 PM	# 14
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: deepceleron 14 октября 2014, 10:51:25 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. SHA256 хэш имеет длину 256 бит. 256 бит может представлять собой число в диапазоне от 0 -а также- 115792089237316195423570985008687907853269984665640564039457584007913129639935. Хэш произвольных данных возвращает хеш со значением в пределах этого интервала, казалось бы, случайным образом, с равномерным распределением. Сложность определяет, что пороговое значение меньшего количества требуется "выиграть", Что найденное значение хэш должно быть значительно меньше, чем максимум. Если мы делаем порог в 100 раз меньше, только один в 100 хэшей победит. Отправной точкой с Bitcoin на сложности 1 requres хэш-значение 4295032833,000015 меньше максимума, то есть только 1 в ~ 4,3 млрд хэшей встретится с трудностью 1 вызов. Фактическая разница между шагами может быть легко вычислен. Bitcoin кодирует трудности цель с почти шесть значащих цифр в шестнадцатеричном формате. Я не буду пытаться объяснить, как это на самом деле закодированы. Здесь мы покажем следующую возможную разность приращения после трудностью 1 трудность +1,000015259254738: >>> (0xFFFF * 2,0 ** 208) / (0xFFFE * 2,0 208) +1,000015259254738 Текущая целевая трудность заключается в: 0x00000000000000001F6973000000000000000000000000000000000000000000 что трудности +35002482026,13323 Следующая возможная цель трудности инкремент 0x00000000000000001F6972000000000000000000000000000000000000000000 что трудности +35002499029,10224 Соотношение между этими двумя 1,0000004857646665, что достаточно точностью, что даже разница в одну секунды при измерении периода горна двухнедельный приведет к различной сложности. btchris** не находит каких-либо проблем с использованием числа начальных нулевых битов в качестве меры доказательства работы. Я Allready согласился с ним, что путем подсчета битовых переходов может быть сложным. Вот почему мы обратились за комментариями, потому что мы хотели, чтобы обнаружить последствия нашего подхода. Давайте предположим, кто-то находит случайно хэш-со многими переходами или начальными нулями. Как мы можем принять это во внимание? Есть возможности, что система может раскошелиться. Если в качестве простого правила требуют, чтобы ветвь с большинством переходов предпочтительнее тогда все узлы знают, что делать. Наконец да прошу большинство переходов может быть более убийство, но система будет работать нормально без каких-либо упоминаний на трудность, что это мое личное убеждение

14 октября 2014, 11:34:58 PM	# 15
PenAndPaper Сообщения: 252 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: deepceleron 14 октября 2014, 10:51:25 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. Эта. Кроме того, совет для тех, кто думает, что он может придумать лучше или принципиально иной или даже немного другой алгоритм ... ПР Изучают очень основы!

14 октября 2014, 11:46:26 PM	# 16
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: PenAndPaper 14 октября 2014, 11:34:58 PM Цитата: deepceleron 14 октября 2014, 10:51:25 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. Эта. Кроме того, совет для тех, кто думает, что он может придумать лучше или принципиально иной или даже немного другой алгоритм ... ПР Изучают очень основы! Спасибо за повторение вещей, которые я все готово знать. Если вы утверждаете, чем никогда не будете существовать лучший алгоритм военнопленных, то я могу гарантировать вам, что вы не правы PS. https://en.wikipedia.org/wiki/Hamming_distance

14 октября 2014, 11:54:43 PM	# 17
btchris Сообщения: 672 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop 14 октября 2014, 11:22:39 PM Цитата: qdoop 14 октября 2014, 11:22:39 PM ... btchris не находит каких-либо проблем с использованием числа начальных нулевых битов в качестве меры доказательства работы. ... Пожалуйста, не перефразировать то, что я сказал ... что я сказал "у нас уже есть способ замедлить генерацию хеш: увеличивает сложность. Имейте в виду, что трудности не подсчет битов [Курсив мой], это более мелкозернистая, чем это." Другими словами, я полностью согласен с deepceleron.

15 октября 2014, 12:14:29 AM	# 18
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: btchris 14 октября 2014, 11:54:43 PM Цитата: qdoop 14 октября 2014, 11:22:39 PM Цитата: qdoop 14 октября 2014, 11:22:39 PM ... btchris не находит каких-либо проблем с использованием числа начальных нулевых битов в качестве меры доказательства работы. ... Пожалуйста, не перефразировать то, что я сказал ... что я сказал "у нас уже есть способ замедлить генерацию хеш: увеличивает сложность. Имейте в виду, что трудности не подсчет битов [Курсив мой], это более мелкозернистая, чем это." Другими словами, я полностью согласен с deepceleron. Это ясно и спасибо за разъяснение! Бито переключение изменяет возможность с коэффициентом 2 (два раза меньше или его). Просто вопрос, если вы знаете наверняка. При расчете общей трудности цепи мы считаем значение фактических хешей или целей сложности в блоках?

15 октября 2014, 12:14:42 AM	# 19
PenAndPaper Сообщения: 252 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: qdoop 14 октября 2014, 11:46:26 PM Цитата: PenAndPaper 14 октября 2014, 11:34:58 PM Цитата: deepceleron 14 октября 2014, 10:51:25 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. Эта. Кроме того, совет для тех, кто думает, что он может придумать лучше или принципиально иной или даже немного другой алгоритм ... ПР Изучают очень основы! Спасибо за повторение вещей, которые я все готово знать. Если вы утверждаете, чем никогда не будете существовать лучший алгоритм военнопленных, то я могу гарантировать вам, что вы не правы PS. https://en.wikipedia.org/wiki/Hamming_distance Концепция чего-либо "лучший пау алгоритм" относительно. Некоторые могут возразить, что "трудно памяти" POW алгоритмы лучше для криптографических валют. Проблема заключается в том, что вы не понимаете, очень фундаментальное понятие, на вершине которых основаны алгоритмы военнопленный. И эта концепция не может быть лучше, потому что это так просто (и элегантный), как это добирается.

15 октября 2014, 12:24:58 AM	# 20
qdoop Сообщения: 123 Цитировать по имени цитировать ответ	Re: Уровень сложности! Действительно ли нам это нужно? Цитата: PenAndPaper 15 октября 2014, 12:14:42 AM Цитата: qdoop 14 октября 2014, 11:46:26 PM Цитата: PenAndPaper 14 октября 2014, 11:34:58 PM Цитата: deepceleron 14 октября 2014, 10:51:25 PM Цитата: qdoop от 14 октября 2014 года, 3:56:54 PM В настоящее время для блока-хэш принимается (доказательство работы) должно иметь такую форму XXX .... YYYYYYYYYYYYYYYYYYYYYYYYYYY ..... где Крестики: Нули Y-х: не заботится Сложность Цель требует по крайней мере, минимальному числу нулевых крестиков. Это требование не очень хорошо адаптироваться омрачить изменения мощности сети хеша и время, необходимое, чтобы найти хэш может значительно отличаться. Мы предлагаем иной алгоритм в качестве доказательства работы, адаптирует хорошо и работает без указания цели сложности. Вместо того, чтобы на Y не заботами мы считаем битовые изменения (от 0 до 1) переходов внутри них. Таким образом, мы заставляем блок хэш удовлетворять два противоречивых требования в связи с фиксированной битовой длиной хэша (256bits) Подсчет 0 до 1 переходов хэш может иметь при макс 128 что-то очень редкое. Учитывая два хэши с тем же числом переходов одной с наиболее крестиков, равным нулю побед. Я Exact, начиная с левого и сравнивая бит хэшей бит первый, имеющий 0, где другой хеш 1 выигрывает. (0 Доминантный бит) Как сеть развивается сознание? A) Все участвующие узлы пытаются максимизировать хэш 0 до 1 переходов B) В определенные промежутки времени узлы публикуют их лучше всего до сих пор С) Узел, принимающий два или более хешей всегда предпочитает один с большинством переходов, и если равна одной с наиболее доминирующими 0 бит. * Узел, который находит действительно редкий блок и публикует его на время радикально повышает безопасность сети. Это предварительная работа мы хотели бы ваши комментарии или предложить аналогичные работы от других. Это богатство ерунды, которая показывает полное отсутствие понимания того, как добыча полезных ископаемых, цель, трудности, или даже двоичным математике работы, которая затем вызывает в воображении несуществующие проблемы. Эта. Кроме того, совет для тех, кто думает, что он может придумать лучше или принципиально иной или даже немного другой алгоритм ... ПР Изучают очень основы! Спасибо за повторение вещей, которые я все готово знать. Если вы утверждаете, чем никогда не будете существовать лучший алгоритм военнопленных, то я могу гарантировать вам, что вы не правы PS. https://en.wikipedia.org/wiki/Hamming_distance Концепция чего-либо "лучший пау алгоритм" относительно. Некоторые могут возразить, что "трудно памяти" POW алгоритмы лучше для криптографических валют. Проблема заключается в том, что вы не понимаете, очень фундаментальное понятие, на вершине которых основаны алгоритмы военнопленный. И эта концепция не может быть лучше, потому что это так просто (и элегантный), как это добирается. Хорошо, я не понимаю, я должен признать, что. Просто вопрос, если вы знаете наверняка. При расчете общей трудности цепи мы считаем значение фактических хешей или целей сложности в блоках?

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW