Зачем вводить ограничения на скрипты транзакций Bitcoin Coinbase?

Есть несколько ограничений на структуру транзакции coinbase (вознаграждения) в блоке.

  1. Есть только один вход. vin.size() == 1( источник )
  2. Он не ссылается на какой-либо предыдущий вывод. vin[0].prevout.IsNull()( источник )
  3. scriptSig не слишком большой. vin[0].scriptSig.size() <= 100( источник )
  4. СценарийSig не так уж и мал. vin[0].scriptSig.size() >= 2( источник )

Я не вижу смысла ни в одном из них. #1 и #2 включают BIP34 , но они не обязательны для достижения того же результата. Ограничения по размеру на самом деле ничего не ограничивают, если майнер хочет создать большой блок, он может просто много-много выходов в своей базе монет или много-много транзакций в свой блок.

Почему транзакция coinbase не является просто транзакцией, которая:

  1. Имеет хотя бы один вход, который не ссылается ни на один из предыдущих выходов (для использования в BIP34 )
  2. Разрешено требовать до (награда за блок + сборы) больше, чем он может потратить

В частности, coinbase может иметь дополнительные нулевые входы и тратить предыдущие выходы.

Я знаю, что для Биткойна, вероятно, уже слишком поздно что-то менять. Является ли это случаем чрезмерного проектирования или существуют соображения безопасности для любого из этих ограничений на базе монет? Ослабление ограничения № 2, в частности, заставляет меня задуматься из-за электронного письма списка рассылки разработчиков биткойнов, в котором говорилось, что разрешение coinbase тратить prevouts позволит безопасно платить майнеру за майнинг реорганизации цепочки определенным образом.

#1 and #2 enable BIP34Собственно, высота блока идет в скрипте Sig, а не в prevout.
@NickODell, но значение prevout равно null делает так, что scriptSig может содержать что угодно, в частности, он может содержать высоту.

Ответы (1)

Правильный ответ: спросите Сатоши.

Мои предполагаемые ответы на вопросы, которые вы задали:

  1. Почему только один вход? Вы не можете предсказать, когда конкретная транзакция coinbase превратится в успешный блок, и вы не можете потратить результат транзакции coinbase на 100 блоков. Это означает, что использование обычной транзакции намного лучше любых обычных расходов. Если нет нормального случая для добавления входных данных в базу монет, возможно, Сатоши решил, что лучше запретить входные данные, чтобы предотвратить необдуманные атаки.

  2. Зачем ссылаться на нулевой минус ? Использование того же базового формата, что и в обычной транзакции, вероятно, позволяло повторно использовать код. Если бы он оптимизировал базу монет, мы бы сэкономили 36 байт умножить на 338 692 блока (на данный момент), или около 12 МБ. Не так уж и важно.

  3. Зачем ограничивать размер базы монет до 100 байт? Мы знаем, что Сатоши использовал coinbase, чтобы поместить сообщение в блок 0. Возможно, ограничение в 100 байт было его попыткой помешать кому-либо еще использовать тот же механизм для добавления слишком длинных сообщений. Вероятно, это было довольно разумно: с самых ранних дней до сегодняшнего дня многие майнеры добавляют сообщения во все свои базы монет — мы можем только представить, насколько раздражающими и расточительными были бы эти сообщения, если бы они не были ограничены 100 байтами.

  4. Зачем указывать минимальный размер базы монет как 2 байта? Это весьма спекулятивно, но, возможно, Сатоши предвидел легкое дублирование баз монет, описанное в BIP30, и хотел, чтобы люди использовали что-то вроде оригинального экстранонса , чтобы предотвратить случайные коллизии TXID.

Что касается №1, можете ли вы вспомнить какие-либо такие непродуманные атаки? Возможно, это связано с платой майнеру за майнинг реорганизации определенным образом? Я не знаю, как это сработает. В № 2 я предполагаю, что оптимизация, о которой вы говорите, заключается в том, что не нужно указывать prevout (32 байта) и индекс (4 байта). Я думаю, что ваше предположение № 3 имеет большой смысл.
#1Что ж, когда Сатоши принял проектное решение, правила консенсуса не отклоняли блоки, в которых не учитывалась высота блока (это было сделано с BIP34 , поэтому атака, которую вы описываете, не сработала. Однако оплата конкретному майнеру за создание блок является антидецентрализованным --- если вы платите конкретному майнеру, вы, вероятно, не поощряете децентрализованный майнинг с использованием комиссии #2за транзакцию.