OP_EVAL предложение | Биткоин форум

Я должен кредитовать jimrandomh для этой цитаты, которые ставят меня на правильном пути.

Цитата: jimrandomh от 01 октября 2011 года, 4:56:47 PM

Теперь предположим, что вместо того, чтобы публиковать адреса, что это хэш моего открытого ключа, я мог бы вместо того, чтобы опубликовать адрес, что это хэш произвольного скрипта. Тогда, если я хочу провести монеты вместе, я совершить сделку, содержащую как сценарий - который оказывается функция, которая говорит мне нужна некоторая комбинация подписей - а также подпись, которые делают скрипт возвращает истину. Это похоже на правильный путь для обработки нескольких ключевых адресов.

Когда я впервые прочитал это предложение, это звучало для меня как casascius предлагал специальный язык сценариев для использования с OP_CHECKSIGEX в рамках существующего языка сценариев. Это звучало безвкусный; Гораздо лучше иметь один язык сценариев, мы можем использовать для всего. Однако я пропустил точку casascius пытался сделать. Вот моя версия той же самой идеи, используя новый опкод OP_EVAL.

На данный момент, большинство scriptPubKeys выглядеть "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG",
Легко видеть, что для удовлетворения этого scriptPubKey Вы должны предоставить scriptSig, содержащий подпись и открытый ключ.
Когда вы отправляете кому-то ваш адрес, он принимается текущим клиентом в качестве инструкции для построения scriptPubKey вышеуказанного типа при оплате на этот адрес. Это означает, что только нужно распределить более короткий открытый ключ хэша для приема платежей, а не более открытым ключом.
когда blockexplorer видит сделку с выше scriptPubKey он знает, что только открытый ключ с указанным хэш может быть использован, чтобы удовлетворить его, и, следовательно, можно вычислить "баланс" адреса.

Мы могли бы ввести новый адрес типа тех же длины (но с порядковым номером версии) и нового опкод. Использование нового адреса будет означать, что намеченная scriptPubKey будет выглядеть "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_EVAL",
Для того, чтобы провести сделку, владелец этого адреса должен построить scriptSig, которая, вероятно, выглядит как "<сиг> <скрипт>" где <скрипт> можно рассматривать как число (OP_DUP'd и OP_HASH160'd), но когда OP_EVAL'd расширяется в сценарий.

Таким образом, чтобы дублировать функциональность существующей системы, новый адрес кодирует хэш "<Публичных> OP_CHECKSIG",
Кто-то посылать на этот адрес выглядит на номер версии и знает построить scriptPubKey из "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_EVAL" где scriptHash декодируется с адреса таким же образом, что pubKeyHash декодируется из текущих адресов.
Для того, чтобы выкупить сделки держатель адрес поставляет scriptSig из "<сиг> <скрипт>" где <скрипт> кодирует "<Публичных> OP_CHECKSIG", После объяснения страница транзакции вики

стек

Как заработать Биткоины?
Без вложений. Не майнинг.

2 октября 2011, 1:10:08 AM	# 2
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Получил 1806 Биткоинов Реальная история. Мне нравится OP_EVAL лучше, чем начать ... ENDDIGEST.

2 октября 2011, 1:15:36 AM	# 3
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: Гэвин Андресен 02 октября 2011 года, 1:10:08 AM Мне нравится OP_EVAL лучше, чем начать ... ENDDIGEST. Я не вижу разницы между этим и моим предложением, для использования имени символа OP_EVAL и говорят, что это новый опкод, а не просто переименовано в OP_CHECKSIG опкода за исключением, и использование всей системы сценариев, а не логическое подмножества , Это в противном случае в значительной степени идентичны. Если опкод были переименованы, и <скрипт> состоящий только из Публичных просто имел в виду "проверить подпись для этого Публичного", То не было бы никакой необходимости увеличивать номер версии. Все существующие Bitcoin сделки уже будет вперед совместимы с изменением. Я считаю, изменение номера версии и сделать все новые Bitcoin адреса начинаются с "2" будет стоить нам дополнительные сложности с точки зрения пользователя, и это не стоимость ресурса, чтобы принимать всерьез. В любом случае, я до сих пор нравится. Это будет по-прежнему работать так же хорошо, как новый опкод. Если вы выбираете этот план, моя единственная надежда состоит в том, что номер версии в адрес Bitcoin не увеличивается. Должна быть возможность сделать это без изменения - если каждый должен перейти на новый клиент в любом случае, то нормальные операции могли бы также содержать OP_EVAL, а также.

