Объединенный / Remote Mining - Open Source - Обновлено 2010-12-24 | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Объединенный / Remote Mining — Open Source — Обновлено 2010-12-24

13 октября 2010, 11:27:32 PM	# 1
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Из-за малую вероятность того, что отдельный шахтер процессор будет найти блок в разумном количестве времени, и ожидание от новых пользователей, чтобы увидеть результаты быстро, я разработал сервер / клиент для Bitcoin, что позволит многим отдельным шахтерам сотрудничать на решения блоков. Это позволит эффективно агрегировать их скорость хэширования, позволяет решать блоки быстрее, чем по отдельности возможно, и распространять сгенерированные биткойно, взвешенный по скорости хэширования, способствующий узла. Это также может быть использован человеком, который не хочет работать полный клиент Bitcoin на компьютере, но все-таки хотелось бы, чтобы генерировать блоки с ним. Вот основной обзор того, как он в настоящее время работает. Кто-то работает Bitcoin в качестве сервера, с возможностью подключения пароля, чтобы принимать соединение от удаленных клиентов. Сервер создает уникальный блок на одного клиента, сохраняет его в памяти, и отправляет его клиенту в хэш. Затем клиент хешей блок, добавляет первый байт сгенерированного хэша в буфер, и создает metahash буфера, когда он заполнен, и посылает его на сервер для последующей проверки. Клиент увеличивает одноразовый номер блока после каждого хеша, но не изменяет блок временной метки. Сервер будет периодически отправлять новые блоки для клиента, чтобы хеш, либо через каждые 2 минут, или когда клиент запрашивает новый блок, так как Nonce близка к переполнению. Каждые 10 секунд, сервер выбирает клиент с старейшими верифицированными metahashes и проверяет последнюю metahash от этого клиента. Сервер будет также отправлять обновление статуса для каждого клиента каждые 10 секунд. В настоящее время существует абсолютно никакого встроенные негативных последствия для клиента отправки ошибочных данных, кроме не отключаясь для отправки искаженных пакетов. Журнал отладки будет содержать информацию о узлов, хотя плохое поведение. Однако на этой ранней стадии развития, она может быть ошибки, вызывающие проблемы, а не злонамеренных клиентов, так что это должно быть принято во внимание. Некоторые вещи, чтобы рассмотреть следующие вопросы: Сформированные монеты распределяются либо на основе хаш в вносящих вклад клиента / с делится на все узлы Хаш / с, или с помощью каждого из клиентов всего хешей способствовали разделенное на всех хешей вклад. Это означает, что сгенерированные монеты будут иметь Прецизионную весь путь вплоть до самого маленький десятичный Bitcoin позволяет. Из-за округления вопросы наследования с операций с плавающей точкой, сервер будет израсходовать все оставшиеся дробных монет, которые почти всегда один значное число в наименьшей позиции десятичной. Из-за активности metahashing и сетей, шахтеры не будут столь же быстро, как шахтеры строго посвященными блокировать хэширование. Сформированные блоки могут поразить максимальный размер блока, если подключены достаточно клиентов. Я не смотрел на это глубоко, чтобы увидеть, что предел, но точно знаю, что это может быть возможным, чтобы достичь этого предела. Поставленные удаленные клиенты просто доказательство концепции. Клиент может быть создан на любом языке, который способен обрабатывать подключения к сокету, и с помощью JSON, а также использовать любые средства генерирования блоков, доступные для него, таких как GPU. Биткойн двоичный могут иметь проблемы отображения и / или с использованием монет, сгенерированные, которые меньше 0,01 BTC. Я предполагаю, что они не будут отображаться в клиенте вообще. Я тщательно не проверял это. Вполне возможно, что сервер будет нуждаться в большой пропускной способности, если подключены многие клиенты Параметры командной строки Bitcoin сервера -удаленный сервер Включение удаленного сервера -remotebindaddr = х.х.х.х Bind сервер конкретного адаптера. По умолчанию 127.0.0.1. Обратите внимание, что это будет принимать соединения только с локального компьютера. -remotebindport = ххххх Привязка сервера к определенному порту. Значение по умолчанию 8335. -remotepassword = ххххх Установите пароль для доступа к серверу. Значение по умолчанию является пустым паролем. -distributiontype = подключен \| вклад Устанавливает метод, используемый для распределения Bitcoins. "связанный" будет распределять монеты только для тех клиентов, которые были связаны, когда блок решаемой был создан. Распределение основано на каждых подсоединенных клиент Рассчитанных скоростей хэша от общей скорости хеширования в то время создаются новый блок. "способствовали" будут начисляться все хеши посылаются на сервер для данного адреса с момента последнего сгенерированного блока. Клиент может свободно переподключить и будет продолжать накапливать хэши к любому адресу, указанному клиентом. Распределение монет с помощью этого метода основано на хэш начисленных по каждому адресу, с общими хэш заказа составляет все. Сервер будет сохранять значения, когда он выключается, и загрузить их резервные копии на старте. -resethashescontributed Сброс счетчика хэш вклада от каждого адреса. Клиентские параметры командной строки -Сервер = х.х.х.х Адрес сервера для подключения. По умолчанию 127.0.0.1. -Порт = ххххх Порт сервера. Значение по умолчанию 8335. -пароль = ххххх Пароль при подключении к серверу. Значение по умолчанию является пустым паролем. -Адрес = XXXXXXX Bitcoin адрес, который вы хотите генерироваться монеты отправлены. Значение по умолчанию является пустым. Пустой адрес сделает долю клиента генерируемых монет хранятся на сервере. -нити = х Запустить количество шахтерских потоков. Значение по умолчанию равно количеству ядер на вашем процессоре при использовании шахтера процессора, или 1 при использовании GPU шахтера. Существует одна проблема, которую я не смог решить. Функции хэширования, кажется, сломана в релиз сборки в Microsoft Visual Studio. В частности, Midstate буфер содержит фиктивный Midstate при отправке клиенту. Я проверил по вопросам буфера, а также вопросы инициализации, но я не вижу ни одного. При размещении ошибки проверки коды и протоколирования ПОСЛЕ хэширования происходит, результаты вышли правильно. Удаление проверки кода вызывает проблемы вновь появиться и Midstate быть ошибочным. Пойди разберись. Во всяком случае отладка строит не показывает эту проблему. Там, вероятно, это ошибка где-то, так что, может быть, кто-то может заметить это. Загрузки (Обновлено 2010-12-24) Pooled Miner Server / Client источник на основе SVN 205 Окна Бинарники Смотрите следующую нить для получения подробной информации о подключении шахтера к серверу управляет doublec Регистрация объединенного горнодобывающего усилия Bitcoin

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

