Segregated Witness и изменяемость транзакций

Любопытство

1. Почему посторонний мог изменить идентификатор транзакции, не нарушив её действительности?
2. Как вынос подписей из хешируемых данных устраняет изменяемость, сохраняя при этом их защиту консенсусом?
3. Что такое вес блока и почему скидка для witness-данных увеличила вместимость блока?

Исследование

1. До SegWit идентификатор транзакции (txid) вычислялся как двойной SHA-256 от всей транзакции, включая подписи. Третья сторона могла перекодировать подпись — например, заменить её значение s на противоположное или изменить способ его помещения в стек, — не делая подпись недействительной, и получить новый txid для того же платежа. Эта изменяемость ломала цепочки неподтверждённых транзакций: если дочерняя транзакция Алисы ссылалась на родительскую по идентификатору, изменённая родительская транзакция делала дочернюю «осиротевшей», что сбивало с толку кошельки и биржи, отслеживающие платежи.
2. В феврале 2014 года Mt. Gox ссылалась на этот механизм, объясняя внутренний хаос во время своего краха, однако последующий анализ показал, что на него пришлась лишь небольшая часть заявленных потерь. Уязвимость сохранялась, поскольку подписи ECDSA по своей природе допускают изменение байтового представления; переписывать их могли третьи стороны, а после введения BIP66 и правила low-S — главным образом майнеры. Из-за этой нестабильности было небезопасно строить двусторонние платёжные каналы, такие как Lightning, где состояния канала зависят от конкретных, предсказуемых идентификаторов транзакций ещё до подтверждения.
3. Механизм Segregated Witness (BIP141), активированный 24 августа 2017 года на блоке 481,824, решил эту проблему путем разделения данных свидетельства от самого тела транзакции. Теперь хэш txid формируется только на основе полей, не являющихся частью свидетельства, что делает его неизменным при изменениях в способе кодирования подписей. Данные свидетельства остаются в отдельной структуре внутри сырой транзакции, но не учитываются при формировании хэша идентификатора транзакции. Третьи стороны больше не могут изменять txid, в то время как подписи по-прежнему проверяются с использованием механизма консенсуса.
4. Witness-данные фиксируются через дерево Меркла, на которое ссылается coinbase-транзакция каждого блока, поэтому их нельзя удалить или изменить, не сделав блок недействительным. Хотя witness-данные отделены от txid, они всё равно учитываются в лимите размера блока по новой метрике — «весу»: 4 000 000 единиц веса на блок. Каждый байт вне witness считается за 4 единицы веса, а каждый байт witness — за 1, поэтому транзакции с большим объёмом подписей проще поместить в блок.
5. BIP143 ввёл новую схему хеширования подписей, устранившую квадратичный рост затрат на хеширование для транзакций с большим числом входов. BIP141 определил witness-программы версии 0 — P2WPKH и P2WSH, — ставшие стандартом для новых адресов, а BIP144 описал, как witness-данные передаются между пирами. Эти изменения не только устранили изменяемость, но и заложили основу для будущих обновлений, таких как Taproot, создав систему версионируемых witness-программ, которая позволяет развивать скрипты, не нарушая действующих правил консенсуса.
6. Откройте блок-эксплорер и найдите недавнюю транзакцию P2WPKH. Изучите её: подписи находятся в отдельном поле «witness», а не в scriptSig входа, и txid вычисляется без них. Сравните её с транзакцией P2PKH 2016 года, созданной до SegWit: там подписи находятся в scriptSig и поэтому входят в расчёт txid. Это наглядное разделение подтверждает, что witness-данные больше не влияют на идентификатор транзакции.

Ключевые факты

Упражнение девять, шесть, три, один

Проверка фактов

Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.

• BIP141: Segregated Witness (Consensus layer)
• BIP143: Transaction Signature Verification for Version 0 Witness Program
• Decker & Wattenhofer, 'Bitcoin Transaction Malleability and MtGox' (2014)
• Bitcoin Core 0.13.1 release notes (SegWit deployment)