Почему Сатоши не увеличил место для одноразового номера?

Я знаю, что Сатоши больше нет рядом, чтобы спрашивать, поэтому спрашивать может быть бесполезно, но я надеюсь, что кто-то может что-то понять по этому поводу.

В майнинге биткойнов обычно используется поле extraNonce ( bnExtraNonceв scriptSig coinbase tx) и поле nonce (32 бита). Почему Сатоши просто не увеличил поле nonce, и тогда не было бы необходимости в bnExtraNonce? Есть ли какая-то причина, по которой поле nonce должно быть 32-битным? Кажется, было бы проще иметь 64-битное целое число в заголовке блока. Даже если он беспокоился о том, что целое число больше 32 бит, заголовок мог быть просто интерпретирован как два 32-битных целых числа nonce1и nonce2.

Ответы (5)

На этот вопрос было много хороших ответов. Прочитав их, я тоже попытаюсь ответить.

Поле coinbase транзакции coinbase (как оно называется) на самом деле представляет собой просто scriptSig, который не должен проходить какую-либо проверку своего содержимого (за исключением того, что он меньше 100 байтов и более новые требования BIP34). Сатоши знал, что вы можете поместить сюда произвольное содержание, поэтому он поместил своевременный заголовок новости в сценарий исходного блока Sig: «The Times 03/Jan/2009 Канцлер на пороге второй помощи банкам». Подобное сообщение также помогает подтвердить, что предварительный майнинг не проводился, поскольку сообщение не могло быть помещено в блок до даты публикации статьи.

Я думаю, что Сатоши думал, что 32-битное одноразовое пространство было излишним. Стандартный компьютер, подобный тому, на котором я это пишу, может получить около 3 MH/s, что составляет около 0,07% пути через один одноразовый диапазон, прежде чем вы сможете увеличить nTime и получить совершенно новый диапазон одноразовых номеров. Это не значит, что Сатоши думал, что когда-либо будет майнить только один процессор компьютера ( этот пост показывает, что это не так), но я уверен, что он думал, что в этом случае у каждого майнера будет свой собственный адрес.

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

Из правил протокола не существует такого понятия, как дополнительный одноразовый номер.

В заголовке блока есть только 32-битный одноразовый номер (который можно очень быстро повторить), а на входе coinbase может быть до 100 произвольных байтов. Код генерации блоков внутри эталонного клиента традиционно помещает «дополнительный одноразовый номер» в эти произвольные байты, но содержимое может быть любым.

Как вы думаете, почему он изначально поместил туда поле coinbase? Тайлер предположил, что это может позволить вносить произвольные изменения в блок даже в ситуации, когда нет никаких изменений в условиях транзакций. Однако не уверен, почему изменение корня merkle было бы лучше, чем просто изменение второго поля nonce. Дэвид предположил, что он, вероятно, использовался для отладки. Однако похоже, что это можно было просто распечатать в файле отладки.
Может быть, он даже не собирался ничего туда помещать, это просто транзакция со scriptSig, которую вам не нужно проверять, поэтому вы можете поместить туда все, что хотите, и это не вызовет ошибок...
Но он поместил сообщение в транзакцию coinbase блока генезиса, поэтому он, очевидно, знал, что его можно изменить. Я думаю, что майнерам просто повезло, что было что-то, что можно было так легко изменить, поскольку Сатоши не дал достаточно места для одноразового номера.
32-битный одноразовый номер в заголовке блока подходит для 4 Ghash. Отметка времени в заголовке составляет 4 Ghash/s. 32-битного extranonce (что, однако, означает пересчет дерева Меркла) достаточно для 16 экзахеш/с. Что вы говорите о том, что этого недостаточно?
Я имел в виду, что одного nNonce недостаточно для текущего использования, поэтому пулы прибегают к изменению базы монет.

Мое предположение: кажется очевидным, что Сатоши не ожидал майнинга в пуле.

В мире без майнинга в пуле у вас просто было бы, чтобы каждое оборудование для майнинга, способное до 4 гигахэшей в секунду (GH/s), использовало свой собственный открытый ключ, гарантируя, что оно производит уникальный вывод транзакции coinbase. Поле времени может обновляться каждую секунду, поэтому одноразовый номер может быть сброшен на 0 при каждом обновлении времени.

В мире с объединенным майнингом несколько человек создают идентичные выходные данные транзакций coinbase (платят тому, кому оператор пула говорит платить), и они коллективно хешируют намного быстрее, чем 4 GH/s, исчерпывая диапазон одноразовых номеров до предполагаемого времени. быть обновленным. Это требует дополнительного одноразового номера, чтобы избежать проверки одними и теми же хэшами заголовков несколькими майнерами.

Так почему же Сатоши вообще создал лишний одноразовый номер? Похоже, это был простой способ узнать, сколько хэшей использовал майнер с момента запуска. Если вы посмотрите на базу монет из блока 1 (первый блок после блока генезиса), вы увидите, что это:

 04 ......... Push 4 bytes to stack
 ffff011d ... The same as the nBits field
 01 ......... Push 1 byte to the stack
 04 ......... Number of times nonce was reset so far: 4  <= 20 GH

По блоку 10 это 0x36 (54 <= 220 GH). Короче говоря, оригинальный дополнительный одноразовый номер может быть просто дополнительным инструментом отладки. Вы можете использовать nBits и дополнительный одноразовый номер, чтобы вычислить, сколько блоков в среднем должен был произвести майнер, и если это сильно отличается от того, сколько блоков он произвел, у вас могут возникнуть проблемы.