14 октября 2010, 1:53:03 AM	# 2
Сообщения: Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Получил 1806 Биткоинов Реальная история. Я хочу ботнет армии muwahahahah !! У меня есть сервер сбора пыли, если вы хотите, чтобы установить это Дэйв. У Вас есть еще детали IRC-канал я послал вас?

14 октября 2010, 2:03:14 AM	# 3
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: davidonpda 13 октября 2010, 11:56:13 PM Вы удивительные тоже. Нет Доля отправляется вам не там? Если вы не внести свой вклад, конечно, ха-ха. Нет, нет коды там, чтобы послать что-нибудь кому-либо, кроме удаленных клиентов и оставшиеся монет из-за ошибки округления к оператору сервера. котировка Итак, как же определить, сколько кто вносит свой вклад? Я предполагаю, что вы отправить эту информацию, но так как он является открытым исходным кодом, что мешает им принимать это число и * 10? Он основан на скорости, что они посылают свои metahashes обратно на сервер в течение предыдущих 60 секунд. Поскольку сервер проверяет, что metahashes правильны периодически, вы можете быть уверены, что этот показатель является хорошей оценкой скорости хэш клиента. котировка По умолчанию Bitcoin клиента не будет показывать монеты меньше, чем 0,01, но вы не должны посылать монеты меньше, чем потому, что вы будете платить за операцию 0,01. Вы должны округлить все от 0,01. Так как создатель блока определяет платы не имело бы смысл включать плату за наши собственные блоки. Распределение Bitcoins фактически включаются в выходной сгенерированного блока, так что каждый получает свою долю, как только блок генерируется и не требуется никаких сборов. Цитата: davidonpda 14 октября 2010, 12:05:34 AM Код: Const int64 RemoteClientConnection :: GetCalculatedKHashRate (Const ИНТ сек) сопзЬ { Int64 хэш = 0; Int64 DENOM = (сек * 1000); time_t Теперь = время (0); для (станд :: вектор:: const_iterator я = m_sentwork.begin (); ! Я = m_sentwork.end (); я ++) { для (станд :: вектор:: const_iterator J = (* я) .m_metahashes.begin (); ! J = (* я) .m_metahashes.end (); j ++) { если (difftime (сейчас, (* J) .m_senttime)<= Сек) { хэш + = BITCOINMINERREMOTE_HASHESPERMETA; } } } возвращать хэш / DENOM; } Измените последнюю строку на: обратный хэш; и я просто увеличил свою долю пирога? Это влияет только на вычисление на сервере, и все будет по-прежнему в конечном итоге с тем же отношением их хаш над общей хаш. Все клиент может сделать, чтобы повлиять на этот расчет, посылают действительные metahashes как можно быстрее. Если они пошлют недопустимые они будут обнаружены. Если они посылают дубликаты из них, они игнорируются.

