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

Ниже приведен пример того, как может происходить процесс (версия # для клиентов, так и блоков в данном примере являются произвольными и используются только для целей иллюстрации):
1) Тест этот процесс от начала до конца на testnet.
2) В будущей версии Bitcoin клиента (1.0.1) добавлена ​​поддержка новой версии блока (версия 2). По умолчанию горнодобывающих узлы будут по-прежнему создавать версии 1 блоки в это время. В 1.0.1, ver2 блоков >высота 1MB они помечены как нестандартные и предупредят вопрос предупреждение узла, сохраните блок и не исключают их >1MB блоки, делая лучший / самый длинный выбор цепи.
3) Предложите пользователям перейти на 1.0.1. Контролируйте использование 1.0.1+ версий клиентов и ждать, пока супер большинство не модернизировал (не технический номер, но 80% + использовался в прошлом).  
4) После того, как супер большинство узлов модернизировали установить дату отсечения и использовать предупредительные сообщения, чтобы предупредить старые клиент, чтобы обновить или рискуют отделился основная сеть.
5) После того, как дата в шаге 4 были шахтеры начинают создавать версии 2 блоков (но все еще мягкие ограничивается 1 Мб). Флаг конфигурации может быть использован в 1.0.1 версии узла, чтобы заставить узел в версии 2 (режим блока еще мягкий ограничен до 1 Мб). Это гарантирует, что все узлы имеют возможность запускать то же кодовое, но по-прежнему сохранять свою способность поддерживать или не поддерживать новый блок версии.
6) принять решение о высоте блока для реализации >1MB блоки. Это должно быть 10 000 до 20 000 блоков за пределами текущей высоты блока. Это имело бы смысл для того, чтобы быть памятным номер, например, если мы были готовы к transistion сегодня (блок высотой 246242) может произойти изменение на высоте блока 260000
7) Выпуск новой версии клиента (1.1.1), который выше высоты блока решено на шаге 6, позволяет создавать версии 2-х блоков >1MB и считает их стандарт (выбираются самой длинной / лучшей цепь). Версия 1.1.1 будет удалить поддержку версии блока 1.
Используйте предупреждающие сообщения, чтобы предупредить узлы на версии старше 1.1.1, что они рискуют отделились после высоты блока в шаге 6. Поскольку высота блока приближается сообщения должны происходить чаще и с большей настойчивостью.
9) до основной версии 1.0.1 могут быть закодированы с помощью безотказного узла. С тех пор "понимает" VER2 блоки и просто считает >1MB нестандартным он может использовать это, чтобы защитить пользователя. Версия 1.0.1 может быть закодирована искать двойной тратит в >1MB блоки. Узел может также рассчитывать на # блоков, полученных на цепях, помеченных нестандартные (потому что они имеют 1 или более >1 МБ блок), и если это превышает 50% от общего числа блоков в предшествующем уровне дня пользователя, вероятно, был раздвоенным выключен (потому что после даты отсечки). Затем узел мог бы рассмотреть все операции неподтвержденным, предотвратить расходы и предупредить пользователя, чтобы немедленно обновить, чтобы избежать потери средств. Пользователи старше 1.0.1 будут иметь на знание версии 2-х блоков и подвергаются большему риску, однако аналогичный безопасный режим может быть встроено в клиентов, которые в настоящее время ищет >50% блоков, являющихся будущие блоки версий.

Конец состояние (после того, как высота блока определена # 6 проходов):
Шахтеры могут (но не обязаны) производить блоки больше 1Мб.
Все узлы на текущую версии будут видеть эти большие блоки, как действительные и использовать их для выбора наилучшей цепи.
Узлы, которые находятся на устаревшие версии имеют некоторую защиту от вредоносных атак (предупредительные сообщения & отказоустойчивый режим).

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