Спасибо, это полезно! Значит, вы думаете, что он думал, что 32-битного одноразового номера будет достаточно, а затем поле coinbase в транзакцию coinbase было добавлено позже, чтобы избежать изменения заголовка блока и предоставить майнерам больше одноразового пространства? Или, если он был там с самого начала для отладки, это не объясняет, что ему нужно было даже поместить его в цепочку блоков. Кажется, что вы могли бы просто писать в файл отладки каждый раз, когда одноразовый номер переполняется, и это было бы проще.
Возможно, он хотел узнать, сколько хэшей майнер должен сделать общедоступным в блокчейне. Кроме того, означает ли это, что нам просто повезло, что Сатоши даже указал поле coinbase в транзакции coinbase, и поэтому майнинг в пуле возможен? (Все еще было бы возможно с двумя одноразовыми номерами в заголовке)
Поле coinbase было всегда. Изменения в поле coinbase изменяют заголовок (корень merkle). Я не думаю, что первоначальная реализация дополнительного одноразового номера использовалась для того, чтобы дать майнерам большее пространство для одноразового номера — я думаю, что он использовался для отладки. Майнеры начали использовать его для других целей, когда они начали создавать пулы, а текущее дополнительное использование nonce началось, когда стало доступно оборудование ASIC, которое могло хешировать намного быстрее, чем 4 GH/s. (До этого майнеры использовали хаки вроде nRollTime.)
Если бы поля coinbase не было, майнеры могли бы просто добавить сценарий вывода с нулевым значением, начиная с OP_RETURNсоздания дополнительного поля nonce.
Я тоже об этом думал, но это не был бы стандартный тип транзакций (или, может быть, тогда не было такого понятия, как стандартные типы транзакций?). Что вы подразумеваете под «отладкой»? Что он отладил? Я просто не понимаю, почему что-то из этого должно быть в поле coinbase и менять корень merkle, а не просто иметь больше одноразового номера в заголовке.
Для текущего майнинга было бы удобнее, если бы заголовок nonce был больше. Ваш вопрос заключался в том, почему Сатоши не ожидал этого, поскольку он, кажется, предвидел необходимость в дополнительном поле одноразового номера для обновления корня merkle. Я предполагаю, что целью исходного дополнительного поля nonce было не обновление корня merkle (хотя оно это и делало), а отслеживание статистики о том, сколько хэшей было проверено. Майнеры, которым необходимо использовать дополнительный одноразовый номер в качестве вспомогательного одноразового номера заголовка, не занимаются майнингом так, как предполагал Сатоши, с уникальным открытым ключом для каждой единицы оборудования для майнинга.
Дополнительный одноразовый номер всегда был там. Даже сам блок генезиса имеет экстранонс (со значением 4). И нестандартность OP_RETURN не имеет значения для майнеров, так как именно они решают, что помещать в блок.

На самом деле дополнительный одноразовый номер представляет собой произвольное целое число точности ( http://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/ )

Я предполагаю, что это позволяет вносить произвольные изменения в блок даже в ситуации, когда нет никаких изменений с точки зрения транзакций. Это сделало бы еще менее вероятным появление неразрешимого пустого блока в период без транзакций. (Уже почти невозможно. Но хеши по своей природе непредсказуемы, поэтому Сатоши, возможно, просто был слишком параноиком, добавляя их.)

На самом деле нам вообще не нужен 32-битный одноразовый номер в заголовке блока. Все можно поместить в скрипт ввода coinbase. Итак, вопрос должен быть таким: можем ли мы иметь дело с 76-байтовым заголовком блока вместо 80-байтового?

Если бы в заголовке блока не было поля nonce, вам потребовались бы хэши log(N) SHA256d для каждого хэша, который вы делаете, где N — количество транзакций. Таким образом, люди, которые не включают транзакции, будут иметь явное преимущество.
Ааа, потому что поле nonce делает так, что вам не нужно каждый раз пересчитывать корень Меркла. Я до сих пор не понимаю, почему Сатоши хотел бы, чтобы вам пришлось так много возиться с корнем merkle, когда мы могли бы просто иметь большее nonce-space.
Спасибо, Ник ODell для очистки. Возможно, Сатоши думал, что 32-битного одноразового номера достаточно. 80 байт для заголовка - это круглое число. Пересчет хэша merkle после 4 млрд попыток не представляет большой проблемы
Разве это не будет 2 * N хэшей для каждого хэша заголовка блока? Высота дерева Меркла будет log(N), но количество хэшей, необходимых для вычисления корня Меркла, я думаю, составляет около 2*N.
@StephenM347StephenM347 Да, но вы меняете только монетную базу, поэтому вам нужно только пересчитать часть дерева Меркла.
Ааа, имеет смысл. Так что это объясняет, почему не весь диапазон nonce находится в coinbase, но не то, почему он не весь был помещен в заголовок блока... Какая польза от наличия чего-либо в coinbase? Это просто похоже на обходной путь.
@StephenM347: более короткие заголовки блоков, что, среди прочего, приводит к снижению потребления ресурсов клиента SPV на 5%.
@MeniRosenfeld, это интересно, но вряд ли стоит того или запланировано. См. мой ответ выше о том, как я, по крайней мере, рационализирую ограниченное пространство одноразового номера.