14 октября 2010, 10:03:38 AM	# 4
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Я бы подумал, что лучший способ, чем metahash обеспечить честность, чтобы получить удаленные шахтеры отправить обратно подлинные хэшей на более низком уровне сложности. Поскольку существует известная связь между простотой генерации хэшей на разных уровнях сложности, вы можете быть уверены, что удаленный шахтер представление регулярных хэшей на более низких уровнях сложности делает свою долю работы по нахождению хэшей на официальном уровне сложности ,

14 октября 2010, 11:26:23 AM	# 5
tcatm Сообщения: 337 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Можно даже рассчитать клиентам истинное hashrate от результатов низкого сложности.

14 октября 2010, 12:01:40 PM	# 6
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: tcatm 14 октября 2010, 11:26:23 AM Можно даже рассчитать клиентам истинное hashrate от результатов низкого сложности. Если вы сделали это, то клиент будет тогда только послать низкую трудность хэш как можно быстрее. Там не будет никакого стимула для хеширования фактического блока пытается решить. Для того, чтобы убедиться, что клиент хэширования, что он должен и знать, как быстро клиент хэширования, то metahashes должны быть выведены из фактического блока клиент пытается решить. Там могут быть и другие способы сделать это, но я думаю, что это самый простой и удобный.

14 октября 2010, 12:22:29 PM	# 7
tcatm Сообщения: 337 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: puddinpop 14 октября 2010, 12:01:40 PM Если вы сделали это, то клиент будет тогда только послать низкую трудность хэш как можно быстрее. Там не будет никакого стимула для хеширования фактического блока пытается решить. Для того, чтобы убедиться, что клиент хэширования, что он должен и знать, как быстро клиент хэширования, то metahashes должны быть выведены из фактического блока клиент пытается решить. Там могут быть и другие способы сделать это, но я думаю, что это самый простой и удобный. Вычислив низкую сложность хешей для блока он будет в конечном итоге вычислить целевую сложность хэш. Почему он не должен представить его? Это сделает его выиграть монеты.

14 октября 2010, 12:42:16 PM	# 8
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: tcatm 14 октября 2010, 12:22:29 PM Цитата: puddinpop 14 октября 2010, 12:01:40 PM Если вы сделали это, то клиент будет тогда только послать низкую трудность хэш как можно быстрее. Там не будет никакого стимула для хеширования фактического блока пытается решить. Для того, чтобы убедиться, что клиент хэширования, что он должен и знать, как быстро клиент хэширования, то metahashes должны быть выведены из фактического блока клиент пытается решить. Там могут быть и другие способы сделать это, но я думаю, что это самый простой и удобный. Вычислив низкую сложность хешей для блока он будет в конечном итоге вычислить целевую сложность хэш. Почему он не должен представить его? Это сделает его выиграть монеты. Я понимаю, что вы имеете в виду прямо сейчас. Отправка хэши для целевого блока, которые являются низкой сложностью. Ну, что может работать, но я вижу 2 вопроса сразу. Во-первых, эти хэши могут или не могут быть получены в обычном порядке, и есть даже не гарантия клиент будет производить один. Расчетная скорость хэша на основе этой метрики должна быть взята из большого размера образца. Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение.

14 октября 2010, 1:14:26 PM	# 9
tcatm Сообщения: 337 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Мне было любопытно, и читать источник. Ваш metahash подход не использует отдельный блок, как я сначала подумал, и это на самом деле очень похоже на мою идею. Может быть, вы можете избавиться от массива и просто просуммировать все предыдущие хэш для экономии памяти. Это может лучше работать с графическими процессорами с небольшим объемом памяти (2 ^ 32 пытались metahashes являются ~ 17 Гбайта).

14 октября 2010, 1:49:06 PM	# 10
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: puddinpop 14 октября 2010, 12:42:16 PM Я понимаю, что вы имеете в виду прямо сейчас. Отправка хэши для целевого блока, которые являются низкой сложностью. Ну, что может работать, но я вижу 2 вопроса сразу. Во-первых, эти хэши могут или не могут быть получены в обычном порядке, и есть даже не гарантия клиент будет производить один. Расчетная скорость хэша на основе этой метрики должна быть взята из большого размера образца. Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение. Я уверен, вы бы получить хорошее приближение к скорости хеширования, если клиенты представили свой лучший (высокий уровень сложности) хэш каждые N минут. В течение нескольких часов в среднем все эти лучшие хешей должна быть пропорциональна скорости хеш-клиента (если клиент не были как-то раз очень повезло или не повезло, но это было бы крайне маловероятно).

