Re: Гибкие Сделки - BIP134
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki
Это альтернатива SegWit, с жесткой вилкой.
Видео: https://vimeo.com/193595931
котировка
BIP: 134
Название: Гибкие Сделки
Автор: Том Zander <tomz@freedommail.ch>
Статус: Проект
Тип: Стандарты Track
Создано: 2016-07-27
== Аннотация ==
Это BIP описывает следующий шаг в создании самого основного элемента Bitcoin, в
сделка, более гибкой и легче расширить. В то же время это
фиксирует все известные случаи пластичности и решает значительные суммы
технический долг.
== Резюме ==
Гибкие Транзакции использует тот факт, что первые 4 байта в транзакции
определить версию и что большинство клиентов использовать
правило, не консенсус (политика) не принимать номера версий транзакций
кроме тех, которые конкретно определены Bitcoin.
Этот BIP выбирает новый номер версии, 4, и определяет, что данные
Следующий байт для версии в формате под названием Compact Message
Format (CMF). СМФ представляет собой гибкий, маркер на основе формата, где каждый маркер представляет собой
Сочетание имени, формата и стоимости. Поскольку имя добавляется мы
может пропускать неиспользуемые маркеры, и мы можем свободно добавлять новые маркеры простым способом
в будущем. Мягкая вилка обновление станет намного проще и чище этого
путь.
Это обновление протокола очищает прошлое мягкие вилки изменения как BIP68, которые
использовать существующие поля и сделать их лучше, чтобы поддерживать и проще
для анализа системы. Это создает строительные блоки, чтобы новые возможности быть
добавил гораздо чище в будущем.
Он также показывает, что можно удалить подписи от операций с
минимальные обновления программного обеспечения и по-прежнему поддерживать последовательную сделку
история. Тесты показывают, что это может уменьшить использование пространства до 75%.
== Мотивация ==
После 8 лет использования по существу той же версии транзакции и расположения
Bitcoin нуждается в обновлении и извлеченных уроках в то время являются
принимая во внимание при его проектировании. Наиболее важной деталью является то, что
мы видим необходимость большей гибкости. Например, когда «последовательность»
поля были введены в старом формате транзакции, а затем осуждается
опять же, конечный результат в том, что все сделки по-прежнему были вынуждены держать
эти поля и вырастить blockchain в то время как все они были установлены по умолчанию
стоимость.
Путь к этой гибкости использовать родовое понятие из популярных
различные десятилетия назад с форматом XML. Идея заключается в том, что мы даем каждому
поле имя, и это означает, что новые поля могут быть добавлены или необязательные поля
может быть исключено из отдельных операций. Некоторые другие идеи являются
стандартизация данных-форматы (например, целое число и строка кодирование), так
мы создаем более последовательную систему.
Одна вещь, которую мы не должны наследоваться от XML является текстовый формат. Вместо
мы используем [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Компактный формат сообщений]
(СМФ), который оптимизирован, чтобы сохранить размер мал и быстро разобрать.
Лексем на основе файловых форматов не являются новыми, системы, такие как XML и HTML использовать
Подобная система для обеспечения будущего роста, и они были весьма успешными
на протяжении десятилетий отчасти из-за этого свойства.
Рядом с этим это обновление протокола будет переупорядочить данные-поля,
позволяет нам аккуратно решить проблему пластичностью, что означает, что будущее
технологии, такие как Lightning сеть будет зависеть от этого BIP развертывается.
В то же время, из-за этого повторного упорядочения полей данных, он становится очень
легко удалить подписи из сделки, не нарушая ее TX-идентификатор,
который отлично подходит для будущих функций обрезки деревьев.
=== Особенности ===
* Исправления тягучесть
* Линейное масштабирование подписи проверки
* Очень гибкая расширяемость будущее
* Делает сделки меньше
* Поддерживает Lightning сеть
Кроме того, в формате v4 (flextrans) мы добавим поддержку для
следующие доказательства;
* Сумма входного сигнала. В том числе сумма средств, мы подписываем эту сделку, только если сумма, которую мы тратим это один предусмотрено. Бумажник, которые не имеют полную UTXO DB можно смело подписывать, зная, что, если они лгали о количестве расходуются, их подписи бесполезно.
* ScriptBase является комбинированный сценарий ввода и вывода, без подписей естественно. Обеспечивая это аппаратный кошелек означает, что он знает, что выход он тратит и может реагировать должным образом. Включая его в хэш означает, что его подпись была бы нарушена, если мы врали ..
* Двойной отработанное доказательство. Если узел обнаружения двойной потраченный он может уведомить своих коллег об этом факте. Вместо того, чтобы посылать целые операции, вместо этого он посылает только доказательство. Узел должен отправить две пары информации, что доказывает, что в обоих сделок CTxIn идентичны.
=== токены ===
В компактном формате сообщения определят лексемы и в этой спецификации мы
определить, каким образом эти маркеры называются, где они могут быть размещены и которые
необязательный. Для того, чтобы обратиться к XML, эта спецификация будет Зонирование
сделка.
[Https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md СМФ]
жетоны триплеты имени, формат (например, положительное_целый) и значение.
Имена в этой области определяются так же, как перечисление, где фактическая
целое значение (идентификатор, ниже) в равной степени важно письменном имя.
Если какой-либо маркер обнаружил, что не рассматривается в следующей таблице он будет делать
сделка, которая содержит его недействительным.
6
=== изменения сценариев ===
В Bitcoin операций версии 1, проверка подписей осуществляется
различные опкоды. OP_CHECKSIG, OP_CHECKMULTISIG и их эквиваленты
что сразу VERIFY. Они используются для проверки криптографической
доказательства того, что пользователи должны обеспечить, чтобы провести выходные.
Дополнительно мы имеем некоторые хеширования-типа в как SIGHASH_SINGLE, что все
указать несколько различных подразделы, какую часть сделки будет
хэширования для того, чтобы быть подписаны.
Для сделок с 4-й версии мы вычисляем хэш SHA256 для подписания
индивидуальный вход на основе следующего содержания;
# Если хэш-тип 0 или 1 мы хешируем TX-идентификатор транзакции. Для других типов хэшей мы выборочно игнорировать части сделки так же, как он всегда работал. С той оговоркой, что мы никогда не сериализовать никаких подписей.
# TXID сделки мы тратим на этот вход.
# Индекс выхода сделки мы тратим на этот вход.
# Входной сценарий, который мы подписываем (без подписи, естественно).
# Сумма, как вар-междунар.
# Хэш-типа, как вар-междунар.
=== порядок Сериализация ===
Для того, чтобы идти в ногу с названием Flexible сделок, существует очень мало
требование иметь определенный порядок. Исключение составляет лишь случаи, когда
есть необязательные значения и переназначения бы непонятно, что имеется в виду.
По этой причине TxInPrevHash всегда должен быть первый маркер, чтобы начать
новый вход. Это происходит потому, что TxPrevIndex не является обязательной. маркеры
TxRelativeTimeLock и TxRelativeBlockLock является частью входных данных и
Аналогично должны быть установлены после TxInPrevHash они принадлежат.
Аналогичным образом, TxInputStackItem всегда должен быть первым и может быть
а затем ряд TxInputStackItemContinued пунктов.
При большем объеме мы определяем 3 секции сделки.
TXID рассчитывается путем принятия сериализированных сделок без
Подписи и TxEnd и хэширования, что.
TxEnd есть, чтобы анализатор знать, когда одна транзакция в потоке
закончился, позволяя рядом быть разобран.
=== Блок-ковкость ===
Эффект оставить подписи из вычислению
транзакции идентификатор подразумевает, что подписи также не используется для
расчет дерева Merkle. Это означает, что изменения в подписях
не было бы обнаружить и открыть вектор атаки.
По этой причине Merkle дерево расширено, чтобы включить (Append) хэш
в v4 сделки. Дерево Markle будет продолжать иметь все
Транзакции ТЕ-идентификаторы, но добавляются к тому, что являются v4 хэш, которые включают в себя
подписи, а также. В частности, хэш берется дата-сгусток, что
строится из:
# ТХ-идентификатор
# Весь ByteArray, что составляет все подписи сделок. Это сериализации всех подписей токенов, так TxInputStackItem и TxInputStackItemContinued в порядке, основанное на входах они связаны.
=== Будущее === расширяемость
Подстановочный NOP_1x используется в таблице, объясняющей маркеры фактически список
10 значений, которые в настоящее время определены как NOP (нет-операции) теги.
Любая реализация, которая поддерживает формат транзакции v4 следует игнорировать
это поле в сделке. Интерпретация и использование сделки, как если бы
это поле не присутствовал на всех.
Будущее программное обеспечение может использовать эти поля для украшения сделки с
дополнительные данные или функции. Транзакция производящая программное обеспечение не должно
тривиальным использовать эти маркеры для их собственного использования без сотрудничества и
связь с остальной частью экосистемы Bitcoin как шахтеры конечно
имеет возможность отклонять транзакции, использующие неизвестные к ним маркерам.
Количество жетонов, которые могут быть добавлены после числа 19 практически
неограниченны и они в настоящее время определены не допускаются в любом
сделка и сделка будет отклонена, если они присутствуют.
В будущем обновление протокола может вероятность того, что и указать значение для
любой маркер еще не указано здесь. Таким образом, будущие обновления должны быть достаточно
намного более гладкой, потому что нет никаких изменений в понятиях или в формате. Только новые
данные.
== Обратная совместимость ==
Полностью проверка старых клиентов не смогут понять или подтвердить
версия 4 сделки и должны быть обновлены, чтобы восстановить эту способность.
SPV (простая проверка оплаты) футляры должны быть обновлены, чтобы получить или
создать новый тип транзакции.
Этот BIP вводит новый формат транзакции без изменения или
протестующий существующий или любой из его практики. Поэтому
обратную совместимость для любых существующих данных или синтаксического анализа кода.
== Reference Implementation ==
Bitcoin Классик включает в себя реализацию, что следующая эту спецификацию.
Спец-автор отвергает понятие эталонной реализации.
спецификация всегда авторитетная, реализация не является.
Официальные спецификации можно найти на сайте;
https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
== Развертывание ==
Быть определенным
== Ссылки ==
[Https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] СМФ
== Copyright ==
Copyright (с) 2016 Том Zander <tomz@freedommail.ch>
Этот документ двойной лицензирован под Creative-Commons BY-SA лицензия v4.0
и Open Publication License v1.0 со следующими лицензионными-опций:
Распространение существенно измененные версий данного документа запрещено без явного разрешения владельца авторских прав.
Распределение работы или производной от произведения в любой стандартной (бумажной) книги запрещено без предварительного разрешения, полученного от владельца авторских прав.
Название: Гибкие Сделки
Автор: Том Zander <tomz@freedommail.ch>
Статус: Проект
Тип: Стандарты Track
Создано: 2016-07-27
== Аннотация ==
Это BIP описывает следующий шаг в создании самого основного элемента Bitcoin, в
сделка, более гибкой и легче расширить. В то же время это
фиксирует все известные случаи пластичности и решает значительные суммы
технический долг.
== Резюме ==
Гибкие Транзакции использует тот факт, что первые 4 байта в транзакции
определить версию и что большинство клиентов использовать
правило, не консенсус (политика) не принимать номера версий транзакций
кроме тех, которые конкретно определены Bitcoin.
Этот BIP выбирает новый номер версии, 4, и определяет, что данные
Следующий байт для версии в формате под названием Compact Message
Format (CMF). СМФ представляет собой гибкий, маркер на основе формата, где каждый маркер представляет собой
Сочетание имени, формата и стоимости. Поскольку имя добавляется мы
может пропускать неиспользуемые маркеры, и мы можем свободно добавлять новые маркеры простым способом
в будущем. Мягкая вилка обновление станет намного проще и чище этого
путь.
Это обновление протокола очищает прошлое мягкие вилки изменения как BIP68, которые
использовать существующие поля и сделать их лучше, чтобы поддерживать и проще
для анализа системы. Это создает строительные блоки, чтобы новые возможности быть
добавил гораздо чище в будущем.
Он также показывает, что можно удалить подписи от операций с
минимальные обновления программного обеспечения и по-прежнему поддерживать последовательную сделку
история. Тесты показывают, что это может уменьшить использование пространства до 75%.
== Мотивация ==
После 8 лет использования по существу той же версии транзакции и расположения
Bitcoin нуждается в обновлении и извлеченных уроках в то время являются
принимая во внимание при его проектировании. Наиболее важной деталью является то, что
мы видим необходимость большей гибкости. Например, когда «последовательность»
поля были введены в старом формате транзакции, а затем осуждается
опять же, конечный результат в том, что все сделки по-прежнему были вынуждены держать
эти поля и вырастить blockchain в то время как все они были установлены по умолчанию
стоимость.
Путь к этой гибкости использовать родовое понятие из популярных
различные десятилетия назад с форматом XML. Идея заключается в том, что мы даем каждому
поле имя, и это означает, что новые поля могут быть добавлены или необязательные поля
может быть исключено из отдельных операций. Некоторые другие идеи являются
стандартизация данных-форматы (например, целое число и строка кодирование), так
мы создаем более последовательную систему.
Одна вещь, которую мы не должны наследоваться от XML является текстовый формат. Вместо
мы используем [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Компактный формат сообщений]
(СМФ), который оптимизирован, чтобы сохранить размер мал и быстро разобрать.
Лексем на основе файловых форматов не являются новыми, системы, такие как XML и HTML использовать
Подобная система для обеспечения будущего роста, и они были весьма успешными
на протяжении десятилетий отчасти из-за этого свойства.
Рядом с этим это обновление протокола будет переупорядочить данные-поля,
позволяет нам аккуратно решить проблему пластичностью, что означает, что будущее
технологии, такие как Lightning сеть будет зависеть от этого BIP развертывается.
В то же время, из-за этого повторного упорядочения полей данных, он становится очень
легко удалить подписи из сделки, не нарушая ее TX-идентификатор,
который отлично подходит для будущих функций обрезки деревьев.
=== Особенности ===
* Исправления тягучесть
* Линейное масштабирование подписи проверки
* Очень гибкая расширяемость будущее
* Делает сделки меньше
* Поддерживает Lightning сеть
Кроме того, в формате v4 (flextrans) мы добавим поддержку для
следующие доказательства;
* Сумма входного сигнала. В том числе сумма средств, мы подписываем эту сделку, только если сумма, которую мы тратим это один предусмотрено. Бумажник, которые не имеют полную UTXO DB можно смело подписывать, зная, что, если они лгали о количестве расходуются, их подписи бесполезно.
* ScriptBase является комбинированный сценарий ввода и вывода, без подписей естественно. Обеспечивая это аппаратный кошелек означает, что он знает, что выход он тратит и может реагировать должным образом. Включая его в хэш означает, что его подпись была бы нарушена, если мы врали ..
* Двойной отработанное доказательство. Если узел обнаружения двойной потраченный он может уведомить своих коллег об этом факте. Вместо того, чтобы посылать целые операции, вместо этого он посылает только доказательство. Узел должен отправить две пары информации, что доказывает, что в обоих сделок CTxIn идентичны.
=== токены ===
В компактном формате сообщения определят лексемы и в этой спецификации мы
определить, каким образом эти маркеры называются, где они могут быть размещены и которые
необязательный. Для того, чтобы обратиться к XML, эта спецификация будет Зонирование
сделка.
[Https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md СМФ]
жетоны триплеты имени, формат (например, положительное_целый) и значение.
Имена в этой области определяются так же, как перечисление, где фактическая
целое значение (идентификатор, ниже) в равной степени важно письменном имя.
Если какой-либо маркер обнаружил, что не рассматривается в следующей таблице он будет делать
сделка, которая содержит его недействительным.
6
=== изменения сценариев ===
В Bitcoin операций версии 1, проверка подписей осуществляется
различные опкоды. OP_CHECKSIG, OP_CHECKMULTISIG и их эквиваленты
что сразу VERIFY. Они используются для проверки криптографической
доказательства того, что пользователи должны обеспечить, чтобы провести выходные.
Дополнительно мы имеем некоторые хеширования-типа в как SIGHASH_SINGLE, что все
указать несколько различных подразделы, какую часть сделки будет
хэширования для того, чтобы быть подписаны.
Для сделок с 4-й версии мы вычисляем хэш SHA256 для подписания
индивидуальный вход на основе следующего содержания;
# Если хэш-тип 0 или 1 мы хешируем TX-идентификатор транзакции. Для других типов хэшей мы выборочно игнорировать части сделки так же, как он всегда работал. С той оговоркой, что мы никогда не сериализовать никаких подписей.
# TXID сделки мы тратим на этот вход.
# Индекс выхода сделки мы тратим на этот вход.
# Входной сценарий, который мы подписываем (без подписи, естественно).
# Сумма, как вар-междунар.
# Хэш-типа, как вар-междунар.
=== порядок Сериализация ===
Для того, чтобы идти в ногу с названием Flexible сделок, существует очень мало
требование иметь определенный порядок. Исключение составляет лишь случаи, когда
есть необязательные значения и переназначения бы непонятно, что имеется в виду.
По этой причине TxInPrevHash всегда должен быть первый маркер, чтобы начать
новый вход. Это происходит потому, что TxPrevIndex не является обязательной. маркеры
TxRelativeTimeLock и TxRelativeBlockLock является частью входных данных и
Аналогично должны быть установлены после TxInPrevHash они принадлежат.
Аналогичным образом, TxInputStackItem всегда должен быть первым и может быть
а затем ряд TxInputStackItemContinued пунктов.
При большем объеме мы определяем 3 секции сделки.
TXID рассчитывается путем принятия сериализированных сделок без
Подписи и TxEnd и хэширования, что.
TxEnd есть, чтобы анализатор знать, когда одна транзакция в потоке
закончился, позволяя рядом быть разобран.
=== Блок-ковкость ===
Эффект оставить подписи из вычислению
транзакции идентификатор подразумевает, что подписи также не используется для
расчет дерева Merkle. Это означает, что изменения в подписях
не было бы обнаружить и открыть вектор атаки.
По этой причине Merkle дерево расширено, чтобы включить (Append) хэш
в v4 сделки. Дерево Markle будет продолжать иметь все
Транзакции ТЕ-идентификаторы, но добавляются к тому, что являются v4 хэш, которые включают в себя
подписи, а также. В частности, хэш берется дата-сгусток, что
строится из:
# ТХ-идентификатор
# Весь ByteArray, что составляет все подписи сделок. Это сериализации всех подписей токенов, так TxInputStackItem и TxInputStackItemContinued в порядке, основанное на входах они связаны.
=== Будущее === расширяемость
Подстановочный NOP_1x используется в таблице, объясняющей маркеры фактически список
10 значений, которые в настоящее время определены как NOP (нет-операции) теги.
Любая реализация, которая поддерживает формат транзакции v4 следует игнорировать
это поле в сделке. Интерпретация и использование сделки, как если бы
это поле не присутствовал на всех.
Будущее программное обеспечение может использовать эти поля для украшения сделки с
дополнительные данные или функции. Транзакция производящая программное обеспечение не должно
тривиальным использовать эти маркеры для их собственного использования без сотрудничества и
связь с остальной частью экосистемы Bitcoin как шахтеры конечно
имеет возможность отклонять транзакции, использующие неизвестные к ним маркерам.
Количество жетонов, которые могут быть добавлены после числа 19 практически
неограниченны и они в настоящее время определены не допускаются в любом
сделка и сделка будет отклонена, если они присутствуют.
В будущем обновление протокола может вероятность того, что и указать значение для
любой маркер еще не указано здесь. Таким образом, будущие обновления должны быть достаточно
намного более гладкой, потому что нет никаких изменений в понятиях или в формате. Только новые
данные.
== Обратная совместимость ==
Полностью проверка старых клиентов не смогут понять или подтвердить
версия 4 сделки и должны быть обновлены, чтобы восстановить эту способность.
SPV (простая проверка оплаты) футляры должны быть обновлены, чтобы получить или
создать новый тип транзакции.
Этот BIP вводит новый формат транзакции без изменения или
протестующий существующий или любой из его практики. Поэтому
обратную совместимость для любых существующих данных или синтаксического анализа кода.
== Reference Implementation ==
Bitcoin Классик включает в себя реализацию, что следующая эту спецификацию.
Спец-автор отвергает понятие эталонной реализации.
спецификация всегда авторитетная, реализация не является.
Официальные спецификации можно найти на сайте;
https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
== Развертывание ==
Быть определенным
== Ссылки ==
[Https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md] СМФ
== Copyright ==
Copyright (с) 2016 Том Zander <tomz@freedommail.ch>
Этот документ двойной лицензирован под Creative-Commons BY-SA лицензия v4.0
и Open Publication License v1.0 со следующими лицензионными-опций:
Распространение существенно измененные версий данного документа запрещено без явного разрешения владельца авторских прав.
Распределение работы или производной от произведения в любой стандартной (бумажной) книги запрещено без предварительного разрешения, полученного от владельца авторских прав.