2 октября 2011, 1:23:51 AM	# 4
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Я также хотел OP_EVAL лучшее. Эта концепция является действительно фантастической идеей. Я по-прежнему обеспокоен тем фактом, что это будет сделать грубой силы атаки намного проще (хотя, вероятно, до сих пор невозможно). Это может быть хорошая идея, чтобы требовать OP_EVALed сценариев содержат, по меньшей мере, один SigOp или добавить еще один параметр OP_EVAL, который позволяет отправителю указать количество необходимых SigOps.

2 октября 2011, 1:31:46 AM	# 5
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: casascius от 02 октября 2011 года, 1:15:36 AM Я не вижу разницы между этим и моим предложением, для ... использования полной системы сценариев, а не логического подмножества исключения. Правда. Дело в том, что она использует существующую систему сценариев, вероятно, делает его легче реализовать и значительно уменьшить количество тестов, чтобы обеспечить покрытие кода. Я рад отказываемся любой кредит на идее, если это желательно. Вы правы в том, что OP_CHECKSIG может просто быть переписана так, чтобы она эффективно делает OP_EVAL и добавляет OP_CHECKSIG (см постскриптум) для декодированного сценария. Это будет иметь преимущество быть немедленно совместимы. Я, наконец, понять, что вы говорите. В моей защите, когда вы говорили о переопределении OP_CHECKSIG это звучало очень поверхностно. Я буду более внимательно читать ваши сообщения в будущем. Цитата: theymos от 02 октября 2011 года, 1:23:51 AM Я по-прежнему обеспокоен тем фактом, что это будет сделать грубой силы атаки намного проще (хотя, вероятно, до сих пор невозможно). Это может быть хорошая идея, чтобы требовать OP_EVALed сценариев содержат, по меньшей мере, один SigOp или добавить еще один параметр OP_EVAL, который позволяет отправителю указать количество необходимых SigOps. IsStandard (), скорее всего, убедитесь, что OP_EVAL'ed сценарии матч известный белый список типов, по крайней мере, один SigOp. Так что не сезон открыт на нестандартных типов транзакций еще. Одним из недостатков является то, что проверка IsStandard () теперь будет применяться, когда вы пытаетесь погасить монеты, а не когда вы пытаетесь отправить их. К сожалению, это означает, что если IsStandard терпит неудачу, вы, вероятно, не можете выкупить их (короткие ломки хэша), пока IsStandard не изменятся. Это может привести к некоторому дистресса. ByteCoin PS. Очевидно, что прилагается OP_CHECKSIG бы переименовать что-то еще, чтобы избежать рекурсии! Это просто вопрос предоставления вашей версии OP_EVAL количества OP_CHECKSIG и имеющий новый опкод, который на самом деле просто оценивает сиговый против Публичного. PPS Нет, вы правы снова. Это не хорошо всегда имея OP_EVAL добавить в OP_REALCHECKSIG к декодированному сценарию. Случай, когда декодируются сценарий просто Публичный должен быть признан и OP_REALCHECKSIG должен быть добавлен только в том случае, в целях обратной совместимости. Особое поведение и причины для этого потребуется совсем немного объяснить в комментариях к коду.

