Привет Erik,

Спасибо за прочтение и комментарий.

В присутствии многого БИПА, я думаю, нужен критерий квалифицированный. Я не знаю, почему 95% будет лучше, чем 75%. Я думаю, что 75% достаточно, и я думаю, что 95% не может быть достижим. Конечно, если будет достигнут консенсус и "Bitcoin-жильный" или другой проект убеждает всех, чтобы использовать SW, то новый протокол BIP10X может быть просто активированный на заданную высоту блока.

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

Может быть, это недоразумение. Шахтеры не голосуют "каждую неделю"Они голосуют непрерывно "каждый блок", 1 неделя относится к интервалам, в котором шахтер голос Оцениваются и, возможно, корректировки размера блока ограничения имеет место. Я перефразировать это в моей обновленной версии на Github, чтобы избежать этого недоразумения в будущем.

Они не должны. Эта "BIP10X" Предложение предполагает, что операторы шахтера не должен взаимодействовать, но только настроить то, что их предпочтения в голосовании "bitcoin.conf", А затем шахтер будет автоматически отбрасывать правильное голосование в соответствии с предпочтениями Miner оператора. Оператор может регулировать его предпочтения в любое время (нет необходимости соблюдать 1-недельные интервалы в любом случае). Также обратите внимание на то, что вместо стратегии голосования "проголосуй за фиксированное значение", Оператор шахтер также можно настроить с помощью bitcoin.conf, что стратегия голосования должна быть, например, "проголосуй за средний фактический размер блока прошлой недели раз некий самостоятельный выбор факторов"Или шахтер может голосовать за "же предел размера блока, как текущий блок ограничение размера",

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

Вы предлагаете автоадаптации BlockSizeLimit например исключительно на основе фактических пломб блоков? В принципе это возможно, но я хочу представить шахтер голосование "узаконенный" внутри протокола, чтобы избежать утомительной "Предельный размер блока"-motivated жесткие вилки дискуссии на будущее, как мы сейчас. Потому что, если шахтеры могут голосовать в протоколе, они не должны голосовать за совершенно новый hardfork SW, но могут просто использовать механизмы голосования, уже присутствующие в протоколе. Я также написал, как это в "мотивация" часть предложения BIP10X.

Кроме того, мы видим из реакций шахтеров сегодня, что они, как решение, в котором они могут активно голосовать, следовательно, их поддержка BIP100 настолько велика. И мы не можем игнорировать этот факт. Но я хочу, чтобы предложить решение, которое устраняет недостатки BIP100 (которые, возможно, не все операторы рудничных полностью разобрались и знает), т.е. улучшенной версии BIP100, если вы хотите, что шахтеры могут надеяться также хорошо согласуются с, надеюсь, даже лучше, чем с самим BIP100. Можно было бы рассмотреть BIP10X эволюция BIP100.

Еще одна причина, по полной "автоадаптации" без голосования, что могут быть природные (например, сезонные) периоды меньшей трафика, которые не обязательно должны незамедлительно привести к BlockSizeLimit приспособлений (уменьшение) слишком рано. Я действительно считаю, что голосование (или человек = влияние шахтерского) должно играть важную роль, и "фактический размер блока" ограничение следует только шаг, если расхождение между фактическим размером блока и BlockSizeLimit голосованием становится слишком много.