Источник: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

Наконец получили некоторое время над китайским Новым годом, чтобы закодировать и записать это. Это не то же самое, как мой предыдущий forcenet ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html ). Это гораздо проще. Попытка активировать его на testnet будет вам запрещен. Попытка активировать его mainnet, прежде чем будет достигнут консенсус заставит вас потерять деньги.

Это предложение включает в себя следующие функции:

1. Фиксированный время пуска. Не зависит от сигнализации шахтера. Однако, это требует, по меньшей мере, 51% шахтеров фактически построить новый формат блока для того, чтобы активизироваться.

2. Он не имеет никакого механизма для предотвращения раскола. Если 49% шахтеров настаивают на оригинальной цепи, они могут продолжать идти. Сплит профилактика является социальной проблемой, а не технический.

3. Он совместим с существующим протоколом горнорудной Stratum. Только обновление программного обеспечения пула требуется

4. Новый расширенный и гибкий заголовок находится в поле свидетеля coinbase сделки

5. Это обратная совместимость с существующими световыми кошельками

6. Выделенные места для шахтеров, чтобы положить, что они хотят, что Bitcoin пользователи могли полностью игнорировать. Слияние-Майнинг дружелюбным.

7. Малого пространства заголовка для шахтеров, чтобы включать в себя не-консенсус вынужденного Биткойн связанных данных, полезный для оценки платы и т.д.

8. Новая формула веса сделка поощрять ответственное использование UTXO

9. Линейный рост фактического размера блока до определенного предела

10. Sighash O (N ^ 2) защиты для устаревшие (не-segwit) выходы

11. Дополнительной переигровки анти-транзакция

12. Новый дополнительный coinbase формат TX, который позволяет дополнительные входы, в том числе расходов незрелых предыдущих выходов coinbase



Спецификация [Обоснования]:


Активация:

* A "hardfork сигнализации блока" является блок со знаком битого заголовка nVersion установлен [Очевидно, недействительны для старых узлов; легко неавтоматического за легкими кошельками]

* Если средний показатель времени, прошлое последние 11 блоков меньше HardForkTime (точное время будет определена), блок сигнализации hardfork является недействительным.

* Ребенок блока сигнализации hardfork также должен быть блок сигнализации hardfork

* Первоначальная сигнализация hardfork не является обязательным, даже если HardForkTime имеет прошлое [требует, по меньшей мере, 51% шахтеров фактически построить новый формат блока]

* HardForkTime определяется широким консенсусом сообщества Bitcoin. Это единственный способ предотвратить раскол.


Расширенный заголовок:

* Основной заголовок относится к первоначальным 80 байт заголовка блока Bitcoin

* Блок сигнализации hardfork ДОЛЖЕН иметь дополнительный расширенный заголовок

* Увеличенный заголовок помещаются в поле свидетеля coinbase сделки [Есть 2 основные преимущества: 1. coinbase свидетеля в противном случае бесполезно; 2. Значительно просто реализация со структурой стека]

* Там должно быть ровно 3 пунктов свидетелей (HEADER1; HEADER2; Header3)
** Header1 должно быть ровно 32 байта исходной транзакции хэш корня Merkle.
** Заголовок 2 является вторичным заголовком. Она должна быть 36-80 байт. Первые 4 байта должны быть немного обратный порядок байт кодируется количество сделок (минимум 1). Следующие 32 байта должны быть свидетелем корень Меркл (будет определено позднее). Остальное, если таковой имеется, не имеет никакого консенсуса значения. Тем не менее, шахтеры НЕ ДОЛЖНЫ использовать это пространство, не Bitcoin цели [дополнительное пространство позволяет без censensus исполнение данных, которые будут включены, легко доступны для легких кошельков]
** Header3 является шахтером посвященного пространства. Оно не должно быть больше 252 байт. Все дело здесь не имеет никакого значения консенсуса [пространство для добычи слияния; неполные узлы могли полностью игнорировать данные в этом пространстве; 252 максимальный допустимый размер байта сигнала CompactSize]