2 октября 2011, 2:49:27 AM	# 6
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Я присоединюсь к магистральному и сказать OP_EVAL хорошо. Я не озабочен кредитуются за это - я буду гораздо более взволнованы, чтобы это произошло, и я рад, что консенсус строит вокруг реализации что-то, что, в конечном счете достичь первоначально поставленной цели: автоматически мульти-сиг безопасных транзакций без изменение формата адреса Bitcoin. Это большое, потому что в конечном счете приведет к сценарию, в котором мы можем предложить реальную безопасность Bitcoin с непроницаемым лицом.

2 октября 2011, 5:44:03 AM	# 7
genjix Сообщения: 1232 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Я шучу? Система сценариев внутри системы сценариев. Хаки на писака на писаках приведет к протоколу грязнее, чем FTP теперь. Ну, кажется, хорошо на первый взгляд. Но быстрое отслеживание этого в блоке-цепь, вероятно, не мудрая идея. Там нет никакой спешки, так что может быть разумным, чтобы думать об этом как-то в течение 2-х лет времени или более поздней версии. Bitcoin не взрываются завтра, так что это не большая потеря от устояв на судьбоносных изменений, как эти. https://en.bitcoin.it/wiki/BIP_0001 Это хорошее место, чтобы начать. Повторное включение части старой системы сценариев контролируемым образом является хорошей идеей. Добавление нового не так осуществление операций много * право * сейчас.

2 октября 2011, 6:02:26 AM	# 8
theymos Сообщения: 2870 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Там нет необходимости, чтобы быстро отслеживать его, но это одна из нескольких вещей, которые должны быть включены в следующий раз, когда потребности блок цепочки должны быть раздвоенным (который вполне может быть лет через). Что неаккуратно испытывает отправители беспокоиться о новых типах транзакций, которые получатели хотят использовать. Это кажется довольно элегантно ко мне.

2 октября 2011, 6:24:54 AM	# 9
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Я 100% для DIGEST160 вещи. (Вместе же ключ, CHECKSIG должна была четыре опкодов с самого начала:. LOADTX (стек), DIGEST, SIGN и VERIFY, и мы могли бы использовать лучше убежать, чем CODESEPARATOR предоставляет) Это позволит решить проблемы в настоящее время в то время как лучше, общее решение в настоящее время хэшированное (ха!) из. Но будьте очень осторожны с OP_EVAL. Разрешение выполнения данных является чрезвычайно мощным и чрезвычайно трудно обеспечить. Злоумышленники могут сделать такие вещи, как вызывают бесконечные циклы, или переписать скрипт TX всегда проходят. Семантика Eval (), как известно, трудно придавить. Тем не менее, моя компания реализует Bitcoin-как крипто-маркер системы с участием Лисп как язык сценариев (с Eval, лямбды, макросы и все), и я был в первую очередь отвечает за решение сделать это. Поэтому я и говорю из опыта в предупреждении его опасности и трудности, и одновременно как сильный защитник для него, если все сделано правильно.