14 октября 2010, 4:27:11 PM	# 11
jimbobway Сообщения: 1398 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Это удивительное, я надеюсь стать зомби в ботнет сервер в ближайшее время (так как я не думаю, что у меня есть аппаратное обеспечение и пропускная способность для поддержки супер-сервера).

14 октября 2010, 6:36:47 PM	# 12
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: puddinpop от 14 октября 2010 года, 2:03:14 AM Распределение Bitcoins фактически включаются в выходной сгенерированного блока, так что каждый получает свою долю, как только блок генерируется и не требуется никаких сборов. Так что, чтобы уточнить, вы говорите, что монеты, созданные в результате генерации блока могут быть потрачены в сделках, включенных в том же блоке. Не новый блок будет отклонен, поскольку coinbase не созрели? См ConnectInputs. Отсутствие платы, если гарантия плата также может быть проблемой, так как ConnectInputs проверяет, что тоже. ByteCoin

14 октября 2010, 6:41:00 PM	# 13
марсианский Сообщения: 7 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Это, безусловно, огромная. Интересно, если средний бизнес будет работать что-то вроде этого на их корпоративной сети сразу Bitcoin взлетает. Если предположить, что это стоит расходов на электроэнергию, имеющие ресурсы компании получать доход во время простоя может быть очень привлекательным. Конечно, компании, как правило, имеют ужасные ПК, но величина имеет качество все свои собственные. 😉 Одна вещь, немного волнуясь, хотя. Если, скажем, был очень большой глобальный складочный горно-сервер с большинством мощности процессора, не было бы в состоянии производить двойные блоки расходов?

14 октября 2010, 10:34:25 PM	# 14
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: tcatm от 14 октября 2010 года, 1:14:26 PM Мне было любопытно, и читать источник. Ваш metahash подход не использует отдельный блок, как я сначала подумал, и это на самом деле очень похоже на мою идею. Может быть, вы можете избавиться от массива и просто просуммировать все предыдущие хэш для экономии памяти. Это может лучше работать с графическими процессорами с небольшим объемом памяти (2 ^ 32 пытались metahashes являются ~ 17 Гбайта). Это только один байт результирующего хэша, так что 4GiB 2 ^ 32 хешей, что современная карта может передавать в основную память быстрее, чем хэш может быть вычислена. Память на карте не будет учитывать в нем все равно, как вы просто отправить результаты обратно в небольших блоках. Цитата: Гэвин Андресен 14 октября 2010 года, 1:49:06 PM Цитата: puddinpop 14 октября 2010, 12:42:16 PM Я понимаю, что вы имеете в виду прямо сейчас. Отправка хэши для целевого блока, которые являются низкой сложностью. Ну, что может работать, но я вижу 2 вопроса сразу. Во-первых, эти хэши могут или не могут быть получены в обычном порядке, и есть даже не гарантия клиент будет производить один. Расчетная скорость хэша на основе этой метрики должна быть взята из большого размера образца. Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение. Я уверен, вы бы получить хорошее приближение к скорости хеширования, если клиенты представили свой лучший (высокий уровень сложности) хэш каждые N минут. В течение нескольких часов в среднем все эти лучшие хешей должна быть пропорциональна скорости хеш-клиента (если клиент не были как-то раз очень повезло или не повезло, но это было бы крайне маловероятно). Что остановить клиента от лжи? Они просто генерировать несколько хэшей просто послать и сказать серверу, "Это лучшие хэши я придумал, честно." На самом деле клиент тратит остальную часть времени, пытаясь сформировать свой собственный блок. Там нет абсолютно никакого способа проверить, что клиент не лежит таким образом. С metahash подходом, вы можете проверить каждый индивидуальный хэш клиент сообщила решению. Если они лгут, даже около 1 из этих хэшей, вы будете знать, потому что metahash не совпадает. Цитата: ByteCoin от 14 октября 2010 года, 6:36:47 PM Цитата: puddinpop от 14 октября 2010 года, 2:03:14 AM Распределение Bitcoins фактически включаются в выходной сгенерированного блока, так что каждый получает свою долю, как только блок генерируется и не требуется никаких сборов. Так что, чтобы уточнить, вы говорите, что монеты, созданные в результате генерации блока могут быть потрачены в сделках, включенных в том же блоке. Не новый блок будет отклонен, поскольку coinbase не созрели? См ConnectInputs. Отсутствие платы, если гарантия плата также может быть проблемой, так как ConnectInputs проверяет, что тоже. ByteCoin Сервер создает блок, который, очевидно, не включает в себя операции, использующие монеты, которые генерируются этим же блок, в основном, потому что нет никаких операций, полученных из блока, так как никто не знает о блоке еще кроме сервера.

14 октября 2010, 11:34:58 PM	# 15
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Ваш "metahash" метод измерения работы, хотя и более точным, чем probablisitic методов Гэвин Андресен и tcatm, является основным недостатком вашего метода. Для того, чтобы проверить часть работы клиента, вы должны дублировать его. Это не будет масштабироваться хорошо, даже десятки клиентов. Атакующий представления плохих metahashes заработать монеты на самом деле не делать работу просто закрыли, когда узнали, и начать новый клиент на новый IP. Вы должны исключать новых клиентов до тех пор, некоторая часть их результатов не были проверены, а затем становится вероятность игры, где нападавшие только фальсифицировать возможно все большую часть своих результатов. Более серьезно, вы исключаете клиентов (и серверы), которые не являются 100% надежной. Я знаю, что из Мерсенна тестирования, что некоторые компьютеры иногда производят плохие результаты. Вы можете запустить нормальное программное обеспечение в течение многих лет, не замечая частоту ошибок одной ошибки каждого 2 ^ 40 опса, но ваш metahash будет очень чувствителен к таким ошибкам. Это приведет людей, работающих подлинных клиентов на несколько несовершенных машин раздражаться. Обратите внимание, что эти несовершенные машины хороши для нормальной генерации хэша или вычисления скорости хеша-вероятностного. Вы, кажется, думают, что вероятностная схема измерения скорости хешировании недостаточно точна. При желании вы можете сделать некоторые расчеты, чтобы убедить себя иначе. Там уже много неизбежной нечестной случайность в размере вычислений, необходимый для создания нового блока. Цитата: puddinpop 14 октября 2010, 12:42:16 PM Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение. А? Это происходит в любом случае! Как еще можно сказать, если у вас есть выигрышная хэш? Цитата: puddinpop 14 октября 2010, 12:42:16 PM Что остановить клиента от лжи? Они просто генерировать несколько хэшей просто послать и сказать серверу, "Это лучшие хэши я придумал, честно." Ничего. Но тогда выведенный скорость хеширования является очень низким. Для того, чтобы уточнить - скорость хэш рассчитывается исходя из качества и / или количества хешей и ничего другого. Клиент не говорит, что это будет сделано определенное количество работы - только хэш значения. Цитата: puddinpop 14 октября 2010, 10:34:25 PM Сервер создает блок, который, очевидно, не включает в себя операции, использующие монеты, которые генерируются этим же блок, в основном, потому что нет никаких операций, полученных из блока, так как никто не знает о блоке еще кроме сервера. Ах. Я думал, что ты и я думал по тем же линиям элегантного способа оплаты, который не требует никакого доверия и не может быть мошенническим, который, к сожалению, запрещено довольно несущественным и безвкусным правилом Bitcoin. Вы должны войти в более подробно о том, как работает оплата. Решения я могу думать требуют, чтобы клиент доверять серверу и / или может быть мошенническим. ByteCoin

15 октября 2010, 2:42:31 AM	# 16
puddinpop Сообщения: 103 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: ByteCoin 14 октября 2010, 11:34:58 PM Ваш "metahash" метод измерения работы, хотя и более точным, чем probablisitic методов Гэвин Андресен и tcatm, является основным недостатком вашего метода. Для того, чтобы проверить часть работы клиента, вы должны дублировать его. Это не будет масштабироваться хорошо, даже десятки клиентов. Атакующий представления плохих metahashes заработать монеты на самом деле не делать работу просто закрыли, когда узнали, и начать новый клиент на новый IP. Вы должны исключать новых клиентов до тех пор, некоторая часть их результатов не были проверены, а затем становится вероятность игры, где нападавшие только фальсифицировать возможно все большую часть своих результатов. Очевидно, что вы не вычислять каждый metahash, посланный клиентами. Вы хэширование их периодически, и когда ошибочные один найдено, или у вас есть подозрительный клиент, вы проверяете их больше. котировка Более серьезно, вы исключаете клиентов (и серверы), которые не являются 100% надежной. Я знаю, что из Мерсенна тестирования, что некоторые компьютеры иногда производят плохие результаты. Вы можете запустить нормальное программное обеспечение в течение многих лет, не замечая частоту ошибок одной ошибки каждого 2 ^ 40 опса, но ваш metahash будет очень чувствителен к таким ошибкам. Это приведет людей, работающих подлинных клиентов на несколько несовершенных машин раздражаться. Обратите внимание, что эти несовершенные машины хороши для нормальной генерации хэша или вычисления скорости хеша-вероятностного. Ошибочные результаты бы быть фактором для любого метода проверки клиента. Решение состоит в том, чтобы обеспечить определенное количество ошибок. котировка Вы, кажется, думают, что вероятностная схема измерения скорости хешировании недостаточно точна. При желании вы можете сделать некоторые расчеты, чтобы убедить себя иначе. Там уже много неизбежной нечестной случайность в размере вычислений, необходимый для создания нового блока. В самом деле, есть много случайности участвуют, в результате чего скорость генерации блока, чтобы изменяться в широких пределах. Сглаживание Заявленный уровень хэш-клиента из потребует усреднением неприемлемого длительного периода времени. Это несправедливо наказывает клиентов, которые хотят хэширования в течение коротких периодов времени, требует сложных вычислений логики, и результаты в лучшем случае в грубых оценках. котировка Цитата: puddinpop 14 октября 2010, 12:42:16 PM Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение. А? Это происходит в любом случае! Как еще можно сказать, если у вас есть выигрышная хэш? Вы сравниваете 1 байт хэш и только если этот байт 0 Вы полностью проверить хэш. котировка Цитата: puddinpop 14 октября 2010, 12:42:16 PM Что остановить клиента от лжи? Они просто генерировать несколько хэшей просто послать и сказать серверу, "Это лучшие хэши я придумал, честно." Ничего. Но тогда выведенный скорость хеширования является очень низким. Для того, чтобы уточнить - скорость хэш рассчитывается исходя из качества и / или количества хешей и ничего другого. Клиент не говорит, что это будет сделано определенное количество работы - только хэш значения. Это именно то, как сейчас. котировка Цитата: puddinpop 14 октября 2010, 10:34:25 PM Сервер создает блок, который, очевидно, не включает в себя операции, использующие монеты, которые генерируются этим же блок, в основном, потому что нет никаких операций, полученных из блока, так как никто не знает о блоке еще кроме сервера. Ах. Я думал, что ты и я думал по тем же линиям элегантного способа оплаты, который не требует никакого доверия и не может быть мошенническим, который, к сожалению, запрещено довольно несущественным и безвкусным правилом Bitcoin. Вы должны войти в более подробно о том, как работает оплата. Решения я могу думать требуют, чтобы клиент доверять серверу и / или может быть мошенническим. ByteCoin Сервер может передавать блок со всеми сделками с клиентом для проверки. Он не делает этого сейчас, но код не будет слишком трудно добавить. Существует на самом деле комментарий в коде, чтобы добавить эту функцию позже. Таким образом, клиент может проверить, что они получат свою долю. Если вы хотите более подробно, код является лучшим источником детализации вы можете получить. Цитата: davidonpda 15 октября 2010, 12:10:55 AM Цитата: puddinpop 14 октября 2010, 10:34:25 PM Цитата: Гэвин Андресен 14 октября 2010 года, 1:49:06 PM Я уверен, вы бы получить хорошее приближение к скорости хеширования, если клиенты представили свой лучший (высокий уровень сложности) хэш каждые N минут. В течение нескольких часов в среднем все эти лучшие хешей должна быть пропорциональна скорости хеш-клиента (если клиент не были как-то раз очень повезло или не повезло, но это было бы крайне маловероятно). Что остановить клиента от лжи? Они просто генерировать несколько хэшей просто послать и сказать серверу, "Это лучшие хэши я придумал, честно." На самом деле клиент тратит остальную часть времени, пытаясь сформировать свой собственный блок. Там нет абсолютно никакого способа проверить, что клиент не лежит таким образом. С metahash подходом, вы можете проверить каждый индивидуальный хэш клиент сообщила решению. Если они лгут, даже около 1 из этих хэшей, вы будете знать, потому что metahash не совпадает. Может быть, вы не получите то, что он говорит. Давайте посмотрим на целевой хэш скажем, 10 символов, тем больше 0 на фронте, тем лучше. Bitcoin блок должен 9 нулей, чтобы получить блок 50 монет. Вы просите их лучший результат каждые 10 минут. Если они работают в течение 1 минуты на средней машине, они дают вам результат с 2 нулями. Если они работают в течение всего 10 минут, они дают вам результат с 4-мя нулями. Все результаты, которые они ищут, не будет основываться на текущей хэш, так что нет впустую работы. Они просто хранить их лучше в клиенте для текущей хэш, и отправить его, когда сервер запрашивает. Переключитесь на пути Bitcoin работ. Сложность фактор 1398 Кто-то пытается обмануть посылает вам обратно имеет стоит трудность 1. Настоящий клиент посылает вам обратно трудности 7. Кто-то на GPU машина посылает вам обратно трудности 190. Лучший способ сделать это, был бы просить их лучшие военнопленный для каждого блока. Вы можете взять время каждый блок взял, хэш, что они были в состоянии найти (что очень быстро проверить на стороне сервера) и придумать формулу, какую долю они получат. Формула может включать в себя сглаживание высоких пик и минимумов. Это может быть самый сложный метод ... но это звучит до сих пор для меня, как наиболее точный способ, чтобы получить как относительно честный ответ, и он будет относительно взломать доказательство. Все время создания соответствующего потенциального блока. Как они взламывать найти лучший хэш? Если они находят более сильный хэш, они вполне могли бы находить фактический блок. Ничто не теряется в этом сценарии. Я понимаю, что это предложение, но я не вижу его в качестве надежного метода. Предполагается, что вы будете генерировать определенную трудность при определенной скорости хэша в определенное время. Мы все знаем, что это не произойдет. Как вы фактор в незадачливых клиентов? Как насчет счастливчиков? Лучшее, что вы можете сделать, это взять в среднем в течение неприемлемо длительного периода времени, чтобы сгладить скорость хеширования. Я думаю, что этот метод слишком несовершенен, и имеет потенциал, чтобы оштрафовать или более вознаграждение клиентов слишком легко. Я, конечно, не хотел бы, чтобы клиент нарушает, потому что я не мог создать хороший хэш в заданный промежуток времени.