* Основная приверженность заголовка представляет собой Н (Header1 | Н (Н (Заголовок 2) | H (Header3))) Н () = dSHA256 () [hardfork является прозрачным для света кошельков, за исключением того, еще один 32-байтовый хэш необходим для подключения сделка в корень]

* Для того, чтобы разместить заголовок внутр, segwit становится обязательным после hardfork


А «черный ход» softfork релакс предельного размера заголовок 2 и заголовок 3:

* Специальная BIP9 softfork определяется с бит-15. Если это softfork активируется, полные узлы не будут применять предельный размер для заголовка 2 и заголовка 3. [разрешить расширение заголовка без hardfork. Избегайте злоупотребления шахтер, обеспечивая при этом гибкость. Расширение может потребоваться для новых обязательств, как обязательства мошенничества доказательства]


Anti-АЯ-переигровка:

* Hardfork сетевая версия бит 0x02000000. ТХ является недействительным, если наивысший nVersion байт не равен нулю, а версия бит сети не установлен.

* Маска ОЙ версия nVersion со старшим маскируются. Если маскируется версия 3 или выше, sighash для OP_CHECKSIG, так рассчитывается с использованием BIP143, за исключением 0x02000000 добавляют к nHashType (The nHashType в подписи по-прежнему значение 1 байт) [обеспечить чистое разделение подписей; необязательно фиксировать O (N ^ 2) Проблема]

* Изменение политики Pre-hardfork: nVersion определяется замаскированной версией ОЙ для целей политики. Установка Pre-hardfork сетевой версии битного 0x01000000 допускается.

* Детали: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html


Sighash ограничение:

* Sighash воздействие оценивается «Loose оценки» в https://github.com/jl2012/bips/blob/065ea7429035d43ff90965f42b086fb7e1517291/bip-sighash.mediawiki

* Только TXS с замаскированной версией ниже 3 подсчитывается. [Потому что они фиксируются BIP-143, как подпись]

* Каждый SigHashSize определяется как 1 ТХ вес (определен позже).

* SIGHASH_SCALE_FACTOR 90 (см выше BIP)


Новое определение веса ОГО:

* Вес сделки максимум 4 следующих показателей:

** Общего размера сериализованного * 2 * SIGHASH_SCALE_FACTOR (размер определяется свидетелем Ого в формате BIP144)

** Скорректированный размер = (вес транзакций с помощью BIP141 - (количество входов - количество не OP_RETURN выходов) * 41) * SIGHASH_SCALE_FACTOR

** nSigOps * 50 * SIGHASH_SCALE_FACTOR. Все SigOps равны (без масштабирования свидетеля). Для не segwit передатчиков, то sigops в выходном scriptPubKey не учитывается, в то время как sigops во входном scriptPubKey подсчитывает.

** SigHashSize определены в предыдущем разделе

Воплощение в новую метрику, ограничение тока BIP141 является 360000000. Это эквивалентно 360MB из sighashing, 2Мбы сериализованного размера, 4MB скорректированного размера, или 80000 nSigOp.

См мотивировки в этом посте: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html


Блок вес растет по времени:

* Числа для примера. Точное количество будет определено.

* Масса блока в HardForkTime есть (5000000 * SIGHASH_SCALE_FACTOR)

* При каждом росте 16 секунд срединного временного прошлого, вес увеличивается на (1 * SIGHASH_SCALE_FACTOR)

* Рост останавливается (16,000,000 * SIGHASH_SCALE_FACTOR)

* Рост не зависит от фактического времени hardfork. Это только на основе медианы времени прошлого [с использованием медианы времени пришедшего так шахтеры не имеют никакого стимула использовать поддельный штамп времени]

* Предел для сериализованного размера от 2,5 до 8 МБ в течение примерно 8 лет. [Опять же, цифры, например, только]


Новый формат coinbase сделки:

* Существующий формат coinbase допускается, за исключением нового расширенного заголовка в coinbase свидетеля. Нет обязательств OP_RETURN свидетелей не требуется.