2 октября 2011, 11:03:02 AM	# 10
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Кажется, я понял часть первоначального предложения. Тем не менее, несколько замечаний: OP_EVAL звучит как очень элегантный способ увеличения мощности скриптового языка, в некоторые приятные возможности, как описано выше. Я согласен, мы должны быть очень осторожны, об этом - данные, принятые сценарии txout будучи всегда оценивает, должны быть защищены от какой-либо форме хэш-скрипта. Можно утверждать, что это обязанность отправителя, чтобы создать хороший сценарий, хотя. Включение операции, как OP_EVAL подразумевает удаление теста IsStandard (), так как он по существу позволяет любому сценарию обойти тест в любом случае. Я нахожусь в пользу отдыха IsStandard () и позволяет больше операций, но нам нужны твердые юнит-тесты, чтобы убедиться, что все задействованные скрипты / операции проверить штраф. Мне нравится тот факт, что использование ред сценарий хэш-защищенный Eval () не рекомендуется без плательщик спрашивать так (даже если я знаю, что у вас есть адреса A и B, нет никаких оснований для меня, чтобы ожидать, что OP_EVAL скрипт с хэш равно хэш скрипт, который проверяет наличие а и в будет обнаружен вашим клиентом в качестве расходов для вас Мне не нравится тот факт, что мы используем статическую строку для еще более сложных шаблонов txout, он рискует случайное повторное использование, невозможно отказаться после того, как строка будет опубликована, и трудно отследить. ИМХО, правильное решение для случаев было более сложные сценарии разыскиваются непосредственно переговоры их с приемником.

2 октября 2011, 3:45:16 PM	# 11
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение RE: опасайтесь OP_EVAL: Согласно, мы должны серьезно подумать о том, может ли нападавшие делать зло вещи, как создать безвредный небольшой скрипт, который оттолкнул бесконечное количество данных в стеке или что-то (позволяет видеть ... сериализовать () OP_DUP OP_EVAL бы сделать это ...). Запрет рекурсии (без OP_EVALs не допускается в OP_EVAL данных) будет, я думаю, предотвратить все это озорство. RE: OP_EVAL означает не более IsStandard: Я согласен с ByteCoin. ScriptSig будет IsStandard, если это ScriptPubKey был IsStandard, и если это ScriptPubKey была общая форма OP_EVAL то последнее значение проталкивается ScriptSig также придется пройти тест IsStandard (десериализованный в скрипт). RE: данные всегда должны быть защищены хэш-скрипт: Я думаю, что ответ "не быть идиотом" а также "использовать стандартные типы транзакций, которые были заколотили / продумано." RE: отправитель / получатель переговоры сделки: Я думаю, что может стать самым распространенным способом создания сделки, но я не думаю, что когда-либо будет единственным способом.

2 октября 2011, 4:37:43 PM	# 12
jimrandomh Сообщений: 43 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: genjix от 02 октября 2011 года, 5:44:03 AM Ну, кажется, хорошо на первый взгляд. Но быстрое отслеживание этого в блоке-цепь, вероятно, не мудрая идея. Там нет никакой спешки, так что может быть разумным, чтобы думать об этом как-то в течение 2-х лет времени или более поздней версии. Bitcoin не взрываются завтра, так что это не большая потеря от устояв на судьбоносных изменений, как эти. На самом деле, я думаю, что это значительно более актуальным, чем это. Прямо сейчас, это невозможно безопасно провести корпоративные масштабные суммы денег в Bitcoin, потому что корпорации не могут доверять какой-либо один человек с неограниченной властью расходов. Ботсети начали введение бумажника заготовки в качестве стандартной функции, и зашифрованные кошельки не защита, потому что они имели пароль Keylogging была стандартной функцией уже. Каждые крупные кражи сделки серьезный ущерб репутации Bitcoin, и если он занимает слишком много времени, чтобы добавлять новые функции безопасности, ущерб будет непоправимым. Там будет неизбежная задержка между вырабатывая детали этого предложения / группы предложений, а также введение в testnet; еще одна задержка между введением на testnet и введение в основной клиент; а потом еще задержка между введением к главному клиенту и активацией в blockchain, чтобы шахтеры время вставать на сегодняшний день. Эти задержки очень важны, но помните, что вещь, которую мы хотим максимизировать это мысль, а не время; и есть более эффективные способы, чтобы получить больше людей думать об этих вопросах, чем просто ждать. После того, как детали забиваются, и есть реализация testnet (который я вижу мало причин * не * бросаться, это только testnet), то это будет время, чтобы вызвать столько безопасности исследователя к нему внимание, насколько это возможно.

2 октября 2011, 4:55:15 PM	# 13
genjix Сообщения: 1232 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: jimrandomh от 02 октября 2011 года, 4:37:43 PM Прямо сейчас, это невозможно безопасно провести корпоративные масштабные суммы денег в Bitcoin, потому что корпорации не могут доверять какой-либо один человек с неограниченной властью расходов. OP_CHECKMULTISIG позволяет иметь транзакцию, которая требует несколько подписей (необходимо 2 из 3 Sigs из A, B, C). Это предложение, чтобы тонкоуровневая логика, когда платеж погашается (SIGs A и B или просто C).

2 октября 2011, 5:05:36 PM	# 14
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: jimrandomh от 02 октября 2011 года, 4:37:43 PM После того, как детали забиваются, и есть реализация testnet (который я вижу мало причин * не * бросаться, это только testnet), то это будет время, чтобы вызвать столько безопасности исследователя к нему внимание, насколько это возможно. Согласен. Безопасность действительно высоко в списке приоритетов; Я хотел бы видеть, обеспеченные Bitcoin адреса в подписи людей на форуме в течение года. Я уверен, что один из альтернативных blockchains примут эту идею и бежать с ним, так что большой частью ударного-аута будет там.

2 октября 2011, 5:33:20 PM	# 15
maaku Сообщения: 905 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Ну, когда мы выпускаем наши blockchains и API в течение нескольких месяцев, что будет возможность играть с Eval (). Цитата: Гэвин Андресен 02 октября 2011 года, 3:45:16 PM RE: опасайтесь OP_EVAL: Согласно, мы должны серьезно подумать о том, может ли нападавшие делать зло вещи, как создать безвредный небольшой скрипт, который оттолкнул бесконечное количество данных в стеке или что-то (позволяет видеть ... сериализовать () OP_DUP OP_EVAL бы сделать это ...). Запрет рекурсии (без OP_EVALs не допускается в OP_EVAL данных) будет, я думаю, предотвратить все это озорство. То есть по существу то, что мы делаем для нашего первого релиза, хотя это как прихлопнул муху с базуки. Это позволяет еще делать то, что было описано в этой теме до сих пор, но удаляет почти все другие интересные вещи Eval () позволит. Мы также добавили строгую типизацию, а также, что позволит нам вовремя заменить IsStandard () белый список с ProvablyDoesNotDoAnythingEvil () черным списком.

2 октября 2011, 8:42:32 PM	# 16
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Резюме дискуссии что произошло в IRC чат во второй половине дня: Есть 10 не-оп опкоды, которые явно для расширения: https://github.com/bitcoin/bitcoin/blob/master/src/script.h#L150 В настоящее время они включены, и ничего не делать. Если бы мы сделали очевидную вещь и использовали один из них OP_EVAL, то, как ни удивительно, OP_EVAL не обязательно вызовет раскол блока цепи. Зачем? Старые клиенты видят: Код: <сиг> <... сериализовать сценарий ...> DUP HASH160 <гашиш> EQUALVERIFY OP_NOP1 Новые клиенты видят: Код: <сиг> <... сериализовать сценарий ...> DUP HASH160 <гашиш> EQUALVERIFY OP_EVAL Старые клиенты будут рассматривать сделку действующую до тех пор, хэши правильное значение и не OP_FALSE, так как скрипт оценивает, как действительным, если он оставляет без ложного значения на вершине стека, когда это будет сделано. Новые клиенты будут делать полную проверку: хэш должен быть прав, а <сериализованная сценарий> должен быть действительным (должен оставить без ложного значения на вершине стека). Итак: Если модернизированные клиенты и шахтеры начинают производить операции и блоки с OP_EVAL в них, они будут приняты старыми клиентами и шахтерами действительными. Это означает, что OP_EVAL может быть поддержан как только 50 +% от сети хэширования мощности модернизированной, вместо того, чтобы требовать, что 100% от сети (клиентов и шахтеров) обновления до определенного времени или блока. Кто-нибудь хочет добровольно написать BIP, которая работает через все детали?

3 октября 2011, 1:25:51 AM	# 17
groffer Сообщения: 2 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение котировка Адреса для arbitraritly сложных транзакций фиксируются навсегда. Нет необходимости вводить более новые типы адресов. Адреса должны только быть такой же длины, как текущими, навсегда. Не так быстро. В многопартийных сделках (например, 2-из-3 покупателя / продавец / медиатор) вы не можете иметь только один участник создать сценарий, потому что другая сторона не будет защищена от фиктивных сценариев. Например, продавец может сгенерировать скрипт / хэш, который на самом деле не привлекать посредника или покупателя. Вы должны по крайней мере, пройти вокруг HASH160 три pubkeys, прежде чем осесть на сценарии. Для сценария однопартийной (например, безопасности бумажник "А и В или С") Это делает немного упрощает для отправителя. котировка Операции отправки на multisignature адреса в этой схеме имеют одинаковую длину, как обычно. Это устраняет беспокойство theymos о том, что отправители не должны быть обременены начислениями с более длинного scriptPubKeys. Вместо этого, для более сложных операций, то scriptSig больше, что означает, что владелец адреса несет расходы на потенциально повышенные пошлины. Отсрочка платы не будет действительно сделать реальную экономическую ситуацию. Это просто стоимость сделки и в эффективном рынке цена будет регулировать так, что результат для всех сторон одно и то же.

3 октября 2011, 3:28:41 AM	# 18
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: groffer от 03 октября 2011 года, 1:25:51 AM котировка Адреса для arbitraritly сложных транзакций фиксируются навсегда. Нет необходимости вводить более новые типы адресов. Адреса должны только быть такой же длины, как текущими, навсегда. Не так быстро. В многопартийных сделках (например, 2-из-3 покупателя / продавец / медиатор) вы не можете иметь только один участник создать сценарий, потому что другая сторона не будет защищена от фиктивных сценариев. Например, продавец может сгенерировать скрипт / хэш, который на самом деле не привлекать посредника или покупателя. Вы должны по крайней мере, пройти вокруг HASH160 три pubkeys, прежде чем осесть на сценарии. В сценарии медиатора, платежные поручения приходят от посредника. Что продавец может генерировать бы не имеет большого значения.

3 октября 2011, 4:40:04 AM	# 19
groffer Сообщения: 2 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: casascius от 03 октября 2011 года, 3:28:41 AM Цитата: groffer от 03 октября 2011 года, 1:25:51 AM котировка Адреса для arbitraritly сложных транзакций фиксируются навсегда. Нет необходимости вводить более новые типы адресов. Адреса должны только быть такой же длины, как текущими, навсегда. Не так быстро. В многопартийных сделках (например, 2-из-3 покупателя / продавец / медиатор) вы не можете иметь только один участник создать сценарий, потому что другая сторона не будет защищена от фиктивных сценариев. Например, продавец может сгенерировать скрипт / хэш, который на самом деле не привлекать посредника или покупателя. Вы должны по крайней мере, пройти вокруг HASH160 три pubkeys, прежде чем осесть на сценарии. В сценарии медиатора, платежные поручения приходят от посредника. Что продавец может генерировать бы не имеет большого значения. Если посредник генерирует сценарий и использовать хэш без проверки скрипта, то вы должны полностью доверять посреднику.

3 октября 2011, 1:43:53 PM	# 20
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: OP_EVAL предложение Цитата: groffer от 03 октября 2011 года, 4:40:04 AM Если посредник генерирует сценарий и использовать хэш без проверки скрипта, то вы должны полностью доверять посреднику. Так в ситуации депозитного все три стороны должны обменяться открытыми ключами и согласовать один конкретный способ положить их вместе в скрипт, что все они сходятся на (так что все они согласны на хэш скрипта). Это кажется OK-- три стороны должны обменяться открытыми ключами, прежде чем создавать какие-либо сделки в любом случае.

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW

Заголовок