15 октября 2010, 4:23:00 AM	# 17
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Вы, кажется, ценят точность предоставленной вашим "metahash" Схема пока, видимо, терпя значительное количество случаев мошенничества в реальных сценариях использования. Я считаю, что вероятностные схемы пропагандируемых всеми остальные являются достаточно точными, вполне возможно, мошенничеством доказательства и результата, по существу, нулевой нагрузки на сервере. Если мы можем согласиться, некоторые правдоподобные параметры реального мира заранее, и я провернуть через математику, я считаю, что может доказать, что случайные ошибки, полученные при измерении скорости вероятностного значительно меньше искажений, вызванного inevietable мошенничества. Вы бы изменить свое мнение, если я доказал это? Цитата: puddinpop от 15 октября 2010 года, 2:42:31 AM Ошибочные результаты бы быть фактором для любого метода проверки клиента. Решение состоит в том, чтобы обеспечить определенное количество ошибок. Это кажется мне сложно без использования большой пропускной способности. Ты говоришь, что вы делаете это в данный момент или вы планируете это сделать? Как это работает? Там остается несколько вопросов из предыдущих постов, я запрошен, но которые остаются нерешенными. Цитата: puddinpop 14 октября 2010, 12:42:16 PM Второй вопрос заключается в том, что каждый шахтер теперь нужно будет проверить вычисленный хэш от цели после каждого хэша. Это еще одна операция, клиент должен выполнить, и это будет замедлять поколение. Это было сделано в ответ на предложение от tatcm для измерения скорости путем подсчета хэш низкой сложности хешей. Вы, кажется, предполагает, что один недостаток предложения tatcm является то, что вам нужно сравнить хэш цели. Вы означает, что ваш метод позволяет избежать этого сравнения и выше на этой основе. Вы, кроме того, означает, что операция сравнения имеет значительные вычислительные затраты по сравнению с операцией хэш. Для того, чтобы не быть неправильно, то вы должны показать 1) как ваш метод позволяет избежать сравнений хэша от цели. 2), что сравнение не незначительная стоимость по сравнению с операцией хэша. Я утверждаю, что вы будете не в состоянии сделать это, и что, следовательно, вы должны забрать свой "второй вопрос" с предложением tatcm в. Цитата: puddinpop 14 октября 2010, 12:42:16 PM Что остановить клиента от лжи? Они просто генерировать несколько хэшей просто послать и сказать серверу, "Это лучшие хэши я придумал, честно." Вы, кажется, под впечатлением, что расчет скорости может быть обманным путем отправки несколько предположительно низкого качеством хэш, которые являются результатом незначительных вычислительных усилий. Я утверждаю, что это не возможно. Вы должны показать, почему вы думаете, что клиент может лежать о его вычислительных усилиях в этой моде. Пожалуйста, дайте мне знать, будете ли вы убеждены только явным численным демонстрацией превосходства вероятностным скорости хеш-схемы meaurement, а также ваш ответ на два нерешенных вопросов из предыдущих постов, которые остаются без ответа, которые изложены выше. Кроме того, объяснение того, как ваша схема metahash может эффективно переносить вычислительные ошибки будет приветствоваться. ByteCoin