* Новый coinbase формат определен. TX может иметь 1 или более входов. Минус на первый входе должен иметь значение п 0xffffffff, и использовать предыдущий блок хэш в качестве минуса хэша [Это позволяет платить ребенок конкретного блока путем подписания блока хэша]

* ScriptSig первого (coinbase) вход не выполняется. Предельный размер увеличен с 100 до 252 (то же самое для старого формата coinbase)

* Дополнительные входы должны предоставить действительный scriptSig и / или свидетель расходов

* Дополнительные входы могут поступать от преждевременных выходов предыдущих coinbase [это позволяет предыдущие блоки платить последующие блоки поощрять подтверждение]


Свидетель корень Merkle:

* Если coinbase в старом формате, корень свидетеля Merkle такого же, как BIP141, установив следящий хэш coinbase ОГО как 0 (без 32 байт свидетеля зарезервированного значения)

* Если coinbase в новом формате, свидетель хэш coinbase ТХ рассчитывается путем первого удаления расширенного заголовка

* Корень свидетеля Merkle помещаются в расширенном заголовке 2, а не в качестве выходного сигнала OP_RETURN в coinbase ОГО.

* Корень свидетель Merkle становится обязательным. (Это было необязательным в BIP141)


Другие изменения консенсуса:

* BIP9 будет игнорировать знаковый бит. [Установка бита знака в настоящее время является недопустимым, так что это не имеет никакого реального влияния на основе консенсуса]

========

Экспериментальная реализация вышеуказанной спецификации можно найти по адресу https://github.com/jl2012/bitcoin/tree/spoonnet1

Не то же самое, как мои предыдущие усилия на «forcenet», то «spoonnet» является полным hardfork, который будет вам запрещен на существующую сеть.

У меня нет времени, чтобы проверить коды еще не анализировались независимо. Но она проходит все существующие тесты в Bitcoin Core. Никто не должен использовать это в производстве, но я думаю * * это прекрасно работает на testnet как нормальный bitcoind (до тех пор, как он не активирован)

Вещи еще не реализованы:

1. Автоматизированное тестирование

2. Пост-hardfork поддержка старых легких кошельков

3. Поддержка Wallet, особенно анти-АЯ-переигровка

4. Новое сообщение p2p для передачи вторичного заголовка (низший приоритет)

5. Полная добыча и поддержка mempool (не мой приоритет)

========

Потенциал второго изменения этапа:

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

1. SHA256 ярлык как ASICBoost. Все исправления в ASICBoost не очень элегантно. Но вопрос в том, допустимо ли иметь Bitcoin конкретного патента в протоколе консенсуса? Тем не менее, я считаю, что лучший способ решить эту проблему, является владельцем патента (s) любезно как-то освободить право общины.

2. Обеспечение более нонс пространства в главном заголовке 80 байт. Тем не менее, это зависит от ASICBoost быть свободной технологией.

3. Блок удержания атаки. Есть плюсы и минусы, но я в целом согласен с анализом Питер Тодд в https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012046.html . Один момент он не упомянул, что только небольшая действительно нуждается в майнинг, с целью уменьшения отклонений. Большие шахтеры с использованием бассейнов просто ленивы, и они хорошо работают без бассейна. Это означает, что только большие сольные шахтеры могут атаковать бассейны (т.е. мелких шахтеры), в то время как пулы не могут сделать любую контратаку. Это, очевидно, показывает, почему фиксируя это про стрелковых шахтеры. Кроме того, с таким же скоростью хэширования, блок удерживаемой атака более эффективна против меньшего бассейна, чем большой бассейн.

Все эти изменения связаны с изменением заголовка и требуют света бумажники для обновления. Они также требуют микропрограммного обновления для всех существующих шахтеров (изменение-не). Я думаю, что это не должно произойти, по крайней мере, 2 года после фактического активации hardfork так что люди будут иметь достаточно времени для обновления.