Справочник разработчика
Это справочный слой: типы сообщений P2P, опкоды скриптов, названия полей RPC и структуры протокола, которые встречаются при чтении кода биткоина или расшифровке необработанной транзакции, а не при покупке чего-либо.
Он существует потому, что глоссарий разработчика Bitcoin Core, где до сих пор ищут большинство этих терминов, почти не менялся с 2021 года, и несколько его статей больше не описывают программу. Платежный протокол BIP70, который он документирует, был удален из Bitcoin Core в версии 0.20.0. Его статьи о фильтрах Блума описывают механизм, который Core перестал обслуживать по умолчанию в версии 0.19.0. Каждая из них перестроена здесь по тому, что код делает сейчас, с явно указанной поправкой, а не с тихо внесенной.
Термины делятся на группы. Типы сообщений, такие как inv, getdata и MSG_FILTERED_WITNESS_BLOCK, относятся к одноранговому протоколу. Опкоды, такие как OP_RETURN и OP_CHECKSIG, относятся к Script. Флаги хеша подписи, номера последовательностей и locktime определяют, что именно подтверждает подпись. Статьи об X509 и платежных запросах исторические, и они об этом говорят.
Большинству читателей этот раздел никогда не понадобится, и это нормально. Он здесь для того, чтобы поиск точного названия поля попадал на страницу, которая объясняет его точно, а не на заглушку из одной строки.
47 терминов. Последняя проверка: 24 сентября 2026 г.
Термины: Справочник разработчика
- Внутренний порядок байтовВнутренний порядок байтов представляет собой порядок, который биткоин использует внутри сериализованных структур: целые числа записываются начиная с младшего байта, а хеш-дайджесты записываются в том порядке, в каком их создал SHA-256.
- Данные торговца PPДанные торговца PP представляли собой непрозрачную строку байтов, которую торговец по BIP70 помещал в запрос на оплату и получал обратно без изменений, чтобы входящие биткоины можно было сопоставить с заказом.
- Заметка PPЗаметка PP (PP memo) представляла собой поле произвольного текста в UTF-8, которое BIP70 позволял продавцу, плательщику или серверу, подтверждающему получение, прикреплять к платежу, чтобы его мог прочитать человек.
- КвитанцияКвитанция в биткоине представляет собой любое доказательство того, что платеж был совершен, которое вы сохраняете: в BIP70 это было подписанное подтверждение от продавца, а на практике это идентификатор транзакции.
- Контрольная сумма дескриптораКонтрольная сумма дескриптора представляет собой восьмисимвольный код после знака # в дескрипторе вывода, код BCH, который ловит опечатки и ошибки копирования до того, как кошелек импортирует не те ключи.
- Корневой сертификатКорневой сертификат представляет собой самоподписанный якорь доверия в вершине цепочки сертификатов, и ему доверяют только потому, что его включил производитель вашей операционной системы или браузера.
- МеткаМетка в URI биткоина называет человека или организацию, которым производится платеж, а в кошельке она представляет собой личную заметку, которую вы прикрепляете к адресу или транзакции.
- Опкодтакже Opcode, Опкод передачи данных, Опкод без передачи данныхОпкод представляет собой один байт в Bitcoin Script, который указывает проверяющему узлу, что делать дальше: поместить данные в стек или выполнить одну операцию над тем, что уже находится в стеке.
- Параметр rПараметр r представляет собой добавление BIP72 к URI биткоина, которое заменяет адрес платежа на URL, с которого ваш кошелек должен получить подписанный запрос.
- Подпись SSLПодпись SSL (SSL signature) представляет собой название, которое BIP70 дал байтам, подписывающим PaymentRequest ключом сертификата веб-сервера, и это обозначение было неточным уже в момент, когда его записали.
- Порядок байтов RPCПорядок байтов RPC означает обратный порядок, в котором программное обеспечение биткоина отображает хеши из 32 байт, и именно в такой форме представлен каждый ID транзакции, который вы копируете из кошелька или обозревателя блоков.
- Промежуточный сертификатПромежуточный сертификат стоит между корневым и конечным: его подписывает корневой, а он подписывает конечный, поэтому приватный ключ корневого сертификата может оставаться офлайн и не использоваться.
- Протокол платежей (BIP70)также Протокол платежей, Payment protocol, BIP70Протокол платежей (BIP70) был попыткой биткоина заменить простые адреса подписанными платежными запросами, заверенными сертификатами, а Bitcoin Core удалил последнюю его поддержку в версии 0.20.0.
- Сертификат листаСертификат листа представляет собой сертификат конечной сущности, который предъявляет сервер, с которым вы на самом деле установили соединение, и он подтверждает контроль над доменным именем, но ничего не говорит о людях, стоящих за ним.
- Сертификат X.509также X.509 certificate, TLS-сертификатСертификат X.509 представляет собой подписанный файл, который привязывает публичный ключ к имени и сроку действия, и это формат, лежащий в основе каждого HTTPS-соединения, которое вы устанавливаете с биржей.
- Скрипт погашениятакже Redeem scriptСкрипт погашения представляет собой полный контракт расходования, скрытый за выходом pay-to-script-hash: его предоставляет тот, кто тратит, в конце скрипта подписи, и его хеш вычисляют, чтобы проверить совпадение.
- Скрипт подписитакже scriptSig, Скрипт разблокировкиСкрипт подписи представляет собой данные разблокировки, которые вход несет, чтобы удовлетворить скрипт публичного ключа выхода, который он тратит, а в современных входах SegWit он пуст.
- Скрипт публичного ключатакже Pubkey script, scriptPubKey, скрипт блокировкиСкрипт публичного ключа представляет собой короткий фрагмент Bitcoin Script, прикрепленный к каждому выходу транзакции и задающий условия, которые должны быть выполнены, прежде чем биткоины в этом выходе снова смогут перемещаться.
- Скрипт свидетеляСкрипт свидетеля хранит реальные условия расходования выхода P2WSH и передается внутри свидетеля, где его байты учитываются по четверти обычной стоимости.
- Скрипт PPСкрипт PP был обязательным полем в выходе BIP70 и содержал необработанный скрипт блокировки, который плательщик должен был воспроизвести, те самые байты, которые попадают в выход транзакции.
- Функция точкиФункция точки превращает приватный ключ в публичный, умножая генераторную точку secp256k1 на это число, и представляет собой односторонний шаг, на котором строится каждый адрес биткоина.
- Цепочка сертификатовЦепочка сертификатов представляет собой упорядоченный список сертификатов, который связывает сертификат, предъявленный сервером, с корневым сертификатом, которому ваше устройство уже доверяет, причем каждое звено подписано следующим.
- Bitcoin Scriptтакже ScriptBitcoin Script представляет собой небольшой стековый язык, который присутствует в каждом выходе биткоина и задает условия, которые кто-либо должен выполнить, прежде чем эти биткоины можно будет снова потратить.
- CompactSizeтакже Compact size unsigned integer, беззнаковое целое CompactSize, VarIntCompactSize представляет собой целое число переменной длины, которым биткоин предваряет счетчики и длины в сериализованных данных: один байт для значений ниже 253 и до девяти байтов для остальных.
- MSG_BLOCKMSG_BLOCK является типом инвентаря 2, кодом, который узел помещает в сообщение getdata, чтобы запросить у пира целый блок по его хешу.
- MSG_CMPCT_BLOCKMSG_CMPCT_BLOCK, тип инвентаря 4, представляет собой код только для запросов: он никогда не появляется в анонсе и допустим лишь внутри сообщения getdata, отправленного пиру, который согласился на него заранее.
- MSG_FILTERED_WITNESS_BLOCKТип фильтрованного блока со свидетелем присутствует в списке зарезервированных типов из BIP144 и в перечислении исходного кода Bitcoin Core, при этом ни в одном из этих мест за ним не стоит реализация.
- MSG_TXMSG_TX помечает запись в инвентаре как транзакцию, с кодом типа 1, и именно так ваш неподтвержденный платеж объявляется пирам, прежде чем кто-либо из них увидел его содержимое.
- MSG_WITNESS_BLOCKТип инвентаря с данными свидетеля (witness block) описывает, как узел, поддерживающий segwit, запрашивает блок в расширенной сериализации, со всеми подписями на месте, а не удаленными.
- MSG_WITNESS_TXЗапрос транзакции с данными свидетеля, отправляемый как getdata, предписывает пиру вернуть указанную транзакцию с приложенными данными подписи, а не без них.
- OP_CHECKMULTISIGOP_CHECKMULTISIG проверяет группу подписей по списку публичных ключей за один шаг, а в расходах Taproot он не может использоваться вообще, потому что блокирует пакетную проверку.
- OP_CHECKSIGOP_CHECKSIG снимает со стека публичный ключ и подпись и проверяет, что подпись покрывает эту транзакцию; именно эта проверка на деле доказывает, что биткоины принадлежат вам.
- OP_DUPOP_DUP копирует верхний элемент стека, чтобы его можно было использовать дважды, и поэтому стандартный скрипт pay-to-public-key-hash может и вычислить хеш вашего публичного ключа, и проверить подпись по нему.
- OP_EQUALOP_EQUAL сравнивает два верхних элемента стека побайтово и помещает результат true или false; это последний опкод в любом выходе pay-to-script-hash.
- OP_EQUALVERIFYOP_EQUALVERIFY сравнивает два верхних элемента стека и мгновенно прерывает скрипт, если они различаются; именно так расходование по старому шаблону доказывает, что предъявлен правильный публичный ключ.
- OP_HASH160OP_HASH160 применяет SHA-256 к верхнему элементу стека, а затем RIPEMD-160 к полученному результату и оставляет дайджест из 20 байт, тот же отпечаток, который несет внутри каждый адрес, начинающийся с 1 или 3.
- OP_RETURNOP_RETURN является опкодом, который делает выход транзакции заведомо неспособным к расходованию, что позволяет записать в блокчейн небольшой объем произвольных данных, не раздувая набор активных монет.
- OP_VERIFYOP_VERIFY снимает верхний элемент стека и прерывает весь скрипт, если этот элемент не является истинным, превращая любую проверку в Bitcoin Script в жесткое требование.
- PaymentDetailsPaymentDetails является внутренним сообщением BIP70, которое действительно описывало платеж: на какие выходы платить, сколько, когда истекает срок действия запроса и куда отправлять подписанную транзакцию.
- PaymentRequestPaymentRequest представляет собой внешний конверт BIP70: он оборачивает сериализованный блок PaymentDetails вместе с цепочкой сертификатов и подписью, чтобы плательщик мог проверить, кто именно выставил требование.
- PKIтакже Инфраструктура открытых ключейPKI, или инфраструктура открытых ключей, представляет собой систему удостоверяющих центров, сертификатов и хранилищ доверенных сертификатов, которая позволяет программному обеспечению решать, действительно ли открытый ключ принадлежит имени, с которым он связан.
- PP amountPP amount представляло собой поле в сатоши внутри выходной записи BIP70; оно устанавливалось в ноль, когда продавец хотел, чтобы сумму отправки выбрал плательщик.
- PP expiresPP expires представлял собой необязательную временную метку Unix в сообщении PaymentDetails протокола BIP70, которая указывала кошельку прекратить исполнение запроса после наступления этого момента.
- PP pki dataPP pki data представляло собой поле в запросе на платеж BIP70, которое содержало сертификаты продавца в кодировке DER: сначала конечный сертификат, за ним промежуточные, а корневой отсутствует.
- PP pki typePP pki type был строкой из одного слова в запросе на оплату BIP70, которая указывала, как продавец подписал его: none, x509 с SHA-256 или x509 с SHA-1.
- QR-код URIQR-код URI представляет собой квадратный черно-белый узор, в котором закодирован URI bitcoin:, чтобы камера могла прочитать адрес и сумму, которые иначе пришлось бы вводить вручную.
- URI биткоинатакже BIP21URI биткоина собирает данные платежа в одну строку, по которой можно щелкнуть; она начинается с bitcoin: и может содержать адрес, сумму и метку.
Остальные 13 разделов
- ОсновыЧто такое биткоин, что такое сатоши и несколько идей, на которых построен весь остальной глоссарий.
- Адреса и ключиКуда отправляются биткоины, чем на самом деле управляет приватный ключ и как одна сид-фраза порождает тысячи адресов.
- Кошельки и хранениеГорячие, холодные, кастодиальные и мультисиг: что каждый из них меняет в вопросе о том, кто может перемещать ваши биткоины.
- Приватность и безопасностьАтаки, при которых у людей забирают биткоины, а также привычки и инструменты, которые их останавливают.
- Транзакции и комиссииИз чего состоит биткоин-транзакция, почему она стоит столько, сколько стоит, и как сдвинуть зависшую.
- Покупка и биржиТипы ордеров, спреды и таблицы комиссий: словарь, которым пользуется биржа, пока берет с вас плату.
- Рынки и инвестицииРыночная капитализация, волатильность и спотовые ETF. Язык цены без прогнозов цены.
- Майнинг и консенсусКак создаются новые блоки, что регулирует сложность и почему правила соблюдаются, хотя никто не стоит во главе сети.
- Протокол и обновленияSegWit, Taproot, софт-форки и BIP: как меняется биткоин и кто решает.
- Lightning и layer 2Платежные каналы, инвойсы и маршрутизация: способ перемещать биткоин, не платя за место в блоке.
- Регулирование и налогиKYC, Travel Rule, MiCA и прирост капитала: правила, которые доходят до вашего счета и вашей налоговой декларации.
- Культура и историяMt. Gox, генезис-блок, HODL, а также события и сленг, которые сформировали то, как люди говорят о биткоине.
- Узлы и ПОBitcoin Core, полные узлы, прунинг и RPC: программы, которые обеспечивают соблюдение правил.
Часто задаваемые вопросы
Для кого этот раздел?
Для всех, кто читает исходный код биткоина, расшифровывает необработанную транзакцию или работает с протоколом P2P и интерфейсом RPC. Это справочный слой, а не слой покупки, и ничто в нем не нужно, чтобы владеть биткоином или тратить его.
Что такое Bitcoin Script?
Небольшой стековый язык, который решает, можно ли потратить биткоин. Циклов в нем нет намеренно, благодаря чему стоимость каждого скрипта предсказуема до его запуска. Большинство транзакций используют один из нескольких стандартных шаблонов.
Почему порядок байтов постоянно меняется?
Потому что биткоин показывает хеши в порядке, обратном тому, в котором хранит. Внутренний порядок байтов используется протоколом, а вывод RPC и обозреватели блоков его переворачивают. Смешивание этих двух порядков является классической первой ошибкой.
Где находится авторитетная документация?
В исходном коде и в BIP, а не на каком-то одном сайте. Статьи здесь ссылаются на спецификацию там, где она есть, и исправляют старую документацию разработчиков там, где она устарела, а не повторяют ее.