Не обязательно генерировать на лету. Можно было сгенерировать заранее миллион (или сколько нужно) кошельков и перебирать и их.
Это обсуждалось, но решили что содержать этот миллион кошельков неудобно/криво, и лучше переложить работу на майнеров.
Topic: Нестыковочка в расчётах производительно (Read 1848 times)
Не обязательно генерировать на лету. Можно было сгенерировать заранее миллион (или сколько нужно) кошельков и перебирать и их.
Это обсуждалось, но решили что содержать этот миллион кошельков неудобно/криво, и лучше переложить работу на майнеров.
rPman, спасибо за объяснение!
Да и без этого можно было прожить: меняем кошелек - меняется сигнатура, транзакция, и, соответственно, merkle root. Можно снова задавать старые значения времени и перебирать nonce.
Правда из-за асиков пришлось бы много кошельков на лету генерировать и все это обсчитывать, а это сильно больше затрат выч. ресурсов чем текущая схема реализованная через мутацию транзакции в getworktemplate. Но ведь вполне можно было бы и без этого "костыля" обойтись.
Не обязательно генерировать на лету. Можно было сгенерировать заранее миллион (или сколько нужно) кошельков и перебирать и их. Правда из-за асиков пришлось бы много кошельков на лету генерировать и все это обсчитывать, а это сильно больше затрат выч. ресурсов чем текущая схема реализованная через мутацию транзакции в getworktemplate. Но ведь вполне можно было бы и без этого "костыля" обойтись.
Перебирается nonce,
Если все значения перебрали - обновляется время и снова перебирается nonce,
Через 60 секунд (минимум) обновляется транзакция - это значит что у нас новое значение merkle root.
Т.е. за 10 минут переберем 2,5 триллиона вариантов. Если нет транзакций в сети - то жоппа.Если все значения перебрали - обновляется время и снова перебирается nonce,
Через 60 секунд (минимум) обновляется транзакция - это значит что у нас новое значение merkle root.
Был предложен новый протокол - getworktemplate (уже давно работает, с 0.7 версии), который добавляет в первую транзакцию максимум 100-байтовое число extraNonce (2^800 значений) и майнеры уже перебирают и его... думаю из-за этого ограничения проблему слишком быстрого перебора все доступных значений можно еще долго не увидеть.
А ну вот и ответ. Все в порядке, значит.
При использовании старого протокола getwork перебирается nonce, и да, ограниченный размер числа порождает проблему его неэффективого использования для мощных майнеров. Если за время, пока перебирается все 2^32 значений не будет изменено задание (не изменится время, не изменится список транзакций,..) то майнер получит ту же саму работу и будет ее считать заново.
p.s. Кстати, в этом случае существует не нулевая вероятность, что решения на таком коротком интервале даже не может быть найдено (т.е. для определенных комбинаций транзакций и времени решения блока может вообще не существовать!), но эта проблема не заметна, так как текущий блок очень быстро меняется (появляются новые транзакции в течении секунды и быстрее).
Эта проблема сначала частично решалась перебором времени, но для слишком высоких мощностей
и этого недостаточно, так как время можно менять ограниченном интервале (считанные сотни секунд), т.е. проблема всплывала не при 4GH/s а при 1000GH/s.
Был предложен новый протокол - getworktemplate (уже давно работает, с 0.7 версии), который добавляет в первую транзакцию максимум 100-байтовое число extraNonce (2^800 значений) и майнеры уже перебирают и его... думаю из-за этого ограничения проблему слишком быстрого перебора все доступных значений можно еще долго не увидеть.
p.s. Кстати, в этом случае существует не нулевая вероятность, что решения на таком коротком интервале даже не может быть найдено (т.е. для определенных комбинаций транзакций и времени решения блока может вообще не существовать!), но эта проблема не заметна, так как текущий блок очень быстро меняется (появляются новые транзакции в течении секунды и быстрее).
Эта проблема сначала частично решалась перебором времени, но для слишком высоких мощностей
и этого недостаточно, так как время можно менять ограниченном интервале (считанные сотни секунд), т.е. проблема всплывала не при 4GH/s а при 1000GH/s.
Был предложен новый протокол - getworktemplate (уже давно работает, с 0.7 версии), который добавляет в первую транзакцию максимум 100-байтовое число extraNonce (2^800 значений) и майнеры уже перебирают и его... думаю из-за этого ограничения проблему слишком быстрого перебора все доступных значений можно еще долго не увидеть.
А вопрос ведь интересный! Действительно - кто не ленивый и посмотрел исходники? Что там перебирается?
Перебирать время? Это было бы совсем некорректно, полагаю. Время меняется, но согласно часам, а не перебором. У майнера конечно есть возможность изменить поле время в каких-то пределах, но перебирать его, это уж слишком. Поле время - важная характеристика при генерации блока, оно должно соответствовать своему назначению.
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
60 секунд задание не меняется, эти 60 сек можно перебирать.
Потом пул обновляет задание (уже с новыми транзакциями).
Перебирать время? Это было бы совсем некорректно, полагаю. Время меняется, но согласно часам, а не перебором. У майнера конечно есть возможность изменить поле время в каких-то пределах, но перебирать его, это уж слишком. Поле время - важная характеристика при генерации блока, оно должно соответствовать своему назначению.
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Есть ещё nonce в coinbase-транзакции, который тоже можно перебирать, насколько мне известно. Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Перебирать время? Это было бы совсем некорректно, полагаю. Время меняется, но согласно часам, а не перебором. У майнера конечно есть возможность изменить поле время в каких-то пределах, но перебирать его, это уж слишком. Поле время - важная характеристика при генерации блока, оно должно соответствовать своему назначению.
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Нет, идея наверное в том, что если перебрано 4 млрд. нонсов и решение блока всё ещё не найдено, то майнер может обновить поле времени и нонсы можно перебирать заново.
Перебирать время? Это было бы совсем некорректно, полагаю. Время меняется, но согласно часам, а не перебором. У майнера конечно есть возможность изменить поле время в каких-то пределах, но перебирать его, это уж слишком. Поле время - важная характеристика при генерации блока, оно должно соответствовать своему назначению.
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
Тогда уж предлагаю при майнинге перебирать сумму перевода в транзакциях и адрес получателя:-)
ну как минимум еще время
"Перебираем nonce" - упрощённая информация о сути процесса генерации. Естественно при этом не просто 32-битное число пребирается, а перебираются sha256-хэши заголовка структуры блока с заполненными полями, одним из которых является nonce. Кроме nonce туда ещё много чего входит...
Если нужны подробности - исходники открыты.
Если нужны подробности - исходники открыты.
А какие ещё поля меняются при переборе кроме nonce?
"Перебираем nonce" - упрощённая информация о сути процесса генерации. Естественно при этом не просто 32-битное число пребирается, а перебираются sha256-хэши заголовка структуры блока с заполненными полями, одним из которых является nonce. Кроме nonce туда ещё много чего входит...
Если нужны подробности - исходники открыты.
Если нужны подробности - исходники открыты.
К изучению исходников приступаю, я новичок и всё сразу не объять. Но дело не во мне. Во всех официальных и популярных источниках ни слова об этом - только перебираем НОНС и всё. Думаю это не правильно, информация выглядит искажённой, что для такого проекта несолидно. Вот, например, перерыл весь форум по теме - тоже самое - перебираем НОНС. Понимаю, что не всё так просто, вот и выясняю.
А что касается вопроса, думаю форум для того и существует, чтобы гуру просто и доходчиво рассказали новичкам, а дальше и в исходниках будет веселее в тонкости входить. Тема то интересная многим думаю.
А что касается вопроса, думаю форум для того и существует, чтобы гуру просто и доходчиво рассказали новичкам, а дальше и в исходниках будет веселее в тонкости входить. Тема то интересная многим думаю.
А самому открыть исходники и посмотреть не судьба?
Привет всем!
Сейчас частенько указывают производительность систем и оборудования в гигахэшах/сек и даже в терахэшах/сек. Т.е. значительные мощности. Для перебора всего NONCE в подписи блока требуется 2^32 вычислений SHA256, а значит при вычислитеьной мощности системы в 4.2 гигахэш/c весь NONCE можно будет перебрать за одну секунду. Нередко заявляют о наличии и более мощных систем, например в пулах. Получается, что на полный перебор требуется доли секунды, а откуда тогда берется сложность вычисления при таких мощностях? Почему тогда среднее время нахождения блока 10 минут?
Возможно, перебора только одного НОНСа недостаточно, идёт перебор еще каких-то входящих данных? Но об этом нигде ничего не говорят, наоборот, везде указывают, что происходит перебор именно NONCE, 32 бита, но это 4.2 гигахэша. Где же сложность, где proof-of-work?
Проясните ситуацию плиз, кто в курсе.
Спасибо.
Сейчас частенько указывают производительность систем и оборудования в гигахэшах/сек и даже в терахэшах/сек. Т.е. значительные мощности. Для перебора всего NONCE в подписи блока требуется 2^32 вычислений SHA256, а значит при вычислитеьной мощности системы в 4.2 гигахэш/c весь NONCE можно будет перебрать за одну секунду. Нередко заявляют о наличии и более мощных систем, например в пулах. Получается, что на полный перебор требуется доли секунды, а откуда тогда берется сложность вычисления при таких мощностях? Почему тогда среднее время нахождения блока 10 минут?
Возможно, перебора только одного НОНСа недостаточно, идёт перебор еще каких-то входящих данных? Но об этом нигде ничего не говорят, наоборот, везде указывают, что происходит перебор именно NONCE, 32 бита, но это 4.2 гигахэша. Где же сложность, где proof-of-work?
Проясните ситуацию плиз, кто в курсе.
Спасибо.
Jump to: