[RFC] Testnet сброса | Биткоин форум

Сложность на -testnet раздражающе высока. Я предлагаю сбросить -testnet с новым генеза блока и изменения -testnet правила для регулировки сложности следующим образом:

1. Отрегулируйте трудности на testnet каждые 126 блоков (1 / 16'th регулярной чистую корректировки).
2. Держите "Трудность может настроить до максимума 4 *", Но снять ограничение на то, как быстро трудность можно отрегулировать вниз. Минимальная трудность будет оставаться таким же.

Если я не слышу вопли протеста или лучшие идеи, я буду генерировать генезис блок и отправить запрос на тянущий с изменениями. Я не переключит -testnet кран на новую цепочку, пока мы получили 0.3.20 релиз-кандидат строит из.

Я абсолютно согласен, эти правила сделают testnet более полезным для тестирования программного обеспечения.

+1 договорились

Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него?

Цитата: Дав от 30 января 2011 года, 8:41:56 PM

Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него?

Нет, в случае необходимости мы будем менять правила регулирования сложности и сделать код:

если (текущий блок > some_number)
... новые правила регулирования трудности
еще
... старые правила для регулирования трудности

Я мог бы сделать это и сохранил testnet блок цепь, но она чище, чтобы просто сбросить его с новыми правилами.

А также "потянув тот же трюк" означает, что в подавляющем большинстве бросали огромное количество хэширования мощности в основной сети (например, в 16 раз тока общей мощности хеширования) в течение значительного промежутка времени, который становится все более и более трудно сделать.

запрос / тянуть патч:
https://github.com/bitcoin/bitcoin/pull/53

Большая работа ^^
Мы не должны быть обеспокоены слишком много о настройке testnet трудности, так как это все равно выбросить 🙂

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

Сброс не плохо само по себе, имеющих различные правила для каждой сети, безусловно, не очень хорошая вещь, IMO. Что делать, если завтра мы решим, что testnet должны иметь дополнительные X, Y и Z функции, потому что это более "удобный" ?

Может быть, уроки с обгоном тестовой сети должны быть применены к основной сети тоже, если один человек принимал тест сеть на, что организация может сделать? И как мы можем ожидать, что?

То, что я голосую за следующим:
- сброс testnet с теми же правилами, чем основная сеть,
- совершить тот факт, что единственное различие между основным и теста порт и блок генеза,
- предвидеть способ справиться с основной сетью обгоняет тем, кто решил, что стоит это делать

Простое решение, я могу думать о:
- Если ни блок не был создан для 24h ,, 48h или любой сложности делят на 2

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

Цитата: Дав от 01 февраля 2011, 12:31:29 AM

Простое решение, я могу думать о:
- Если ни блок не был создан для 24h ,, 48h или любой сложности делят на 2

...который не решает текущие проблемы с testnet. Testnet трудности не безумно высока, это еще можно добывать блок с достойной аппаратных средств в час или около того. Но она слишком высока для эффективного тестирования некоторого программного обеспечения, где вам нужны много блоков, чтобы пройти все испытания.

Я вижу вашу точку и частично согласен. Некоторые лучше алгоритм, чтобы снизить трудности должны быть усыновителем как к testnet и основной сетью. Но для текущей ситуации, изменения, предложенные Гэвин отлично для меня.

Если testnet клон Bitcoin полностью, это может быть резервный блок цепи в случае стихийных бедствий. Может быть хорошо иметь отдельную сеть там на всякий случай, хотя то же самое может произойти и с более слабой сети, как это случилось с первой тестовой сети.

Можно ли создать версию Bitcoin можно запустить на множестве виртуальных машин, имитирующих реальную сеть?

Bitcoin тестовой сети в песочнице.

Цитата: Гэвин Андресен 31 января 2011 года, 1:07:31 AM

Цитата: Дав от 30 января 2011 года, 8:41:56 PM

Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него?

я за один предпочел бы этот подход полностью перезапуск цепи.

Держите testnet как можно ближе к живой системе. Он разберется в течение нескольких недель.

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

Я думаю, что при переустановке testnet раз в то время это хорошая вещь, это будет означать сброс трудности тоже, поэтому определенные правила сложности для testnet не только бесполезны, но усложняя и склонны к введению ошибок (это например)

Цитата: ribuck 01 февраля 2011, 10:48:58 AM

Нет, она не разберется "через несколько недель", Позвольте мне увидеть, если я могу сделать резервную-оф-конверт:

Трудность в testnet в настоящее время 373. Мы хотим, чтобы она не выше, ой, 5, так и с типичной 3-й или 4-машиной CPU-хеширования на testnet генерировать блок в разумном промежутке времени.

Таким образом, мы формируем в 2016 году блоков более 8 недель. Это сокращает трудности на четыре: ~ 90
Тогда сделайте это снова: ~ 22
и снова ... ~ 5 ПОЛГОДА позже

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

Если вы хотите продолжать использовать старую testnet цепь, быть моим гостем.

Я сочувственно к "testnet и основная сеть должна иметь те же правила", Но на самом деле это testnet есть, и всегда будет много меньше людей хэширования на нем.

Изменение основного чистого кода downard Трудность-регулировка может иметь смысл, но это тема для другого потока. Разрешение основной нетто трудностью настроить весь путь от 22000 до 1 не правильный ответ (это делает Сибил атаки, когда злоумышленник подает вам поддельную версию блока цепи намного проще).

Цитата: Гэвин Андресен 02 февраля 2011 года, 2:56:54 PM

Я сочувственно к "testnet и основная сеть должна иметь те же правила", Но на самом деле это testnet есть, и всегда будет много меньше людей хэширования на нем.

Давайте сделаем это политика, чтобы сбросить testnet каждый месяц / выпуск / что угодно.
Проблема решена, одни и те же правила, как, трудности будут оставаться очень низким, так как никто не хочет добывать для TBTC, так как это будет ясно, что они никогда не будут ценны.

Цитата: davidonpda от 02 февраля 2011 года, 5:28:43 PM

Зачем менять трудности у всех на testnet?

Почему бы не просто держать его в 1 навсегда? Если мы делаем это изменить каждые каждые 126 блоков, кто-то с GPU может ввернуть все с изменением сложности быстро, а затем она занимает 126 блоков для того, чтобы вернуться вниз (который может быть неделя или больше)

Точка testnet, чтобы сделать тесты, которые являются существенными и воспроизводимых на основной сети, если две разные правила, которые вы могли бы, а не что-либо проверить

Цитата: davidonpda от 02 февраля 2011 года, 5:28:43 PM

Что плохого об изменении реальной сети каждые 126 блоков тоже?

хороший вопрос

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

Цитата: ЛЧЙ от 03 февраля 2011, 12:04:54 PM

Да.

Из того, что я понимаю, есть две разные вещи testnet используются для генерации тестирования -> вам нужна низкая трудность для того, чтобы испытывать легкие, testnet также должен иметь те же правила, чем основная сеть, в противном случае тесты не могут быть очень значимыми.

Если вам нужны длительные тесты, вы можете также проверить с парой основных чистых монет.

Я не возражаю делать кодировку, связанную с этой задачей раз в то время, когда трудность делает тестирование сложнее.
патч Вот

Как насчет использования нескольких цепей с различными правилами?

Код:

-testnet = 0
-testnet = 1
-testnet = п

Может быть, лучше было бы четко документировать, как настроить различные testnet.
Я документ, что я сделал, чтобы сбросить текущий тест сети, давайте начнем оттуда.

30 января 2011, 6:25:56 PM	# 1
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Сложность на -testnet раздражающе высока. Я предлагаю сбросить -testnet с новым генеза блока и изменения -testnet правила для регулировки сложности следующим образом: 1. Отрегулируйте трудности на testnet каждые 126 блоков (1 / 16'th регулярной чистую корректировки). 2. Держите "Трудность может настроить до максимума 4 *", Но снять ограничение на то, как быстро трудность можно отрегулировать вниз. Минимальная трудность будет оставаться таким же. Если я не слышу вопли протеста или лучшие идеи, я буду генерировать генезис блок и отправить запрос на тянущий с изменениями. Я не переключит -testnet кран на новую цепочку, пока мы получили 0.3.20 релиз-кандидат строит из.

30 января 2011, 6:29:05 PM	# 2
слякоть Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Получил 1806 Биткоинов Реальная история. Я абсолютно согласен, эти правила сделают testnet более полезным для тестирования программного обеспечения.

30 января 2011, 6:42:35 PM	# 3
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс +1 договорились

30 января 2011, 8:41:56 PM	# 4
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него?

31 января 2011, 1:07:31 AM	# 5
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: Дав от 30 января 2011 года, 8:41:56 PM Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него? Нет, в случае необходимости мы будем менять правила регулирования сложности и сделать код: если (текущий блок > some_number) ... новые правила регулирования трудности еще ... старые правила для регулирования трудности Я мог бы сделать это и сохранил testnet блок цепь, но она чище, чтобы просто сбросить его с новыми правилами. А также "потянув тот же трюк" означает, что в подавляющем большинстве бросали огромное количество хэширования мощности в основной сети (например, в 16 раз тока общей мощности хеширования) в течение значительного промежутка времени, который становится все более и более трудно сделать.

31 января 2011, 2:32:00 PM	# 6
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс запрос / тянуть патч: https://github.com/bitcoin/bitcoin/pull/53

31 января 2011, 10:16:31 PM	# 7
Cdecker Сообщения: 487 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Большая работа ^^ Мы не должны быть обеспокоены слишком много о настройке testnet трудности, так как это все равно выбросить 🙂

1 февраля 2011, 12:31:29 AM	# 8
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Ну, я думаю, что это немного странно иметь разные правила testnet чем основная сеть ... Как правило, среда постановка сохраняется как можно ближе к производству одного. Сброс не плохо само по себе, имеющих различные правила для каждой сети, безусловно, не очень хорошая вещь, IMO. Что делать, если завтра мы решим, что testnet должны иметь дополнительные X, Y и Z функции, потому что это более "удобный" ? Может быть, уроки с обгоном тестовой сети должны быть применены к основной сети тоже, если один человек принимал тест сеть на, что организация может сделать? И как мы можем ожидать, что? То, что я голосую за следующим: - сброс testnet с теми же правилами, чем основная сеть, - совершить тот факт, что единственное различие между основным и теста порт и блок генеза, - предвидеть способ справиться с основной сетью обгоняет тем, кто решил, что стоит это делать Простое решение, я могу думать о: - Если ни блок не был создан для 24h ,, 48h или любой сложности делят на 2 Я не думаю, что: - признавая, что основные и тест имеют разные правила, - не предвидя этот конкретный вид атаки это хорошая вещь.

1 февраля 2011, 12:58:55 AM	# 9
слякоть Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: Дав от 01 февраля 2011, 12:31:29 AM Простое решение, я могу думать о: - Если ни блок не был создан для 24h ,, 48h или любой сложности делят на 2 ...который не решает текущие проблемы с testnet. Testnet трудности не безумно высока, это еще можно добывать блок с достойной аппаратных средств в час или около того. Но она слишком высока для эффективного тестирования некоторого программного обеспечения, где вам нужны много блоков, чтобы пройти все испытания. Я вижу вашу точку и частично согласен. Некоторые лучше алгоритм, чтобы снизить трудности должны быть усыновителем как к testnet и основной сетью. Но для текущей ситуации, изменения, предложенные Гэвин отлично для меня.

1 февраля 2011, 1:17:07 AM	# 10
Сообщения: Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Если testnet клон Bitcoin полностью, это может быть резервный блок цепи в случае стихийных бедствий. Может быть хорошо иметь отдельную сеть там на всякий случай, хотя то же самое может произойти и с более слабой сети, как это случилось с первой тестовой сети. Можно ли создать версию Bitcoin можно запустить на множестве виртуальных машин, имитирующих реальную сеть? Bitcoin тестовой сети в песочнице.

1 февраля 2011, 6:43:09 AM	# 11
нанотрубка Сообщения: 485 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: Гэвин Андресен 31 января 2011 года, 1:07:31 AM Цитата: Дав от 30 января 2011 года, 8:41:56 PM Да, это хорошо, но мы сбрасываем основную сеть на следующий день кто-то тянет тот же трюк на него? Нет, в случае необходимости мы будем менять правила регулирования сложности и сделать код: если (текущий блок > some_number) ... новые правила регулирования трудности еще ... старые правила для регулирования трудности Я мог бы сделать это и сохранил testnet блок цепь, но она чище, чтобы просто сбросить его с новыми правилами. А также "потянув тот же трюк" означает, что в подавляющем большинстве бросали огромное количество хэширования мощности в основной сети (например, в 16 раз тока общей мощности хеширования) в течение значительного промежутка времени, который становится все более и более трудно сделать. я за один предпочел бы этот подход полностью перезапуск цепи.

1 февраля 2011, 10:48:58 AM	# 12
ribuck Сообщения: 826 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Держите testnet как можно ближе к живой системе. Он разберется в течение нескольких недель. Создайте дополнительный блок цепочку для тех, чье развитие потребности требуют что-то другое, чем то, что testnet обеспечивает.

1 февраля 2011, 10:54:31 AM	# 13
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Я думаю, что при переустановке testnet раз в то время это хорошая вещь, это будет означать сброс трудности тоже, поэтому определенные правила сложности для testnet не только бесполезны, но усложняя и склонны к введению ошибок (это например)

2 февраля 2011, 2:56:54 PM	# 14
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: ribuck 01 февраля 2011, 10:48:58 AM Держите testnet как можно ближе к живой системе. Он разберется в течение нескольких недель. Создайте дополнительный блок цепочку для тех, чье развитие потребности требуют что-то другое, чем то, что testnet обеспечивает. Нет, она не разберется "через несколько недель", Позвольте мне увидеть, если я могу сделать резервную-оф-конверт: Трудность в testnet в настоящее время 373. Мы хотим, чтобы она не выше, ой, 5, так и с типичной 3-й или 4-машиной CPU-хеширования на testnet генерировать блок в разумном промежутке времени. Таким образом, мы формируем в 2016 году блоков более 8 недель. Это сокращает трудности на четыре: ~ 90 Тогда сделайте это снова: ~ 22 и снова ... ~ 5 ПОЛГОДА позже Вот оптимистично предполагая, что мы можем найти людей, сотрудничать способствовать хэширования мощности для создания в 2016 году блоков в сложности 300 в 8 недель или меньше. Если вы хотите продолжать использовать старую testnet цепь, быть моим гостем. Я сочувственно к "testnet и основная сеть должна иметь те же правила", Но на самом деле это testnet есть, и всегда будет много меньше людей хэширования на нем. Изменение основного чистого кода downard Трудность-регулировка может иметь смысл, но это тема для другого потока. Разрешение основной нетто трудностью настроить весь путь от 22000 до 1 не правильный ответ (это делает Сибил атаки, когда злоумышленник подает вам поддельную версию блока цепи намного проще).

2 февраля 2011, 3:03:32 PM	# 15
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: Гэвин Андресен 02 февраля 2011 года, 2:56:54 PM Я сочувственно к "testnet и основная сеть должна иметь те же правила", Но на самом деле это testnet есть, и всегда будет много меньше людей хэширования на нем. Давайте сделаем это политика, чтобы сбросить testnet каждый месяц / выпуск / что угодно. Проблема решена, одни и те же правила, как, трудности будут оставаться очень низким, так как никто не хочет добывать для TBTC, так как это будет ясно, что они никогда не будут ценны.

2 февраля 2011, 5:32:06 PM	# 16
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: davidonpda от 02 февраля 2011 года, 5:28:43 PM Зачем менять трудности у всех на testnet? Почему бы не просто держать его в 1 навсегда? Если мы делаем это изменить каждые каждые 126 блоков, кто-то с GPU может ввернуть все с изменением сложности быстро, а затем она занимает 126 блоков для того, чтобы вернуться вниз (который может быть неделя или больше) Точка testnet, чтобы сделать тесты, которые являются существенными и воспроизводимых на основной сети, если две разные правила, которые вы могли бы, а не что-либо проверить Цитата: davidonpda от 02 февраля 2011 года, 5:28:43 PM Что плохого об изменении реальной сети каждые 126 блоков тоже? хороший вопрос

3 февраля 2011, 12:04:54 PM	# 17
ЛЧМ Сообщения: 196 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Если testnet имеет различные правила он теряет часть своей стоимости в качестве испытательного полигона, так как вы не тестируете правила производства больше.

3 февраля 2011, 1:23:52 PM	# 18
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Цитата: ЛЧЙ от 03 февраля 2011, 12:04:54 PM Если testnet имеет различные правила он теряет часть своей стоимости в качестве испытательного полигона, так как вы не тестируете правила производства больше. Да. Из того, что я понимаю, есть две разные вещи testnet используются для генерации тестирования -> вам нужна низкая трудность для того, чтобы испытывать легкие, testnet также должен иметь те же правила, чем основная сеть, в противном случае тесты не могут быть очень значимыми. Если вам нужны длительные тесты, вы можете также проверить с парой основных чистых монет. Я не возражаю делать кодировку, связанную с этой задачей раз в то время, когда трудность делает тестирование сложнее. патч Вот

4 февраля 2011, 12:58:50 AM	# 19
LZ Сообщения: 1680 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Как насчет использования нескольких цепей с различными правилами? Код: -testnet = 0 -testnet = 1 -testnet = п

4 февраля 2011, 8:59:59 AM	# 20
Дав Сообщения: 1372 Цитировать по имени цитировать ответ	Re: [RFC] Testnet сброс Может быть, лучше было бы четко документировать, как настроить различные testnet. Я документ, что я сделал, чтобы сбросить текущий тест сети, давайте начнем оттуда.

Заголовок