15 октября 2010, 5:03:07 AM	# 18
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: davidonpda от 15 октября 2010 года, 3:08:16 AM Одна из самых важных вещей, о объединенных добычах будут участвовать в доверенных группах. Я не думаю, что доверенные группы необходимы, если используются схема вероятностная. Каждый клиент, модифицирован или нет, знает трудности хэшей он произвел и может рассчитать свои ожидаемые долгосрочные доходы, хотя, конечно, будут краткосрочные колебания. Недобросовестный сервер будем попасться из (и довольно скоро, если некоторые из клиентов решили поделиться своей статистикой). Недобросовестный клиент не получает больше, чем его реальную долю прибыли в любом случае.

15 октября 2010, 5:57:39 AM	# 19
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: ribuck от 15 октября 2010 года, 5:03:07 AM Я не думаю, что доверенные группы необходимы, если используются схема вероятностная. Согласовано. {Удалено неправильный материал о клиентах жульничестве. Благодаря ribuck для сдачи меня правильно.} Сервер обмана схем и их предупреждение: Сервер может сказать, что многие из достаточно не совсем хороших хэш подавался клиентами, находящихся в собственности оператора сервера. Чтобы предотвратить это, сервер должен опубликовать все хэши, которые были использованы при расчете работы. Сервер может принять доказательство работы хэши одного или нескольких подлинных клиентов и приписывать их к клиенту, принадлежащей оператору сервера. Чтобы предотвратить это, клиенты подписывают их хэш с помощью открытого ключа адреса, которые они хотят быть начислены их частями горшка. Хэш и подпись все опубликованный на сервере. Сервер может опустить публиковать подписанные хэши подмножества клиентов, которые не контролируются им, и которые не нашли выигрышный хэш. Это увеличивает свою долю в банке. Чтобы предотвратить это, клиенты периодически отправлять подписанные хэши на сервер и сервер подписывает recipt и возвращает его клиенту. Клиент проверяет recipt действует, прежде чем продолжить работу. Если сервер не включает опубликовать подмножество подписанных хэш, то клиент имеет доказательство того, что сервер принял их и может опубликовать это дискредитировать сервер. Если подпись сервера недействительна, то клиент прекращает работу, и объем вычислений впустую ограничен. Я полагаю, что Гэвин Андресен-х "лучший хэш в срок" будет низкой пропускной способностью и предсказуемый способ измерения скорости хэш в этой схеме. Наконец, сервер может не распространять 50BTC клиентов. Чтобы предотвратить это, я подумал, что хитрая идея состояла в том, чтобы иметь как сделки, в новом Боке включают распределение Новоиспеченного 50BTC coinbase участников. Это было бы также предотвратить все вышеописанные атаки на один шаг. Клиенты будут прекратить работу над хэшированием блока, если блок сделка не поделила выручку в моде клиент считал справедливым. Я считаю, что стандартное программное обеспечение Bitcoin отвергает блоки попытки провести coinbase, что не созрел. Если это может быть изменено на позволяя тратить, но делать эти операции 0 / неподтвержденной пока coinbase не созревает, то вся проблема уходит, и мы все очень рады. Если сервер дает клиентам кредитные операции, которые не связаны с перспективно чеканили coinbase, но вместо того, чтобы какой-нибудь другой источник денег, то клиенты могут просто представить эти операции в сети и получить кредит, прежде чем делать всю работу, таким образом, обмане сервер. В противном случае клиент просто должен взять слово сервера для него, что корень Merkle они используют включает в себя операции их кредитования надлежащим образом. Там нет никакого способа доказать это. Это проблема. Там может быть решением с щегольскими сценариями. ByteCoin

15 октября 2010, 6:07:56 AM	# 20
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: складочный / Remote Майнинг - Open Source - Обновлено 2010-12-24 Цитата: ByteCoin от 15 октября 2010 года, 5:57:39 AM Клиент может обмануть, если он генерирует выигрышный хэш в наивной реализации, не сумев передать выигрышный хэш на сервер и просто передавать его непосредственно, как обычный клиент Bitcoin и принимая 50BTC для себя. Нет, я так не думаю. Блок включает в себя время хэшированной транзакции 50BTC присужден генератор. Таким образом, клиент должен решить (прежде чем искать хэшей) ли он хэширования блок, который будет платить сам, или блок, который будет платить сервер. Он не может найти хэш, а затем решить, кто это для. Таким образом, нет никакого риска обмана. Если клиент ищет хэши, которые будут платить сам, он не участвует в общей добыче и не будет иметь никаких результатов низкой сложности для отправки на сервер либо.

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

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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW