Какова цель такого скрипта, как RETURN PUSHDATA(36)(...)

Пример находится здесь: https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0 .

На самом деле выходов дваDUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]

Странно, что на первом выходе 12.77303443 BTC, на втором 0 BTC.

Есть два вопроса по этой сделке.

  1. Как у coinbase может быть больше 12,5 BTC?
  2. Какова цель RETURN PUSHDATA(36)(...), на самом деле, теоретически, этот вывод никогда не может быть никем использован, потому что OP_CHECKSIGв конце нет или аналогичного OP, чтобы вернуть true в стеке Script.

Ответы (3)

1) Как на коинбазе могло быть больше 12,5 BTC?

Из-за комиссий за транзакции

2) Какова цель RETURN PUSHDATA(36)(...),

Цель состоит в том, чтобы встроить данные в блокчейн. Биткойны не сжигались (и комиссия за транзакцию не взималась), так что это бесплатный способ встраивания данных в блокчейн.

Технически это не бесплатно, потому что плата основана на сатоши/кБ, а дополнительные данные увеличивают размер tx.
@JBaczuk Это coinbase tx.
вы правы, но это бесплатно только для coinbase, а не для tx с OP_RETURN
@JBaczuk для чего встраивать данные, развлекаться или получать правильный хэш блока (который должен быть на входе coinbase)? Будет ли пул UXTO хранить эти выходные данные в памяти?
@Capemer Он не будет хранить неиспользуемые результаты, есть проверка, которая немедленно удаляет UTXO, которые начинаются с OP_RETURN: github.com/bitcoin/bitcoin/commit/…
@JBaczuk, тогда какова цель этого?
Люди злоупотребляют им, чтобы хранить любые данные, которые они хотят сохранить «навсегда».
В данном случае этот вывод является частью segwit. Это для обязательства данных свидетеля. См. BIP 141: github.com/bitcoin/bips/blob/master/… . Причина использования OP_RETURN заключается в том, что UTXO не будет добавлен к набору UTXO, так как его невозможно потратить.

2) Какова цель RETURN PUSHDATA(36)(...), на самом деле теоретически этот вывод никогда не может быть никем использован, потому что в конце нет OP_CHECKSIG или аналогичного OP, чтобы вернуть true в скрипте куча.

Насколько я понимаю, это обязательно в блоках с поддержкой SegWit.

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

Ссылка и дополнительная информация: Структура обязательств BIP141 и аналогичный вопрос

Как сказал MCCCS, вознаграждение за майнинг состоит из субсидии на блок и комиссии за транзакцию.

Второй вывод на coinbase фиксирует данные свидетеля в блоке. Как вы, возможно, знаете, блокхедер фиксирует транзакции в блоке через корневое поле Merkle. Корень Меркла создается путем построения дерева Меркла из TXID (идентификаторов транзакций) всех транзакций. Поскольку TXID не связываются со свидетельскими данными, один только корень Merkle оставит свидетельские данные изменяемыми.

Таким образом, каждый блок, включающий какие-либо транзакции SegWit, должен иметь Witness Commitment . Обязательство свидетеля принимает форму 36-байтового OP_RETURNвывода транзакции coinbase, за которым следует префикс aa21a9ed, за которым следует 32-байтовый хэш, являющийся корнем Merkle транзакций WTXID (идентификаторы транзакций свидетеля). WTXID создаются из всей транзакции, включая свидетель.

Какова цель такого скрипта, как RETURN PUSHDATA(36)(...)
СпросиСетьПолитика конфиденциальности1y, 1v