Блокчейн: глоссарий терминов

0 70

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

Содержание:

A  B  C  D  E  G  H  I  J  L  M  N  P  R  S  T  U  V  W  X

А  Б  В  Г  Д  Е  З  К  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Э  Я

 

A

ASIC (Application-Specific Integrated Circuit)

Специализированная интегральная схема (Application-Specific Integrated Circuit, или ASIC) — это специальный микрочип, созданный только для одной цели. ASIC-майнеры — это аппаратные устройства, содержащие такие чипы и предназначенные исключительно для хеширования блоков, чтобы найти валидный proof-of-work. В сущности, единственная функция, которую выполняют эти микрочипы, — это хеш-функция SHA-256 на заголовке блока.

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

a – z ↩

 

B

Base58

Base58 — это схема кодирования с алфавитом из 58 символов, включающим прописные и строчные буквы и цифры 1–9. Алфавит Base58 не включает ноль, прописную букву «O», прописную «I» и строчную «i», чтобы избежать путаницы при прочтении.

Вариант Base58, называемый Base58Check, используется для представления биткойн-адресов старого типа и секретных ключей в формате WIF. Base58Check идентичен Base58, с добавлением 4-байтовой контрольной суммы и префикса версии. Префикс версии указывает на то, какие данные представлены. Pay-to-Public-Key-Hash (P2PKH) адреса имеют префикс 1, P2SH-адреса — префикс 3, а секретные ключи — префикс 5.

a – z ↩

Bech32 и bech32m

Bech32 — это схема кодирования, используемая для создания SegWit-адресов и счетов Lightning. Алфавит Bech32 содержит 32 символа, включая строчные буквы a–z и цифры 0–9, исключая число 1 и буквы «b», «i», «o», чтобы избежать путаницы при прочтении. Bech32 также включает в себя механизм обнаружения ошибок.

После того как была выявлена проблема с обнаружением ошибок в bech32 при будущих обновлениях в некоторых редких обстоятельствах, был предложен новый модифицированный формат bech32 — bech32m. Bech32m будет использоваться в taproot и будущих обновлениях, затрагивающих скрипты на основе segwit, что потребует от кошельков и сервисов, реализовавших поддержку оплаты на адреса исходного формата bech32, обновиться, если они хотят поддерживать оплату на taproot-адреса и вероятные будущие обновления. Чтобы продолжать отправлять транзакции на исходные (v0) segwit-адреса скриптам типа P2WPKH и P2WSH, обновления не требуется.

a – z ↩

BIP (Bitcoin Improvement Proposal)

Предложение по улучшению биткойна (Bitcoin Improvement Proposal, или BIP) — это формальное предложение по изменению Биткойна. Все значимые обновления и улучшения безопасности поступают в кодовую базу Биткойна через BIP. Такие обновления, как SegWit, HD-кошельки, PSBT и многие другие, все изначально были представлены в виде BIP, которые прошли процесс рассмотрения и обсуждения в сообществе, прежде чем быть принятыми. Однако не все BIP предполагают внесение изменений в программный код. Некоторые из них, такие как стандарт резервного копирования мнемонических фраз, устанавливают стандарты для использования в других проектах, связанных с Биткойном.

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

a – z ↩

Bitcoin Core

Bitcoin Core — это эталонная реализация исходного кода Биткойна, то есть все остальные реализации обращаются к Bitcoin Core за методологическими принципами и лучшими практиками в отношении поддержания консенсуса и обновления протокола. Именно этот исходный код загружает большинство пользователей.

Bitcoin Core предоставляет программное обеспечение для ноды и кошелька, хотя большинство пользователей предпочитают использовать Bitcoin Core для нод и стороннее ПО для кошельков. Альтернативное ПО для нод существует, но реализация Bitcoin Core является доминирующей. Загрузить программное обеспечение Биткойна, чтобы запустить свою ноду, можно сделать на сайте Bitcoin Core или на их странице в Github.

Bitcoin Core было создано Сатоши Накамото, и хотя право собственности впоследствии было передано и в проект было добавлено множество обновлений, последняя версия ПО Bitcoin Core по-прежнему совместима с оригинальной версией Сатоши.

Bitcoin Core — проект с открытым исходным кодом. Это означает, что любой может скопировать его код и редактировать эту копию по своему усмотрению. Если разработчик хочет внести улучшения в код Биткойна, он может опубликовать предлагаемые изменения и предложить включить их в Bitcoin Core. Множество разработчиков вносят свой вклад в Bitcoin Core через написание кода, код-ревью и обсуждение предложений. Однако авторитативной организации, которая бы оплачивала эту работу, не существует. Вместо этого, деятельность разработчиков частично финансируется за счет пожертвований и грантов со стороны биткойн-компаний и частных лиц.

Подробнее о Bitcoin Core

a – z ↩

Bitcoin-Qt

Bitcoin-Qt — название графического пользовательского интерфейса (GUI), входящего в состав программного пакета Bitcoin Core. Bitcoin-Qt предлагает визуальные средства управления функциями ноды и кошелька Bitcoin Core. Постфикс «Qt» происходит от названия фреймворка Qt, использовавшегося для создания интерфейса.

a – z ↩

Bitcoind

Bitcoind — это название программы, запускающей bitcoin-ноду и кошелек. Эта программа поставляется с программным пакетом Bitcoin Core и используется на большинстве нод в сети Bitcoin. Суффикс «d» в bitcoind — это сокращение от daemon; так называются службы, запускаемые операционной системой и работающие в фоновом режиме без прямого взаимодействия с пользователем.

a – z ↩

 

С

Child-Pays-for-Parent (CPFP) («ребенок платит за родителя»)

Child-Pays-for-Parent (CPFP) — это механизм ускорения обработки транзакций с малой комиссией, как и Replace-By-Fee (RBF). Если Replace-By-Fee позволяет ускорить обработку и подтверждение транзакции отправителю, то Child-Pays-for-Parent позволяет получателю ускорить подтверждение входящей транзакции.

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

a – z ↩

Coinbase-транзакция (Coinbase Transaction)

Coinbase-транзакция — это первая транзакция каждого блока. В coinbase-транзакции распределяется субсидия на блок, на сегодня составляющая 6,25 BTC/блок, а также собираются совокупные комиссии со всех транзакций в блоке.

Поскольку в этой транзакции создаются новые биткойны, coinbase-транзакция действительна, даже не имея каких-либо входов. Для примера можно взглянуть на эту coinbase-транзакцию блока #650 000 на Blockstream: входов она не имеет, а единственный выход содержит ₿6,25 субсидии на блок плюс ₿0,244131 комиссий, собранных майнером.

a – z ↩

CoinJoin

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

Для того чтобы собрать CoinJoin-транзакцию, пользователи совместно вносят в нее свои входы и получают соответствующие количества биткойнов в качестве какого-то количества выходов одинакового номинала. Например, если 5 пользователей добавляют в CoinJoin-транзакцию входы номиналом 1, 2, 3, 4 и 5 BTC, то в транзакции будет 5 входов на общую сумму 15 BTC, которые будут перераспределены на 15 выходов, по 1 BTC каждый. Поскольку все выходы такой транзакции имеют одинаковый номинал, для внешнего наблюдателя невозможно достоверно определить, какому из пользователей принадлежит каждый из выходов на 1 BTC.

a – z ↩

CoinSwap

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

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

Подробнее о CoinSwap и о том, как  он работает

a – z ↩

CPFP carve out

CPFP carve out (исключение для CPFP) — политика ретрансляции транзакций, реализованная в Bitcoin Core и позволяющая одной транзакции умеренно превышать пределы размера пакета и глубины узла, если эта транзакция имеет одного неподтвержденного предшественника.

Это позволяет протоколам, работающим на основе двухсторонних контрактов (например, Lightning Network) гарантировать, что обе стороны контракта будут иметь возможность ускорить обработку транзакции по схеме «ребенок платит за родителя» (CPFP). Одна сторона может использовать этот способ ускорения транзакции вплоть до исчерпания лимитов для пакета, однако не добьется при этом пиннинга транзакции, поскольку вторая сторона может воспользоваться правилом CPFP carve out.

Первичный код и документация:

  • CPFP carve-out proposal
  • Bitcoin Core PR#15681: [mempool] Allow one extra single-ancestor transaction per package
  • a – z ↩

    D

    DER формат

    Формат Distinguished Encoding Rules (особые правила кодирования), или DER, — это стандарт, используемый в Биткойне для кодирования подписей ECDSA. Подпись состоит из случайного числа r и самой подписи, называемой значением s. Типичная подпись Биткойна имеет длину 71 байт, так как к подписи DER добавляется однобайтовый sighash-флаг, и эти байты представлены в шестнадцатеричном формате.

    Формат DER начинается с префиксного байта 0x30, за которым следует длина подписи. Далее следует байт 0x02, за ним длина значения r, а затем само значение r. Дальше — байт 0x02, длина значения s и само значение s. Если первый байт больше 0x80, то к значениям r и s, добавляется дополнительный байт 0x00. Таким образом, хотя значения r и s имеют длину 32 байта, в формате DER они иногда занимают 33 байта.

    a – z ↩

    DEX (Decentralized Exchange)

    Назначение децентрализованных бирж (DEX) состоит в том, чтобы обеспечить обмен цифровыми активами, не вынуждая пользователей жертвовать конфиденциальностью или доверять бирже хранение своих средств. DEX предлагают доступ к обмену без прохождения процедур AML (Anti-Money Laundering), то есть они не запрашивают у пользователей удостоверение личности, адрес или номер телефона.

    Децентрализованные биржи различаются по степени децентрализации: некоторые из просто не хранят средства пользователей, но имеют централизованный аппарат управления для разрешения споров, другие представляют собой полностью децентрализованные протоколы. Большинство DEX совершают сделки непосредственно между пользователями, не являясь в них посредниками и не контролируя их ход.

    Часто децентрализованные биржи требуют, чтобы продавец внес цифровые монеты на адрес с мультиподписью 2-из-3, для которого каждая из сторон — продавец, покупатель и DEX — имеет свой уникальный ключ. После того как продавец цифрового актива получает платеж, продавец и покупатель подписывают транзакцию, отправляя монеты с multisig-адреса на адрес покупателя. Если какая-либо из сторон нарушает соглашение, потерпевший может обратиться к DEX, которая использует свой ключ для разрешения спора и высвобождения средств с multisig-адреса.

    a – z ↩

    DLC (Discreet Log Contract)

    Discreet Log Contract (DLC) — это форма биткойн-транзакции, использующей оракул для выполнения смарт-контракта. По сути, DLC позволяют сторонам использовать блокчейн Биткойна для размещения ставок. Чтобы создать DLC, две стороны блокируют средства на multisig-адресе. Эти средства могут быть потрачены только в том случае, если оракул опубликует определенную информацию в определенное время. Оракулом для DLC может быть любая форма публикуемых в интернете данных — например, публикация на веб-сайте результата спортивного матча или биржевой листинг цены актива.

    Слово discreet (осмотрительный, тактичный) в названии технически является искаженным написанием слова discrete (дискретный). Однако с самого изобретения DLC используется именно такое написание.

    DLC предлагают улучшение по сравнению с другими типами смарт-контрактов в том, что их ончейн-след ничем не отличается от обычной multisig-транзакции. Таким образом, они не требуют каких-либо особых изменений в протоколе Биткойна, кроме схем Шнорра, введенных с обновлением Taproot. Однако DLC не решают полностью проблему оракула — невозможность бездоверительным образом включить в смарт-контракт реальные данные, — поскольку в отношении публикации достоверных данных они по-прежнему полагаются на доверенного оракула.

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

    Например, если Элис и Боб хотят настроить DLC для ставки на результат подбрасывания монеты, они сначала создают транзакцию финансирования, в которой оба отправляют биткойны — скажем, по 1 BTC каждый — на multisig-адрес 2-из-2. Затем Элис и Боб получают открытые ключи, закрытые ключи к которым создаются из подписи оракула для обоих исходов подбрасывания монеты — орла или решки. Обратите внимание, что эти закрытые ключи — не тот закрытый ключ, что использовался для создания подписей событий. Подпись не может быть использована для получения закрытого ключа, который ее создал.

    С помощью этих открытых ключей Элис и Боб создают две commitment-транзакции, называемые транзакциями исполнения обязательства (Contract Execution Transaction, или CET), одна из которых отправляет 2 BTC из транзакции финансирования на открытый ключ для «орла», а другая — на открытый ключ для «решки». Для отправки каждой из этих транзакций нужны подписи от Элис и Боба и ключ для «орла» или «решки». Поскольку ни у Элис, ни у Боба нет закрытого ключа для «орла» или «решки», эти транзакции имеют только 2 из 3 необходимых подписей, и пока не могут быть записаны в блокчейн.

    После того как оракул определит результат броска монеты — скажем, «орел», — он публикует соответствующую подпись, и Элис или Боб используют ее для получения закрытого ключа для «орла». Элис и Боб теперь могут подписать только CET, отправив биткойны тому, кто поставил на «орел». Подписанная CET-транзакция публикуется в блокчейне, и обладатель выигрышной ставки получает 2 BTC. CET, требующая подписи для «решки», устаревает и отбрасывается.

    Чтобы создать для проигравшего стимул подписать транзакцию, обе стороны добавляют к транзакции финансирования еще один биткойн. Если ставка составляет 1 BTC, то каждая сторона может поставить по 1,5 BTC. Впоследствии победитель получит 2,5 BTC, а проигравший — возврат своих 0,5 BTC. Это позволяет реализовать условие временной блокировки, в которой, если проигравший не подписал и не опубликовал транзакцию к определенному сроку, победитель может дополнительно истребовать 0,5 BTC обеспечения, внесенного проигравшим.

    a – z ↩

     

    E

    ECDSA

    Elliptic Curve Digital Signature Algorithm (алгоритм цифровой подписи, основанный на эллиптических кривых), или ECDSA, — это криптографическая схема для создания цифровых подписей с помощью открытого и закрытого ключей. Все ключи и подписи в Биткойне в настоящее время генерируются с помощью ECDSA.

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

    Эллиптическая кривая-это определенная математическая функция общего формата y^2 = x^3 + ax + b. В случае Биткойна эта кривая имеет определенное уравнение: y^2 = x^3 + 7, поскольку a = 0 и b = 7. Любая точка на этой эллиптической кривой, называемой secp256k1, является валидным открытым ключом Биткойна.

    Чтобы сгенерировать открытый ключ, пользователь должен сгенерировать секретный ключ, который представляет собой просто большое число. Затем этот секретный ключ умножается на определенную точку на кривой, называемую точкой-генератором (generator point), и таким образом получается открытый ключ. Эта операция умножения представляет собой точечное умножение, которое отличается от обычного. Критически важно, что точечное деление не поддается расчету, так что открытый ключ в настоящее время не может быть использован для получения секретного ключа, что и обеспечивает безопасность схемы ECDSA.

    a – z ↩

    Eltoo

    Eltoo — произносится как английское L2 — это предлагаемое обновление для Биткойна, основная цель которого состоит в улучшении решений второго уровня и в первую очередь Lightning Network.

    Eltoo подразумевает введение в протокол Биткойна нового sighash-флага под названием SIGHASH_NOINPUT. Новый sighash-флаг позволит биткойн-подписи фиксировать состояние транзакций без указания txid входа.

    Оставление txid неопределенным обеспечивает бо́льшую гибкость для транзакций. Это означает, что дочерние транзакции могут быть подписаны до того, как их родительские транзакции будут опубликованы в блокчейне.

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

    Без Eltoo каждая транзакция в этом процессе может быть подписана только после создания предыдущей. С Eltoo, расчетая транзакция может быть подписана одновременно с транзакцией финансирования. Это устраняет необходимость в Lightning Network penalty, значительно упрощая защиту Lightning Network от двойного расходования.

    Поскольку Eltoo подразумевает введение нового sighash-флага, это изменяет правила консенсуса протокола, а значит, требует софт-форка.

    a – z ↩

     

    G

    Generic signmessage

    Generic signmessage — это метод, позволяющий кошелькам подписывать или частично подписывать сообщение для любого скрипта, из которого они предположительно могут тратить биткойны.

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

    При подписании для (legacy) P2PKH-адресов, BIP322, вместо generic, использует традиционный signmessage формат, впервые реализованный в ранней версии ПО Биткойна, что делает предложение обратно совместимым с существующим ПО, проверяющим подписанные сообщения для P2PKH-адресов.

    a – z ↩

     

    H

    HD-кошелек (иерархический детерминированный кошелек)

    HD (от Hierarchical Deterministic) кошельками называют кошельки, которые получают открытый и секретный ключи на основе seed-BIP 32 (Github). До того всякий раз, когда пользователю требовался новый адрес, большинство кошельков генерировали несвязанные ключи. Такой формат, называемый Just-a-Bunch-of-Keys (JBOK), требовал, чтобы кошелек создавал резервную копию каждого отдельного ключа, что было значительным неудобством как для кошельков, так и для пользователей. Бэкап HD-кошелька, с другой стороны, можно создать, сохранив только одно seed-значение длиной в 64 байта.

    Термин «иерархический» описывает древовидную структуру ключей: из seed-значения кошелька генерируется единственный главный (верхнего уровня) ключ, который используется для получения дочерних ключей, каждый из которых может создавать собственные дочерние ключи.

    Каждый дочерний ключ может быть описан через его путь получения, содержащий информацию о глубине и индексе ключа — о его местоположении в древовидной структуре. Путь получения указывает кошельку, как получить тот или иной ключ. Главный ключ обозначается просто как ‘m’. Первый дочерний элемент главного ключа имеет путь получения «m/0», а пятый дочерний элемент этого дочернего ключа будет иметь путь получения «m/0/4». Глубина каждого дочернего элемента определяется количеством уровней, каждый из которых отделяется слэшем, между ним и главным ключом. Индекс каждого дочернего элемента — это его номер на определенном уровне, начиная с нуля. Например, ключ «m/0/4» имеет глубину 2 и индекс 4.

    a – z ↩

     

    HTLC (Hashed Time Locked Contract)

    Контракт с временной блокировкой — это биткойн-транзакция, включающая в себя временную блокировку. При хешировании такой биткойн-транзакции получается хешированный контракт с временной блокировкой (Hashed Time Locked Contract, или HTLC). Такие контракты используются в основном в Lightning Network, обеспечивая возможность маршрутизации lightning-платежей между несколькими нодами. Lightning-маршрутизация позволяет двум сторонам совершать бездоверительные транзакции без прямого канала между ними, используя вместо него каналы-посредники.

    a – z ↩

     

    I

    ICO (Initial Coin Offering, первичное предложение койнов)

    ICO необязательно связано с криптовалютами, а относится скорее к предложению цифровых активов, которые могут представлять самые разные вещи – как, например, право собственности на долю в компании, приложении, на произведение искусства и т. д. ICO проводятся как способ привлечения капитала для запуска нового койна, приложения или сервиса. Считается, что ICO являются эквивалентом от криптоиндустрии первичного размещение акций (IPO).

    a – z ↩

     

    J

    JBOK (Just-a-Bunch-of-Keys)

    Just-a-Bunch-of-Keys («просто-связка-ключей»), или JBOK, — это форма биткойн-кошелька, который по запросу пользователя случайным образом генерирует новые ключи, не связанные с предыдущими. Такой дизайн предшествовал иерархическим детерминированным (HD) кошелькам и был гораздо менее эффективным. Для резервного копирования JBOK-кошелька пользователю необходимо было сохранить каждый отдельный секретный ключ, используемый кошельком, притом что возможное количество таких ключей не имеет верхней границы. JBOK- были вытеснены HD-кошельками, потому что для создания полноценной резервной копии HD-кошелька можно использовать единственное seed-значение, к тому же доступность расширенных ключей предполагает значительную полезность для пользователей.

    a – z ↩

    Joinpool

    Joinpool — это конструкция, позволяющая нескольким пользователям бездоверительным образом совместно владеть одним UTXO. При расходе этого выхода по записи в блокчейне невозможно определить, какой (или какие) из участников пула потратил средства. Joinpool может использовать предподписанные транзакции или предлагаемые функции протокола, позволяющие каждому участнику в любое время в одностороннем вывести средства из пула.

    a – z ↩

     

    L

    Lightning Network

    Lightning Network — это протокол, предназначенный для совершения быстрых и дешевых транзакций c BTC. Пока он еще находится на стадии эксперимента, но показывает многообещающие возможности масштабирования Биткойна. Протокол Lightning построен на основе двунаправленных платежных каналов, позволяющих двум сторонам отправлять друг другу быстрые дешевые платежи без необходимости регистрировать каждую транзакцию в основном блокчейне. Кроме того, каналы можно объединять в единую сеть для маршрутизации платежей между сторонами, не имеющими прямого соединения.

    Чтобы открыть один из таких двунаправленных платежных каналов, два пользователя отправляют BTC на multisig-адрес для совместного управления, записав эту транзакцию в блокчейне Bitcoin. BTC на таком адресе можно мгновенно и бесплатно ребалансировать между двумя сторонами без необходимости регистрировать ончейн каждую из этих внутренних транзакций.

    Например, Элис и Боб оба вносят на совместный адрес по 0,5 BTC. В Lightning Network отобразятся соответствующие балансы. После этого, если Элис хочет отправить Бобу 0,1 BTC, она обновляет состояние этого совместного адреса. Теперь у Боба есть 0,6 BTC, а у Элис 0,4 BTC. Эта транзакция еще не записана в блокчейн Биткойна, и пользователи могут совершать между собой еще сколь угодно много транзакций путем обновления соответствующих балансов. Только когда они захотят закрыть канал, в блокчейн Биткойна отправляется еще одна заключительная транзакция, представляющая собой результирующую сумму всех внутренних транзакций между этими двумя пользователями.

    Подробнее о Lightning Network

    a – z ↩

    Lightning Network penalty

    Штрафы (penalty) Lightning Network — это механизм, препятствующий попыткам двойной траты биткойнов с использованием Lightning Network (LN). В настоящее время LN-penalty конфискует весь баланс участника lightning-канала, пытающегося опубликовать недопустимое состояние с целью кражи средств.

    Lightning Network использует для трансфера биткойнов между сторонами полностью подписанные биткойн-транзакции. Эти транзакции не транслируются и не добавляются обычным образом в блокчейн Биткойна. Однако, поскольку они являются валидными транзакциями, любая из них в любое время может быть передана в блокчейн. Это приведет к закрытию lightning-канала и сделает недействительными все lightning-транзакции, произошедшие после.

    Этот механизм может быть использован для двойного расходования биткойнов через Lightning. Например, у Элис и Боба есть открытый lightning-канал, в котором каждый из них контролирует 0,25 BTC. Обе стороны в этот момент держат commitment-транзакцию (транзакцию-обязательство), в которой каждой из сторон предназначается по 0,25 BTC. Затем Элис отправляет Бобу через Lightning 0,05 BTC, после чего ее баланс составляет 0,2 BTC, а Боба — 0,3 BTC. И новая commitment-транзакция отражает это состояние балансов. Однако Элис может взять и опубликовать в блокчейне старую commitment-транзакцию с прежним состоянием балансов. Каждая сторона в этом случае получит по 0,25 BTC, что фактически отменит транзакцию на 0,05 BTC, отправленную Элис Бобу.

    Чтобы предотвратить такое злонамеренное поведение, протокол Lightning позволяет Бобу в течение определенного времени опубликовать в блокчейн более новую commitment-транзакцию и забрать не только те 0,05 BTC, которые Элис ему отправляла, но и все 0,5 BTC, внесенные в канал обеими сторонами. В наказание за попытку двойного расходования со стороны Элис Боб забрал бы всю ее долю в канале.

    a – z ↩

    Lightning-канал (lightning channel)

    Lightning-канал — это соединение между двумя сторонами, двумя участниками сети, и Lightning Network состоит из тысяч таких каналов. Lightning-транзакции пересылаются по каналам туда и обратно, изменяя балансы (в BTC) каждой из сторон данного канала. Все BTC в отдельном канале принадлежат одной из двух его сторон. Lightning-каналы называются двунаправленными платежными каналами, потому что обе стороны канала могут отправлять и получать по нему платежи.

    Чтобы открыть lightning-канал, две стороны — скажем, Элис и Боб — совместно создают multisig-адрес 2-из-2. Чтобы потратить любые отправленные на такой адрес BTC, потребуется две подписи, по одной с каждой стороны. Представим, что Элис и Боб открыли канал и внесли в него по 1 BTC каждый. Теперь, если Элис хочет заплатить Бобу 0,5 BTC, она подписывает транзакцию расходования с multisig-адреса. Эта транзакция имеет два выхода: Боб получит 1,5 BTC и Элис получит 0,5 BTC. Поскольку для расхода средств с multisig-адреса требуются две подписи, эта транзакция еще не является валидной, и Элис не может транслировать ее в сеть Биткойна. Вместо этого, она отправляет частично подписанную транзакцию, называемую транзакцией-обязательством (commitment transaction), Бобу, который ее сохраняет, но тоже не транслирует. Элис заплатила Бобу 0,5 BTC, но Боб не получил окончательный расчет по этому платежу в блокчейне Биткойна. Вот почему lightning-транзакции так дешевы: они не требуют подтверждения каждой транзакции путем включения ее в блок майнерами.

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

    a – z ↩

    Lightning-счет (Lightning invoice)

    Lightning-счет подобен обычному счету в том смысле, что он служит запросом на оплату. Lightning-счет включает в себя сумму к оплате, место назначения платежа, метаданные и сообщение.

    Счета в Lightning служат своего рода эквивалентом адресов в том смысле, что и те и другие сообщаются получателем платежа плательщику для облегчения платежа. Из-за своей длины, lightning-счета обычно представляются в виде QR-кодов.

    a – z ↩

    Liquid Network

    Liquid Network — это сайдчейн-протокол, построенный поверх блокчейна Биткойна. Liquid Network была создана компанией Blockstream, но управляется федерацией сторон и работает на блокчейн-платформе с открытым кодом под названием Elements. Liquid Network предлагает несколько функций, отсутствующих в основном блокчейне Bitcoin:

  • Быстрые и окончательные расчеты. В Liquid Network блоки добавляются ровно каждую минуту, в сравнении с 10-минутным вероятностным интервалом Биткойна. Реорганизации протоколом не допускаются, поэтому двух подтверждений достаточно, чтобы считать расчет окончательным.
  • Множество различных активов. Третьи стороны могут выпускать на сайдчейне Liquid свои токены — токенизированные акции, стейблкойны и т. д.
  • Конфиденциальные транзакции. Liquid Network позволяет совершать более конфиденциальные транзакции, скрывая их сумму и тип актива. В остальном реестр Liquid полностью открыт и публичен.
  • BTC в Liquid Network называются L-BTC или Liquid Bitcoin, и пользование ими аналогично внесению наличных в кассе казино в обмен на фишки. Чтобы использовать BTC в Liquid Network, пользователь должен заблокировать их в транзакции привязки (peg-in). Это делается путем внесения BTC на адрес, сгенерированный Liquid Network. После подтверждения депозита пользователю зачисляется эквивалентная сумма L-BTC, и он получает возможность совершать транзакции в Liquid Network. Чтобы разблокировать и получить обратно свои BTC, пользователь должен внести на соответствующий адрес свои L-BTC, после чего Liquid Network отправит ему биткойны. На момент написания материала Liquid Network возвращает только BTC и только на верифицированные адреса.

    a – z ↩

    M

    MAST (Merkelized Alternative Script Tree) (меркелизованное альтернативное дерево скриптов)

    Merkelized Alternative Script Tree (меркелизованное альтернативное дерево скриптов), или MAST, — это предложение, позволяющее инкапсулировать в биткойн-адрес произвольное количество различных скриптов. Впоследствии эта концепция стала частью обновления Taproot. MAST расширяет гибкость и полезность биткойн-контрактов незатратным образом и с сохранением конфиденциальности.

    В первоначальном предложении концепция MAST называлась Merkelized Abstract Syntax Tree (меркелизованное абстрактное синтаксическое дерево). Однако поскольку текущая версия предложения больше не подразумевает реализации абстрактных синтаксических деревьев, в 2018 году название было изменено.

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

    a – z ↩

    Miniscript

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

    Структурированное представление биткойн-скриптов, обеспечиваемое miniscript, позволяет кошелькам быть гораздо более динамичными в отношении используемых скриптов. В поддержку этой динамичности, минискрипты можно создавать с использованием просто написанного языка политик. Политики можно компоновать, что позволяет заменять любое валидное подвыражение другим валидным подвыражением (в определенных пределах, установленных системой Биткойна).

    a – z ↩

    MuSig

    MuSig — это протокол для создания подписей и открытых ключей мультиподписи в Taproot. MuSig использует подписи Шнорра и агрегацию открытых ключей, поэтому его можно будет использовать только после активации Taproot.

    Особенность MuSig состоит в том, что результирующая multisig-транзакция становится неотличима от транзакции с одной подписью. Это связано с тем, что MuSig объединяет отдельные открытые ключи каждой стороны для создания единого открытого ключа. И при расходовании биткойнов с этого открытого ключа отправители не вынуждены раскрывать собственные отдельные открытые ключи. Вместо этого они совместно создают одну подпись, действительную для открытого ключа, который они создали ранее. Это отличается от обычных multisig-транзакций, использующих скрипты P2SH и подразумевающих обязательное раскрытие в блокчейне подписей и открытых ключей каждого подписанта.

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

    a – z ↩

     

    N

    Nonce

    Термин nonce — это сокращение от number used once («число, используемое один раз») и обозначает число, позволяющее майнерам находить валидный proof-of-work. Процесс майнинга состоит в поиске такого хеша для нового блока, который будет отвечать требованиям протокола. Поскольку хеш детерминистически генерируется из входных данных, хеширование одного и того же блока всегда будет давать на выходе один и тот же хеш. Для того чтобы генерировать уникальные хеши без изменения самого блока, майнеры используют nonce, число, которое они могут изменять, просто чтобы получить новый хеш для своего блока в надежде найти валидный.

    a – z ↩

     

    P

    P2P (peer-to-peer, пиринговый)

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

    a – z ↩

    P2PK (Pay-to-Public-Key)

    Pay-to-Public-Key (P2PK) — это тип скрипта ScriptPubKey, который блокирует BTC с помощью открытого ключа. Это означает, что потратить эти монеты может только обладатель секретного ключа, соответствующего открытому ключу, который указан в скрипте. Открытый ключ в этом случае можно сравнить с почтовым ящиком, на который любой может отправлять почту (биткойн), используя адрес (открытый ключ) почтового ящика, но получить доступ к письмам после этого может получить только тот, у кого есть (секретный) ключ от него. P2PK-транзакция — это такая транзакция, во входах которой использовался P2PK ScriptPubKey.

    Например, если Элис отправляет Бобу ₿1 в P2PK-транзакции, то такая транзакция включает в себя открытый ключ Боба. Когда Боб хочет потратить полученные от Элис BTC, он должен подписать свою транзакцию секретным ключом, соответствующим открытому ключу, который Элис включила в свою транзакцию.

    Технически P2PK — это просто название определенного скрипта с вышеупомянутыми требованиями. Каждый выход в Биткойне снабжается скриптом, который определяет, как этот выход может быть потрачен, и P2PK — один из таких скриптов. Сейчас P2PK-скрипты устарели и уступили место более безопасным и удобным P2PKH-скриптам.

    a – z ↩

    P2PKH (Pay-to-Public-Key-Hash)

    Pay-to-Public-Key-Hash (P2PKH) — это тип скрипта ScriptPubKey, который блокирует BTC с помощью хеша открытого ключа. P2PKH-транзакция — это такая транзакция, в которой входы блокируются с помощью P2PKH ScriptPubKey. Открытый ключ в этом случае также называют адресом, и P2PKH на сегодняшний день является наиболее распространенным типом скрипта в Биткойне. P2PKH-транзакции похожи на P2PK за исключением того, что монеты блокируются с помощью хеша открытого ключа, а не самого ключа.

    Если Элис хочет отправить Бобу ₿1 в P2PKH-транзакции, то Боб предоставляет Элис адрес своего кошелька. Адрес Боба включается в транзакцию. Чтобы потратить полученные BTC, Боб должен подписать транзакцию секретным ключом, соответствующим открытому ключу, хеш которого совпадает с хешем, включенным в транзакцию Элис.

    a – z ↩

    P2SH (Pay-to-Script-Hash)

    Pay-to-Script-Hash (P2SH) — это тип скрипта ScriptPubKey, который позволяет расходовать BTC, удовлетворяя правилам скрипта, хеш которого указан в транзакции. P2SH-транзакция — это такая транзакция, входы в которой блокируются с помощью P2SH ScriptPubKey.

    Например, если Элис отправляет Бобу ₿1 в P2SH-транзакции, она включает в нее хеш скрипта, необходимого для расходования передаваемого в транзакции BTC. Этот скрипт может требовать подписи секретным ключом Боба и/или выполнения иных условий. Чтобы потратить полученные BTC, Боб восстанавливает скрипт, хеш которого Элис использовала для отправки монет, и подписывает транзакцию секретными ключами, определенными в этом скрипте.

    P2SH чрезвычайно гибок и позволяет пользователям создавать произвольные скрипты. P2SH используется также для обеспечения обратной совместимости с новыми типами транзакций, включая SegWit. Кроме того, отправителю транзакции не нужно знать, какому типу скрипта он отправляет транзакцию. В примере выше Боб может в частном порядке создать желаемый скрипт и отправить Элис только его хеш, что сохраняет для Боба больше конфиденциальности.

    a – z ↩

    P2TR (Pay-to-Taproot)

    Pay-to-Taproot (P2TR) — это тип scriptPubKey, который привязывает биткойны к скрипту, разблокировать который можно с помощью открытого ключа либо MAST, что дает вариативность в расходовании этих биткойнов.

    Внешне P2TR-выход привязывает биткойны к открытому ключу Шнорра, который на схеме ниже мы называем Q. Но на самом деле этот открытый ключ Q объединяет в себе открытый ключ P и открытый ключ M, который рассчитывается из корня дерева хешей для списка других scriptPubKey.

    Подробнее об агрегировании ключей Шнорра

    Биткойны с P2TR-выхода можно потратить, опубликовав подпись к открытому ключу P либо выполнив условия одного из скриптов, содержащихся в хеш-дереве.

    Pay-to-Taproot гибко сочетает в себе функциональность скриптов Pay-to-Script-Hash (P2SH) и Pay-to-Public-Key (P2PK), позволяя владельцу или владельцам выбирать, каким способом они предпочли бы потратить свои средства. Благодаря этому P2TR значительно повышает конфиденциальность всех пользователей Биткойна.

    Притом что расходовать P2TR-выходы можно множеством различных способов, раскрытию подлежит только тот из них, что реально используется, в то время как неиспользованные альтернативы оставляются в тайне. Кроме того, благодаря агрегированию ключей Шнорра, открытый ключ P и сам может быть агрегированным ключом, за которым может скрываться скрипт мультиподписи. Самое главное, что статус открытого ключа P как ключа с одной подписью или с несколькими никогда не раскрывается, и потому все P2TR-выходы похожи друг на друга, что подрывает многие эвристические правила, используемые в блокчейн-анализе, и способствует сохранению конфиденциальности пользователей.

    Pay-to-Taproot — это SegWit-выход версии 1, что означает, что подписи P2TR-входов хранятся в witness-поле транзакции, а не в scriptSig. Как и в других SegWit-адресах, в P2TR-адресах используется кодировка bech32.

    Подробнее о Taproot.

    a – z ↩

    P2WPKH (Pay-to-Witness-Public-Key-Hash)

    Pay-to-Witness-Public-Key-Hash (P2WPKH) — это тип scriptPubKey, используемый для привязки биткойнов к SegWit-адресу. P2WPKH-транзакция во многом похожа на P2PKH-транзакцию; она по-прежнему привязывает биткойны к хешу открытого ключа. Основное отличие заключается в том, что P2WPKH использует SegWit.

    Подробнее о Segregated Witness (SegWit)

    Это означает, что scriptSig — скрипт, разблокирующий биткойны — для всех входов перемещается из тела транзакции в поле Witness и называется Script Witness. Эти данные по-прежнему записываются в блокчейн, но за них взимается более низкая комиссия, чем за обычные данные, что снижает стоимость SegWit-транзакций в сравнении с обычными.

    a – z ↩

    P2WSH (Pay-to-Witness-Script-Hash)

    Pay-to-Witness-Script-Hash (P2WSH) — это тип транзакции, во многих отношениях похожий на P2SH, за исключением того, что он использует SegWit. Как и P2SH-, P2WSH-транзакции привязывают биткойны к хешу скрипта. Чтобы потратить эти биткойны, отправитель должен предоставить так называемый redeemScript («скрипт высвобождения») и все необходимые подписи.

    На техническом уровне P2WSH фактически описывается как scriptPubKey, используемый для привязки биткойнов к хешу SegWit-скрипта. P2WSH-транзакция расходует биткойны, которые до того были привязаны к P2WSH-адресу. Поскольку P2WSH является SegWit-транзакцией, когда P2WSH-выход используется как вход для новой транзакции, scriptSig перемещается в поле Witness и называется witnessScript.

    a – z ↩

    PayJoin (P2EP)

    PayJoin, также известный как Pay-to-Endpoint (P2EP) — это особый тип биткойн-транзакции, в которой отправитель и получатель оба вносят входы транзакции, нарушая тем самым эвристику по общему владению входами, допущение, используемое в блокчейн-анализе для нарушения конфиденциальности пользователей Биткойна.

    Эвристика по общему владению входами (common input ownership) — одно из наиболее часто используемых эвристических правил в блокчейн-анализе. Оно предполагает, что в каждой транзакции все входы подписаны одним субъектом сети. До сих пор это было относительно безопасным допущением, хоть и не дающим 100% надежного результата, поскольку уровень использования мультиподписей остается сравнительно низким. Предложение P2EP было создано для того, чтобы нарушить это допущение и повысить конфиденциальность Биткойна.

    Хотя синтаксис P2EP напоминает многие типы скриптов, P2EP скриптом не является. Это скорее протокол, позволяющим двум пользователям Биткойна совершать транзакции с сохранением конфиденциальности. Используя peer-to-peer канал, такой как onion-адрес, отправитель и получатель могут обмениваться информацией об UTXO, которые они хотели бы использовать в качестве входов транзакции. Затем они могут совместно собрать и подписать транзакцию, используя стандарт частично подписанных биткойн-транзакций (PSBT), определенный в BIP 174. Результирующая транзакция будет похожа на типичную транзакцию с несколькими входами и несколькими выходами.

    a – z ↩

    Proof-of-stake (PoS)

    Proof-of-stake (PoS) — это распространенный алгоритм консенсуса, представляющий собой менее ресурсозатратную альтернативу proof-of-work. Он предполагает распределение ответственности за администрирование публичного реестра между узлами-участниками пропорционально количеству принадлежащих им токенов виртуальной валюты.

    a – z ↩

    Proof-of-work (PoW)

    Proof-of-work — это метод подтверждения валидности данных. Для того чтобы его блок считался валидным, биткойн-майнер должен предоставить proof-of-work (дословно «подтверждение [выполненной] работы») в форме валидного хеша. Proof-of-work побуждает майнеров затрачивать большое количество энергии и денег на добавление блоков, стимулируя их оставаться честными и тем самым защищая сеть. Proof-of-work — это один из немногих способов, посредством которых децентрализованная сеть может договориться об одном источнике истины, что является необходимой чертой денежной системы.

    Майнеры генерируют proof-of-work путем создания блока, хеш которого меньше заявленного целевого значения. Хеш представляет собой случайным образом сгенерированное 64-значное число, и майнерам приходится сгенерировать миллиарды хешей, чтобы найти тот, что будет отвечать заданному условию. Целевое значение хеша динамически устанавливается исходным кодом Биткойна. По мере того как к сети присоединяется все больше майнеров, целевое значение понижается, что затрудняет майнерам поиск хеша ниже этого целевого значения. Если майнеры покидают сеть. цель повышается, что облегчает майнерам поиск валидного хеша. Алгоритм, рассчитывающий целевое значение, стремится к тому, чтобы новые блоки для блокчейна Биткойна находились в среднем каждые 10 минут.

    a – z ↩

    PSBT (Partially Signed Bitcoin Transactions)

    Частично подписанные биткойн-транзакции (Partially Signed Bitcoin Transactions, или PSBT) — это стандарт Биткойна, облегчающий переносимость неподписанных биткойн-транзакций, что позволяет нескольким сторонам легко подписывать одну и ту же транзакцию. Это наиболее полезно в тех случаях, когда несколько сторон хотят добавить свои входы в одну транзакцию. PSBT был введен с BIP-174 и позволяет пользователям легче подписывать транзакции на устройстве холодного хранения BTC, а затем транслировать подписанную транзакцию с устройства, подключенного к интернету.

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

    a – z ↩

    PTLC (Point Time Locked Contract)

    Point Time Locked Contract (PTLC) — это биткойн-транзакция, блокирующая биткойны по точке на эллиптической кривой. Выходы, создаваемые в транзакции этого типа, имеют также блокировку по времени (таймлок), что означает, что они не могут быть потрачены до определенного момента, задаваемого по времени UTC или по высоте блока. PTLC подобны контрактам HTLC (Hashed Time Locked Contract), но обеспечивают лучший уровень приватности и некоторую экономию на комиссиях. По этой причине PTLC могут заменить HTLC в качестве основного контракта Lightning Network и других офчейн протоколов.

    PTLC станут более доступными с реализацией в Биткойне поддержки схем Шнорра, что произойдет при активации Taproot.

    a – z ↩

     

    R

    redeemScript

    RedeemScript (скрипт высвобождения) используется для разблокировки биткойнов, отправленных на P2SH- или P2WSH-адрес. В P2SH- или P2WSH-транзакциях биткойны привязываются к хешу скрипта redeemScript, гарантируя, что потратить эти «монеты» сможет лишь тот, кто воспроизведет redeemScript и предоставит все необходимые подписи. Чаще всего redeemScript(ы) содержат multisig- или обернутые SegWit-скрипты.

    a – z ↩

    Regtest (Regression Test Network)

    Regtest (сеть регрессионного тестирования) — это отдельный блокчейн, параллельный основному блокчейну Биткойна. Он работает почти идентично основной сети, но используется для тестирования и частной разработки. Regtest больше всего похож на testnet (тестовую сеть) в том, что биткойны в regtest-сети не монетизируются. Кроме того, regtest предназначен исключительно для частного тестирования; внешние подключения не поддерживаются и сложность майнинга установлена на ноль. Это позволяет пользователям regtest-сети добывать сколько угодно блоков, что упрощает тестирование.

    a – z ↩

    Replace-By-Fee (RBF)

    Replace-By-Fee (дословно «замена по комиссии»), или RBF, — это механизм ускорения обработки сетью транзакции с малой комиссией. Если транзакция помечена как RBF, это позволяет отправителю заменить эту транзакцию в мемпуле другой аналогичной транзакцией с более высокой комиссией. Этот механизм существует для того, чтобы пользователи имели возможность среагировать на изменение загрузки и неожиданный рост комиссий сети. Если пользователь отправляет транзакцию с низкой комиссией и обнаруживает, что подтверждение ее занимает слишком много времени, он может увеличить уплачиваемую комиссию, чтобы быстрее подтвердить свою транзакцию.

    RBF работает только тогда, когда транзакция находится в мемпуле. Как только транзакция попадает в блок, она уже больше не может быть заменена по Replace-By-Fee. Кроме того, чтобы воспользоваться опцией Replace-By-Fee, она должна быть указана при первой отправке транзакции. Это достигается путем установки nSequence — небольшой части каждой транзакции — в любое значение ниже 0xfffffffe. nSequence транзакции предназначается для того, чтобы разрешить обновление транзакции после трансляции ее в сеть.

     

     

    S

    Script (Bitcoin Script)

    Скриптовый язык Биткойна называется просто Script. Все скрипты Биткойна написаны в Script. Это простой язык, не Тьюринг-полный, поэтому в нем отсутствуют некоторые логические функции, включая циклы. Это сделано для того, чтобы ни один биткойн-скрипт не мог потреблять чрезмерную вычислительную мощность и наносить вред узлам сети (нодам).

    Script используется почти исключительно для блокировки и разблокировки биткойнов, не для создания приложений или запуска программ. Простота языка Script также способствует безопасности Биткойна, помогая разработчикам избежать критических ошибок, ведущих к потере средств пользователей, при разработке кошельков и иных приложений на основе Биткойна.

    Все биткойн-транзакции используют Script для определения того, как могут быть потрачены соответствующие выходы. Другими словами, скрипт биткойн-транзакции определяет, кому были отправлены BTC. В протоколе Биткойна есть несколько различных скриптов, самый популярный из них Pay-to-Public-Key-Hash (P2PKH). P2PKH — это простой скрипт, который выплачивает биткойны по указанному адресу.

    Другие скрипты могут выполнять более сложные действия, такие как создание multisig-адресов. Для расходования BTC, отправленных на такой адрес, требуются несколько подписей от нескольких секретных ключей.

    Хотя скрипты SegWit — P2WPKH и P2WSH — обеспечивают экономию на комиссиях за транзакции, внедрение этих скриптов протекает медленно. По состоянию на апрель 2021, почти через четыре года после активации SegWit, более чем в 70% UTXO используются P2PKH-скрипты.

    Типы скриптов по использованию (: Clark Moody’s Dashboard)

    a – z ↩

    Script Witness

    Script Witness содержит подписи и открытые ключи, которые вместе разблокируют BTC, отправленные в SegWit-транзакции. Script Witness аналогичен ScriptSig транзакции старого вида, за исключением его местонахождения. Каждый SegWit-вход имеет свой Script Witness, и все Script Witness транзакции составляют поле Witness.

    Для решения проблемы пластичности транзакций, с обновлением Segregated Witness (SegWit) было введено новое поле Witness, в котором содержатся Script Witness всех входов. Это решает проблему изменения txid в результате изменения подписи транзакции, существовавшую в транзакциях старого вида.

    Script Witness не следует путать с Witness Script. Script Witness содержит witness-данные любого SegWit-входа. Script Witness — это не форма Bitcoin Script, это просто данные, используемые скриптом.

    С другой стороны Witness Script — это скрипт, определяющий условия расходования P2WSH-входа, и представляет собой форму Bitcoin Script.

    a – z ↩

    ScriptPubKey

    ScriptPubKey — это скрипт, контролирующий то, как BTC могут быть потрачены. В переводе на русский большинство биткойн-скриптов формулируются примерно следующим образом: «Чтобы потратить эти BTC, нужно создать подпись, соответствующую такому-то открытому ключу…», — далее следует открытый ключ. Вместо самих открытых ключей чаще используются их хеши, но сути это не меняет.

    ScriptPubKey часто называют скриптом блокировки, потому что он блокирует BTC до тех пор, пока кто-то не сможет предоставить нужный ответ для их разблокирования. Скрипт разблокировки — ScriptSig в транзакциях старого типа и Script Witness в SegWit-транзакциях — предоставляется при расходовании этих BTC в будущей транзакции.

    a – z ↩

    scriptSig

    ScriptSig — это часть транзакции, содержащая необходимые подписи и скрипт, который разблокирует UTXO для расходования. ScriptSig со scriptPubKey формируют полный и валидный скрипт. ScriptSig присутствует только в биткойн-транзакциях старого типа. В SegWit-транзакциях ScriptSig удаляется из тела транзакции и называется witnessScript.

    При отправке биткойны блокируются с помощью scriptPubKey. ScriptPubKey можно сравнить с загадкой, отгадать которую может только владелец корректных секретных ключей. Чтобы потратить эти биткойны, владелец должен опубликовать ответ на загадку, подписав транзакцию своими ключами. Опубликованный ответ на загадку — это и есть scriptSig.

    Каждая нода проверяет каждую получаемую транзакцию на соответствие scriptSig и scriptPubKey, гарантируя, что в блокчейн не будут добавлены недействительные транзакции. Одним из основных изменений в обновлении SegWit стало перемещение scriptSig из тела транзакции в поле Witness.

    a – z ↩

    SEC формат

    Standards for Efficient Cryptography (SEC) — это стандартный метод кодирования открытых ключей в Биткойне. Открытый ключ Биткойна — это точка на эллиптической кривой, называемой secp256k1, и, следовательно, имеет координаты x и y.

    Однако каждое значение x имеет только два возможных значения y, и вследствие природы secp256k1, одно из этих значений y для каждого x четное, а другое нечетное. Таким образом, для идентификации открытого ключа достаточно знать x и четность значения y. Четность значения y обозначается байтом 0x02 либо 0x03, указывающими на четность или нечетность соответственно. За этим следует значение x, представляющее собой 32-байтовое число.

    Этот формат называется сжатым, потому что занимает всего 33 байта по сравнению с несжатым форматом SEC, который начинается с префикса 0x04, за которым следуют полные значения x и y, занимающим 65 байт.

    a – z ↩

    Secp256k1

    Secp256k1 — это название эллиптической кривой, используемой в Биткойне для реализации криптографии с открытым ключом. Все точки на этой кривой являются валидными открытыми ключами Биткойна. Когда пользователь хочет сгенерировать открытый ключ, используя свой секретный ключ, он умножает секретный ключ на большое число, генераторную точку — определенную точку на кривой secp256k1. Благодаря проблеме дискретного логарифмирования, делением открытого ключа на генераторную точку нельзя получить секретный ключ.

    Все эллиптические кривые представляют собой уравнения с определенным шаблоном: y^2 = x^3 + ax^ + b. В частности, для secp256k1 a = 0 и b = 7, что дает уравнение y^2 = x^3 + 7. Поскольку компонент y уравнения возведен в квадрат, кривая secp256k1 симметрична по оси x, и для каждого значения x есть два значения y, одно из которых нечетное, а другое четное. Это позволяет идентифицировать открытые ключи просто по координате x и четности координаты y, что дает существенную экономию в использовании данных в блокчейне.

    a – z ↩

    Seed

    Seed-значение — это фрагмент данных, который может быть использован для генерации иерархического детерминированного (HD) кошелька. Это единственные данные, необходимые для восстановления любых секретных и открытых ключей в кошельке, так что они могут использоваться как резервная копия кошелька. Поскольку дизайн seed является детерминированным, определенное seed-значение каждый раз будет генерировать одни и те же ключи, и одно seed-значение может генерировать почти бесконечное количество открытых и секретных ключей.

    Seed — это просто энтропия, случайная строка цифр. Она используется для генерации одного расширенного секретного ключа (extended private key, или xprv). Этот секретный ключ может использоваться для генерации дочерних открытых и секретных ключей, позволяя кошельку генерировать столько пар ключей, сколько нужно пользователю. Такой сетап максимально упрощает резервное копирование кошелька без ущерба для конфиденциальности, позволяя избегать повторного использования адресов.

    Seed-значения часто бывают представлены в виде мнемонических фраз (seed-фраз), чтобы облегчить их хранение и запоминание. Использование seed стало стандартом комьюнити благодаря BIP 32, а мнемонических фраз — благодаря BIP 39.

    a – z ↩

    SegWit (Segregated Witness)

    Segregated Witness (SegWit) — это софтфорк-обновление Биткойна, активированное в 2017 году. SegWit исправил проблему пластичности транзакций, когда транзакция могла иметь несколько валидных txid. Это обновление проложило путь для реализации Lightning Network и открыло возможности для нескольких будущих обновлений, включая Taproot.

    SegWit также позволяет включать в блок больше транзакций, несколько снижая давление комиссий и являясь частично масштабирующим решением.

    Одним из наиболее заметных изменений, внесенных SegWit, стал переход от кодировки Base58 к Bech32.

    SegWit устранил проблему пластичности транзакций за счет перемещения ScriptSig — подписи транзакции и ее изменяемой части — из тела транзакции в Script Witness, находящийся в разделе Witness. Witness каждой транзакции по-прежнему хранится в блокчейне, но только теми нодами, версия ПО которых поддерживает SegWit.

    Поскольку раздел Witness не включен в основное тело транзакции, он не влияет на txid. Однако для того чтобы гарантировать неизменность раздела Witness транзакции после включения ее в блок, для Witness вычисляется отдельный txid (wtxid). Этот wtxid включает в себя Witness, а хеш-дерево из имеющихся wtxid записывается в выход coinbase-транзакции каждого блока.

    Подробнее о Segregated Witness (SegWit)

    a – z ↩

    SHA-256

    SHA-256 — это криптографическая хеш-функция. Криптографическая хеш-функция обладает несколькими ключевыми свойствами. Она принимает вход, называемый прообразом, и выдает выход определенной длины — все выходы SHA-256 имеют длину 256 бит. Это детерминированный процесс, то есть определенный вход будет каждый раз давать один и тот же выход. Кроме того, хеш-функции непредсказуемы: малейшее изменение входа даст в результате совершенной иной выход, так что невозможно целенаправленно создать желаемый выход или вычислить вход на основе имеющегося выхода. SHA-256 — член семейства хеш-функций, называемых Secure Hashing Algorithm (SHA).

    Биткойн использует SHA-256 для получения ID транзакций (txid), хешей блоков, адресов и хеш-деревьев. Иногда SHA-256 применяется дважды, как в случае txid.

    a – z ↩

    Sighash-флаг (Sighash Flag)

    Флаг хеша подписи (sighash, от signature hash) — это небольшая часть каждого входа в транзакции, которая определяет, какие части транзакции становятся неизменными после добавления в транзакцию подписи.

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

    Почти во всех транзакциях используется флаг SIGHASH_ALL, что означает, что подпись каждого входа валидна только в том случае, если все остальные входы и выходы остаются неизменными. Другие sighash-флаги позволяют подписи входа оставаться валидной даже при изменении других входов и выходов.

    В транзакции каждый вход требует собственной подписи и, следовательно, собственного sighash-флага. Это подразумевает возможность гибкой настройки входов. Когда несколько сторон участвуют в определенной транзакции, они могут влиять только на собственные определенные выходы. Например, если Элис вносит в транзакцию ₿1 и ожидает получить взамен ₿1,2, она, вероятно, заботится только о том, чтобы подпись гарантировала ее выход с ₿1,2. В этом случае Элис может использовать sighash-флаг SIGHASH_SINGLE. Этот флаг фиксирует все входы, но только один выход. Это позволит другим сторонам транзакции добавлять и изменять свои выходы по собственному усмотрению, если только они не будут менять выход Элис с ₿1,2.

    В редких случаях, когда сторона транзакции не заинтересована ни в одном из выходов, она может использовать sighash-флаг SIGHASH_NONE, который фиксирует все входы, но ни одного выхода.

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

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

    a – z ↩

    Signet

    Signet — это предлагаемая новая тестовая сеть, параллельная сети Биткойна. Как и testnet и regtest, signet будет использоваться разработчиками в качестве тестовой среды. В отличие от основной (mainnet) сети Биткойна, signet использует для проверки блоков цифровые подписи, а не proof-of-work систему.

    Блоки в signet валидны только в том случае, если они подписаны ключом, использовавшимся для создания этой signet. Это дает создателю signet полный контроль над формированием блоков, позволяя выбирать скорость появления блоков или время возникновения форков. Это обеспечивает гораздо более управляемую сетевую среду, чем тестовая proof-of-work сеть (testnet), где недобросовестные майнеры могут использовать различные приемы, чтобы на долгое время сделать сеть практически непригодной для использования.

    a – z ↩

     

    T

    Taint («порченность»)

    «Порченность» (Taint) — это концепция, согласно которой некоторые монеты являются более рискованными или менее приемлемыми для владения из-за их истории (прежних владельцев) либо возможной связи с преступной деятельностью. Эта концепция продвигается и используется компаниями по блокчейн-аналитике.

    Концепция «порченности» цифровых монет имеет вредные последствия для Биткойна, расчетные единицы которого по идее должны быть взаимозаменяемыми, то есть каждый BTC должен стоить ровно столько же, сколько и любой другой BTC. Вывод о порченности тех или иных цифровых монет основывается на применяемом аналитическими компаниями эвристическом анализе, который по определению не гарантирует стопроцентной точности.

    a – z ↩

    Tamper-proof (защита от несанкционированного доступа)

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

    a – z ↩

    Taproot

    Taproot — предлагаемое обновление Биткойна, на момент написания этого текста находящееся в стадии активации. Обновление Taproot описано в BIP 340, 341 и 342 и предполагает введение схемы подписей Шнорра, Taproot и Tapscript. Вместе эти обновления привносят более эффективные, гибкие и приватные способы передачи биткойнов.

    Подписи Шнорра — это более эффективная, безопасная и быстрее верифицируемая схема цифровой подписи по сравнению с оригинальными ECDSA-подписями Биткойна. Кроме того, подписи Шнорра открывают возможности для использования MuSig, более эффективной формы мультиподписи, значительно повышающей приватность и оптимизирующей размер комиссий за транзакции с мультиподписью.

    Taproot позволит отправлять и расходовать BTC с открытых ключей Шнорра, а также отправлять BTC сразу нескольким скриптам. Для достижения этой цели будет определен новый тип ScriptPubKey, называемый Pay-to-Taproot (P2TR). Адреса для этих скриптов будут использовать кодировку SegWit v1 bech32.

    Подробнее о Taproot:

  • Taproot: наступление новой эпохи
  • Taproot: что он собой представляет и чем полезен для Биткойна
  • a – z ↩

    Tapscript

    Tapscript — это скриптовый язык, используемый для реализации различных новых типов транзакций в рамках обновления Taproot. Tapscript похож на Script, скриптовый язык Биткойна с момента его создания, но с некоторыми изменениями.

    Главное изменение, добавление опкода OP_CHECKSIGADD, основывается на том факте, что подписи Шнорра, еще один аспект обновления Taproot, могут быть агрегированы. Кроме того, Tapscript оптимизирован для упрощения непредвиденных будущих обновлений с помощью опкода OP_SUCCESS.

    Подробнее о Tapscript в BIP342 на GitHub.

    a – z ↩

    txid (ID транзакции)

    Txid, или ID транзакции, — это строка букв и цифр, идентифицирующая конкретную транзакцию в блокчейне. Строка представляет собой просто двойной SHA256-хеш транзакции. Этот хеш можно использовать для поиска транзакции в ПО ноды или в блок-эксплорере.

    При подписании транзакции фактически подписывается txid. Подписание txid гарантирует, что, если после подписания изменится какая-то часть транзакции, то изменится ее ID, и тогда подпись станет недействительной.

    Технически txid не всегда является хешем всей транзакции. Поскольку подпись не может подписывать сама себя, подписи не включаются в txid. И, следовательно, подпись можно изменить после ее создания, в некоторых случаях без того, чтобы она стала недействительной. До внедрения SegWit это позволяло изменять txid после подписания транзакции — проблема, называемая пластичностью транзакций.

    a – z ↩

     

    U

    UTXO (Unspent Transaction Output)

    Непотраченный выход транзакции (UTXO, от Unspent Transaction Output) — это дискретная часть биткойна. В протоколе Биткойна не используются счета и балансы в традиционном понимании. Вместо этого, отдельные лица обладают правом собственности на определенные части биткойна. С каждым UTXO ассоциирована определенная сумма. Это дискретные единицы биткойна, которые расходуются и получаются в каждой транзакции.

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

    UTXO напоминают физические наличные в том, что обычно их расходование подразумевает получение сдачи. Например, если Элис владеет UTXO стоимостью 1 BTC и хочет заплатить Бобу 0,4 BTC, то она должна потратить весь 1 BTC в качестве входа транзакции. Для того чтобы Боб получил ровно 0,4 BTC, создается два выхода: первый — для Боба, в размере 0,4 BTC, и второй — для Элис, в размере 0,59 BTC, если предположить, что она заплатила комиссию за транзакцию в размере 0,01 BTC. В этой транзакции будет разрушен один UTXO и создано два новых. Обратите внимание, что уплаченная комиссия не создает нового выхода. Она просто рассчитывается как сумма входов (1 BTC) минус сумма выходов (0,4 + 0,59 = 0,99 BTC). Майнер при проведении этой транзакции рассчитает заложенную в ней комиссию и затребует ее для себя в coinbase-транзакции.

    a – z ↩

     

    UTXO-сет (UTXO Set)

    UTXO-сет — это полный набор всех UTXO Биткойна, существующих в данный момент времени. Сумма значений всех UTXO равна общему предложению выпущенных биткойнов на текущий момент.

    Уникальная особенность Биткойна как денежной системы состоит в том, что любой желающий может самостоятельно проверить общий объем его предложения на тот или иной момент времени без необходимости доверять кому бы то ни было. Все ноды Биткойна хранят и поддерживают в актуальном состоянии идентичные копии UTXO-сета. Когда в блокчейн добавляется новый блок, UTXO-сет обновляется, поскольку во включенных в блок транзакциях какие-то UTXO расходуются и создаются новые.

    UTXO-сет важен также потому, что позволяет всем нодам сети Биткойна обнаруживать и отклонять любые попытки двойной траты, когда кто-то пытается дважды потратить одни и те же UTXO («монеты»). Ноды должны постоянно хранить полный UTXO-сет, чтобы определять, какие монеты существуют и, следовательно, могут быть потрачены на текущий момент.

    a – z ↩

     

    V

    Vault

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

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

    Некоторые из дизайнов vault основаны на ковенантах, требующих внесения изменений в правила консенсуса сети Биткойна. Другие дизайны используют существующие функции протокола в комбинации с такими методами, как подписание транзакций задолго до того, как они понадобятся, с последующим уничтожением средств для подписания альтернативных транзакций (либо путем безопасного удаления подписывающего ключа, либо с использованием множественной [multisig] подписи, гарантирующей, что для расхода понадобится несколько независимых ключей).

    a – z ↩

    vБайт (vByte)

    vБайт — это единица измерения веса блоков и транзакций, введенная с обновлением SegWit. vБайт эквивалентен 4 единицам веса (wu). Таким образом, размер валидного блока ограничен 1 vМегабайтом, или 4 миллионами единиц веса.

    Кошельки обычно рассчитывают и отображают комиссии за транзакции в сат./vБайт, то есть комиссия платится за каждый vБайт используемых данных. Следовательно, чем больше «весит» транзакция, тем больше должна быть комиссия за нее, чтобы обеспечить желаемую скорость проверки. Этим объясняется также меньший размер комиссии за SegWit-транзакции по сравнению с обычными, поскольку байт witness-данных эквивалентен всего 1 единице веса (1/4 vБайта), тогда как байт прочих (не-witness) данных составляет 4 единицы веса (1 vБайт).

    a – z ↩

     

    W

    Watchtower

    Watchtower (смотровая вышка) — это служба, которая следит за определенным lightning-каналом для защиты от мошенничества. Такие службы позволяют пользователям иметь полудоверенную третью сторону, которая следит за их каналом, чтобы предотвратить двойные траты.

    Поскольку Lightning Network использует для трансфера средств неподтвержденные транзакции, проблема двойной траты не устранена в ней полностью. Недобросовестный участник lightning-канала может транслировать более старую неподтвержденную транзакцию и предпринять попытку аннулировать совершённые lightning-платежи, украв деньги у другой стороны канала.

    Решение этой проблемы, реализованное в Lightning Network (LN), называется LN-penalty и позволяет жертве расквитаться со злоумышленником, вернув себе весь баланс канала, включая любое количество биткойнов, которыми злоумышленник мог вполне законно владеть до атаки. Такая процедура истребования баланса канала называется justice transaction (транзакция правосудия).

    Justice-транзакции можно выполнить только в течение определенного времени после первоначальной атаки, и поскольку пользователи не следят за своими Lightning-кошельками постоянно 24/7, своевременное выполнение justice-транзакции не всегда возможно. Watchtower позволяет пользователям отдать выполнение justice-транзакций «на аутсорс», так что даже если они не следят за своим кошельком или их lightning-нода находится офлайн, они не пропустят временное окно для отправки justice-транзакции.

    a – z ↩

    Witness

    Witness (англ. свидетель) транзакции — это поле SegWit-транзакций, не учитываемое при хешировании и подписании транзакции. Поле Witness содержит Script Witness для всех SegWit-входов транзакции. Script Witness — это аналог scriptSig, используемого в транзакциях старого типа: он содержит подписи и скрипты, необходимые для расходования биткойнов с SegWit-выхода.

    Подробнее о Segregated Witness (SegWit)

    Поскольку расходующий скрипт включается в поле Witness, scriptSig в SegWit-транзакции оставляется пустым. А раз поле Witness не включается в хеш транзакции, изменение Witness не влияет на txid. Такая архитектура была реализована для того, чтобы исключить пластичность транзакций.

    Witness-данные считаются частью транзакции и хранятся вместе с каждой транзакцией всеми биткойн-нодами, развернувшими соответствующее обновление ПО с поддержкой SegWit. Однако при расчете веса транзакции witness-данные учитываются с существенным дисконтом. Если обычный байт транзакции эквивалентен 4 единицам веса, то байт witness-данных эквивалентен всего 1 единице веса. Благодаря этому дисконту расходование SegWit-выходов стоит дешевле, чем расходование выходов старого типа. Это также увеличивает предельный размер блока с 1 МБ до 4 МБ.

    Чтобы обеспечить неизменность поля Witness после включения транзакции в блок, для транзакции вычисляется отдельный witness txid (wtxid). Этот wtxid используется для создания отдельного дерева хешей всех SegWit-транзакций в блоке, подобно обычному хеш-дереву блока. Это дерево хешей добавляется как scriptPubKey пустого coinbase-выхода с помощью опкода OP_RETURN.

    a – z ↩

    witnessScript

    В witnessScript записываются требования к расходованию выхода типа Pay-to-Witness-Script-Hash (P2WSH). Чаще всего такие скрипты определяют правила расходования для SegWit-кошелька с мультиподписью.

    P2WSH-выход — это SegWit scriptPubKey, содержащий хеш witnessScript. Чтобы потратить P2WSH-выход, отправитель должен создать witnessScript, хеш которого совпадает с хешем, указанным в scriptPubKey, а также представить подписи и открытые ключи, требуемые в witnessScript.

    WitnessScript — это SegWit-эквивалент redeemScript в P2SH-транзакциях. Однако если redeemScript P2SH-транзакции включается в scriptSig, то witnessScript записывается в поле Witness, что делает входы P2WSH дешевле, чем P2SH.

    WitnessScript не следует путать со Script Witness. Script Witness содержит witness-данные любого SegWit-входа. Script Witness — это не форма Bitcoin Script, но просто данные, используемые скриптом.

    С другой стороны witnessScript — это скрипт, определяющий условия расходования P2WSH-входа, и представляет собой форму Bitcoin Script.

    a – z ↩

    Wrapped SegWit

    Wrapped SegWit (дословно «обернутый SegWit») — это реализация, включенная в обновление SegWit и предназначенная для облегчения поддержки SegWit сторонними кошельками и более старым программным обеспечением. Это достигается через использование нативных SegWit-скриптов, P2WPKH и P2WSH в качестве redeemScript обычной P2SH-транзакции, что дает два дополнительных типа скриптов, составляющих Wrapped SegWit: P2SH-P2WPKH и P2SH-P2WSH соответственно.

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

    Как и любые P2SH-адреса, Wrapped SegWit адреса начинаются с «3» и используют схему кодирования Base58, в то время как нативные SegWit-адреса начинаются с «bc1» и используют кодирование bech32.

    a – z ↩

    wtxid (witness transaction ID)

    ID witness-транзакции (wtxid) вычисляется как двойной SHA-256 хеш сериализованной транзакции, включая ее SegWit-маркер, версию и поле Witness. При расчете обычного txid witness-данные не учитываются, следовательно, если транзакция не имеет SegWit-входов, ее wtxid идентичен ее txid.

    Wtxid используются майнерами для построения дерева хешей, которое включается в выход coinbase-транзакции. Это исключает пластичность witness-поля транзакции после того, как транзакция была добавлена в блок.

    a – z ↩

     

    X

    xpub (Extended Public Key)

    Extended public key (расширенный открытый ключ), или xpub, — это открытый ключ, который можно использовать как часть HD-кошелька для получения дочерних открытых ключей. Xpub — это стандарт Биткойна, введенный с BIP 32 и в основном используемый «под капотом» кошельков для получения открытых ключей.

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

    По xpub невозможно получить какие-либо секретные ключи, так что в случае его утечки никакие средства не подвергаются риску, однако ваша конфиденциальность окажется нарушена. Все xpub ключи начинаются с символов ‘xpub’, за которыми следует длинная строка букв и цифр.

     

    A  B  C  D  E  G  H  I  J  L  M  N  P  R  S  T  U  V  W  X

    А  Б  В  Г  Д  Е  З  К  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Э  Я

    А

    Адаптер подписи (adaptor signature)

    Адаптер подписи (или адаптерная подпись) — это дополнительная подпись, которая объединяется с первоначальной для раскрытия секретного фрагмента данных, «секрета». Адаптеры подписи позволяют двум сторонам одновременно раскрыть друг другу два фрагмента данных, что решает проблему доверия, возникающую при одновременных транзакциях, таких как атомарные свопы и койнсвопы.

    Сетап для адаптера подписи включает в себя секретное значение, адаптерную подпись и «простую» подпись. Знания любых двух из этих фрагментов данных достаточно, чтобы вычислить третий. Мощное свойство адаптеров подписи состоит в том, что одна сторона может сгенерировать адаптерную подпись исходя из секретного фрагмента данных, а другая сторона может сгенерировать собственную адаптерную подпись на основе тех же данных, но не зная самих этих данных.

    Например, Элис и Боб хотят обменяться 1 BTC. Сначала Элис передает Бобу адаптерную подпись для неподписанной транзакции, платящей Бобу 1 BTC. Адаптер — это не подпись транзакции, поэтому транзакция еще не может быть записана в блокчейн, однако адаптер фиксирует секретное значение.

    Затем Боб создает свою транзакцию, платящую 1 BTC Элис. Используя адаптерную подпись Элис, Боб может создать собственную адаптерную подпись. Его адаптерная подпись фиксирует то же секретное значение, даже при том, что Боб его не знает. Боб передает Элис свою транзакцию вместе со своей адаптерной подписью.

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

    а – я ↩

    Адрес (address)

    Адрес используется для получения биткойнов и представлен в виде строки букв и цифр. Открытые ключи и адреса часто объединяются. Адрес обычно представляет собой хеш открытого ключа, и в настоящее время для прямого получения BTC используются адреса, а не открытые ключи. На техническом уровне адрес может представлять собой нечто большее, чем просто хеш открытого ключа.

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

    Лучшей практикой считается никогда не использовать адреса повторно. Каждый раз, когда вы хотите получить BTC, лучше сгенерировать в своем кошельке новый адрес.

    На техническом уровне адрес может представлять несколько различных скриптов. Адреса кодируются и снабжаются префиксом, обозначающим тип их скрипта. В адресах старого типа используется Base58, и когда такой адрес является хешем открытого ключа (так называемый P2PKH-адрес), он начинается с 1. Реже адрес старого типа может являться хешем скрипта; в этом случае он будет начинаться с 3. На сегодняшний день все SegWit-адреса кодируются в bech32 и начинаются с префикса bc1.

    Когда пользователь вводит в кошельке адрес, чтобы отправить на него BTC, кошелек проверяет тип адреса и создает соответствующий скрипт. Этот скрипт, называемый scriptPubKey, добавляется к сумме, отправляемой на адрес. Эти два фрагмента данных — сумма и scriptPubKey — образуют выход.

    а – я ↩

    Алгоритм хеширования (hashing algorithm)

    Алгоритм хеширования (hashing algorithm) — криптографическая хеш-функция. Это математический алгоритм, который сопоставляет данные произвольного размера с хешем фиксированного размера. В отличие от шифрования, он представляет собой одностороннюю функцию, которую невозможно инвертировать. Хеширование позволяет проверять информацию без обмена ею: если хеш определенных данных записан в блокчейн, то идентичность имеющихся данных записанным можно проверить посредством сравнения хешей, даже не видя исходных данных, хранящихся у другой стороны.

    а – я ↩

    Альткойн (Altcoin)

    «Альткойнами» принято называть все криптовалюты помимо Биткойна.

    а – я ↩

    Атака 51% (51% attack)

    Если атакующие хотят изменить блок в блокчейне Биткойна, им необходимо заново создать proof-of-work не только для того блока, который они хотят изменить, но и для всех последующих блоков. Кроме того, они должны создавать новые блоки быстрее, чем все добросовестные майнеры вместе взятые, чтобы ноды воспринимали их измененную версию блокчейна как валидную. Это связано с тем, что ноды всегда считают валидной самую длинную ветку блокчейна — ту, в которой больше всего блоков.

    Для достижения всего этого злонамеренным майнерам нужно контролировать не менее 51% майнинговых мощностей сети Биткойна. Другими словами, атакующие должны контролировать больше вычислительных мощностей, чем все остальные майнеры вместе взятые. Сложность проведения такой атаки служит Биткойну защитой от мошенничества и отмены транзакций.

    Страх перед атакой 51% объясняет также, почему так важно измерять скорость хеширования (хешрейт) сети. Хешрейт — это показатель общей майнинговой мощности сети Биткойна, и чем он выше, тем выше стоимость проведения атаки 51%. Таким образом, хешрейт является мерой защищенности Биткойна от атаки 51%.

    а – я ↩

    Атака информационного затмения (eclipse attack)

    Атака информационного затмения (eclipse attack) нацелена на определенные узлы сети (ноды), окружая их вредоносными нодами и затрудняя получение информации о состоянии сети. Например, если биткойн-нода имеет восемь подключений к другим нодам и злоумышленник контролирует все восемь из этих узлов, он может отказаться передавать все новые блоки, формируемые майнерами. В то время как остальная часть сети будет продолжать обрабатывать новые блоки, нода-жертва не будет знать об их поступлении.

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

    а – я ↩

    Атака Сивиллы (Sybil attack)

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

    Подробнее о биткойн-нодах.

    Биткойн не является системой, управляемой большинством. Биткойн управляется консенсусом Накамото, в котором каждый узел сети выполняет именно тот код и набор правил, который он считает правильным выполнять. Выполняющие определенный код узлы формируют сеть, в то время как те, кто этого не делает, из сети исключаются. Критически важно, что метод определения валидного состояния блокчейна каждым узлом сети является объективным и не зависит от мнения других узлов. Таким образом, атаку Сивиллы на Биткойн провести гораздо сложнее, потому что сам факт контроля злоумышленника над простым или даже подавляющим большинством узлов не позволит ему изменить набор правил, используемых честными узлами.

    а – я ↩

     

    Б

    Биткойн (₿) (BTC)

    Биткойн (₿) (BTC) — это цифровая валюта (называемая также криптовалютой), запущенная в 2009 году и функционирующая абсолютно независимо от какого-либо централизованного органа управления, такого как центральный банк или правительство страны. Биткойны можно обменивать на товары или услуги у поставщиков, принимающих их в качестве оплаты. Транзакции типа биткойн–биткойн осуществляются путем цифрового обмена анонимными сильно зашифрованными хеш-кодами в пиринговой (P2P) сети (блокчейне). P2P-сеть (блокчейн) отслеживает и верифицирует движение биткойнов между пользователями. Биткойны каждого пользователя хранятся в программе, называемой цифровым кошельком, которая содержит публичные адреса для отправки и получения биткойнов, а также закрытый ключ, известный только пользователю.

    а – я ↩

    Блок (block)

    Блок — это набор транзакций, происходящих в сети Bitcoin. Блоки хронологически связаны друг с другом, образуя блокчейн. Большинство bitcoin-блоков включают около 2700 транзакций и могут иметь размер до 4 МБ.

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

    Например, если транзакция в блоке #400 будет изменена, хеш этого блока изменится, что приведет аннулированию proof-of-work для блока #400, но также сделает невалидным и блок #401, поскольку параметр «previous hash» блока #401 больше не будет соответствовать хешу блока #400. Это изменение распространится и дальше, разорвав связь с блокчейном для всех блоков начиная с #400. Это свойство гарантирует, что после добавления блока в блокчейн ни он сам, ни какая-либо из включенных в него транзакций, не могут быть изменены.

    а – я ↩

    Блок генезиса (genesis block)

    Блок генезиса — это первый блок в блокчейне Биткойна. Сатоши Накамото, создатель Биткойна, создал первый блок, блок генезиса, 3 января 2009 года и включил в него свежий заголовок из Financial Times — «Chancellor on brink of second bailout for banks» («Канцлер готов повторно субсидировать банки») — как декларацию сверхзадачи Биткойна: избежать неравенства и коррупции, присущих фиатной денежной системе.

    Блок генезиса особенный в нескольких отношениях. Во-первых, его поле хеша предыдущего блока пусто, поскольку нет предыдущего блока, на который можно было бы ссылаться. Во-вторых, первые 50 BTC, созданные в coinbase-транзакции блока генезиса, вообще не подлежат расходованию.

    а – я ↩

    Блок-эксплорер (block explorer)

    Блок-эксплорер — это сервис, который позволяет любому пользователю просматривать и запрашивать любые открытые данные блокчейна. Блокчейн Биткойна полностью открыт и доступен каждому. Десятки тысяч нод поддерживают полные копии одного блокчейна, что позволяет им самостоятельно проверять любую транзакцию или блок и подтверждать балансы BTC. Блок-эксплорер позволяет тем, кто не держит собственной ноды, делать все то же самое и более простым способом.

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

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

    а – я ↩

    Блокчейн (blockchain)

    Блокчейн — это синхронизируемая цифровая база данных (реестр) совместного пользования, содержащая растущий список записей, называемых блоками, которые связаны между собой с помощью криптографии. Каждый блок содержит криптографический хеш предыдущего блока, метку времени и данные транзакции. По своей конструкции блокчейн устойчив к изменению содержащихся в нем данных. Это «публичный распределенный реестр, который может верифицируемым образом регистрировать транзакции между сторонами и делать это эффективно и постоянно» (Iansiti, Marco; Lakhani, Karim R., январь 2017, The Truth About Blockchain, Harvard Business Review). После записи данные в любом блоке невозможно изменить задним числом без изменения всех последующих блоков, для чего требуется консенсус большинства участников сети. Записанные данные хранятся на многих узлах сети («нодах», калька с англ. «node»), то есть компьютерах, на которых хранится локальная версия базы данных. Блокчейн – это ключ к реализации технологии распределенного реестра.

    а – я ↩

    Блокчейн-аналитика (Chain Analysis)

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

    а – я ↩

    Бонд добросовестности (fidelity bond)

    Бонды добросовестности были предложены в качестве способа защиты CoinSwap от DoS-атак. Вкратце, бонды добросовестности требуют от инициатора предложения по CoinSwap-обмену внести на специальный контракт с временной блокировкой соответствующую сумму обеспечения в биткойнах, что гарантирует другой стороне наличие у инициатора сильного стимула для гладкого завершения операции. Бонды добросовестности блокируют залог инициатора, а значит, проведение крупномасштабной DoS-атаки потребует блокирования на значительный период времени огромного количества биткойнов. Предполагается, что такого увеличения издержек должно быть достаточно для предотвращения DoS-атак.

    а – я ↩

     

    В

    Взаимозаменяемость (fungibility)

    Взаимозаменяемость — это свойство товаров или активов, единицы которых являются взаимозаменяемыми и неразличимыми. Например, каждый пенни стоит $0,01, и владение одним пенни нисколько не предпочтительнее владения любым другим пенни.

    Взаимозаменяемость — это желательное свойство для Биткойна, максимизирующее его полезность для физических лиц. Если определенные биткойны (монеты) рассматриваются как «порченные» — возможно, из-за истории владения, ассоциируемой с противоправной деятельностью, — то биржи или компании могут счесть такие монеты менее ценными. А продавцам может потребоваться проверять каждый биткойн, чтобы убедиться в чистоте его истории. Такие ограничения стали бы огромным бременем для потребителей, продавцов и бирж, препятствуя распространению Биткойна.

    Различные механизмы конфиденциальности, такие как CoinJoin, представляют собой попытку сохранить взаимозаменяемость расчетных единиц Биткойна в будущем, обеспечивая безопасный способ скрыть историю владения определенными «монетами» и существенно ограничивая применимость концепции порченности цифровых монет.

    а – я ↩

    Вес блока (block weight)

    Вес блока — это размер блока, измеряемый в единицах веса (wu). Протокол Биткойна ограничивает размер блока 4 миллионами wu, что накладывает ограничение на количество транзакций, которое майнер может включить в каждый блок. 4 млн wu эквивалентно 4 МБ данных, то есть предельный размер блока на сегодня составляет 4 МБ. Этот лимит позволяет предотвратить слишком быстрое разрастание блокчейна, что затруднило бы для обычных пользователей хранение и верификацию его полной копии.

    Определение предельного размера блока через его вес было введено с активацией SegWit. До того предельный размер блока измерялся в байтах и составлял 1 МБ.

    а – я ↩

    Временная блокировка (timelock)

    Временная блокировка позволяет создавать bitcoin-транзакцию таким образом, чтобы получатель ее выходов не мог их потратить в течение указанного времени. Продолжительность блокировки можно задавать либо по высоте блока, либо в Unix-времени.

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

    а – я ↩

    Выбор монет (coin selection)

    Выбор «монет» — это процесс выбора подмножества UTXO, контролируемых кошельком, для создания и финансирования транзакции. При создании транзакции от имени пользователя кошелек должен отобрать конкретные UTXO для использования в качестве входов транзакции.

    Например, если Элис хочет заплатить Бобу 1 BTC и в ее кошельке содержится несколько UTXO на общую сумму 5 BTC, кошелек должен определить, какие из этих UTXO будут потрачены в транзакции. Это решение не тривиально и зависит от приоритетов пользователя. Некоторые методы выбора монет отдают приоритет расходованию меньших непотраченных выходов, чтобы избежать накопления пыли, другие — расходованию разумно бо́льших выходов, чтобы минимизировать комиссии, третьи ставят во главу угла приватность пользователей и/или избегают образования выходов для сдачи.

    Обычно выбор монет определяется встроенным в кошелек алгоритмом, но некоторые кошельки позволяют пользователям самостоятельно выбирать настройки согласно собственным приоритетам.

    а – я ↩

    Высота блока (block height)

    Блокчейн — это набор блоков, связанных между собой в неизменном хронологическом порядке. Начиная с нулевого блока, блока генезиса, все блоки нумеруются в порядке возрастания. Этот номер называют высотой блока.

    Текущая высота блока — это просто количество блоков в блокчейне минус один. Высоту блока можно использовать в качестве ссылки на момент времени в истории блокчейна. Например, халвинги в Bitcoin происходят на определенных высотах блоков (каждые 210 000 блоков). Кроме того, некоторые bitcoin-транзакции могут быть иметь временную блокировку (timelock) до определенной высоты блока.

    а – я ↩

    Выход для сдачи (change output)

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

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

    а – я ↩

     

    Г

    Генераторная точка (generator point)

    Генераторная точка, называемая G, представляет собой определенную точку на эллиптической кривой secp256k1 Биткойна и имеет координаты x и y. Чтобы сгенерировать открытый ключ, пользователь умножает свой секретный ключ sk * G = P, где P — это открытый ключ.

    В то время как секретный ключ — это большое число, открытый ключ — это точка с координатами x и y. Аналогичным образом, и сама G тоже является валидным открытым ключом.

    Как и у большинства открытых ключей, координаты генераторной точки чрезвычайно велики. Кодированная в формате SEC генераторная точка может быть записана как 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798.

    а – я ↩

    Группирование платежей (batching)

    Так называется объединение нескольких платежей в одну транзакцию с множеством выходов. Поскольку размер комиссии в Биткойне зависит от используемого объема данных, а не от суммы платежа, объединение нескольких транзакций в одну может сократить общий расход данных и, следовательно, снизить комиссию за обработку этих платежей.

    Например, если Элис хочет заплатить 0,5 BTC Бобу, 0,3 BTC Чарли и 0,2 BTC Дэвиду, она может создать транзакцию с одним входом на 1 BTC и тремя выходами, вместо трех транзакций с двумя выходами каждая — один для получателя платежа, другой для сдачи от расходуемого UTXO.

    Выгода от группирования платежей особенно заметна с увеличением масштаба. Например, биржа, желая обработать 100 запросов клиентов на вывод средств, может сделать это либо в 100 отдельных транзакциях, либо в одной транзакции со 100 выходами. Второй вариант дает значительную экономию на комиссиях.

    а – я ↩

     

    Д

    Двойное расходование (double spend)

    Двойное расходование происходит, когда кто-то может потратить одни и те же деньги дважды, обманув одну или несколько сторон и заставив их поверить, что они получили оплату.

    Для цифровых объектов, таких как файлы или текст, легко создать дубликат. Но для денежных единиц простое создание дубликатов определенно не является желаемым качеством. Это и описывает проблему двойного расходования: как получатель цифровых денег может быть уверен, что те же денежные единицы не были одновременно отправлены и кому-то другому? И как все участники денежной системы могут быть уверены, что остальные не дублируют денежные единицы по собственному желанию?

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

    Подробнее о проблеме двойного расходования

    а – я ↩

    Дерево хешей (дерево Меркла) (Merkle tree)

    Андреас Антонопулос предложил одно из наиболее ясных определений: «дерево хешей используется для суммирования всех транзакций в блоке, создавая общий цифровой отпечаток всего набора транзакций и обеспечивая высокоэффективный процесс проверки того, включена ли транзакция в блок» (A. Antonopoulos, 2015, «Mastering Bitcoin», изд. O’ Reilly, стр. 168).

    а – я ↩

    Дескрипторы скрипта выхода (output script descriptors)

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

    Дескрипторы хорошо комбинируются с минискриптами, позволяя кошельку отслеживать и подписывать широкий спектр скриптов. Они также хорошо сочетаются с PSBT, позволяя кошельку определять, какие ключи он контролирует в multisig-скрипте.

    а – я ↩

    Децентрализованный реестр (decentralized ledger)

    Децентрализованный реестр — это запись всех транзакций в сети. Этот реестр поддерживается и обновляется множеством независимых нод (узлов сети), которые взаимодействуют друг с другом на основе набора правил, установленных протоколом. Bitcoin для организации сети и ведения ее децентрализованного реестра использует блокчейн и механизм proof-of-work.

    Традиционные банки используют для отслеживания остатков централизованные реестры. Каждое отделение банка периодически обновляет центральный реестр, но этот реестр не является ни публичным, ни легко проверяемым извне. Протокол Биткойна меняет эту парадигму, позволяя любому человеку читать и вносить записи в общий реестр, следуя определенным правилам. Любой может опубликовать bitcoin-транзакцию. Майнеры добавят эту транзакцию в блокчейн, к которому любой желающий может обратиться, чтобы проверить балансы и историю транзакций.

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

    а – я ↩

     

    Е

    Единица веса (weight unit) (wu)

    Единица веса — это единица измерения размера транзакций и блоков, принятая с обновлением SegWit. Часто название «единицы веса» (weight units) сокращается до wu. До активации SegWit транзакции и блоки измерялись в байтах, и размер блока ограничивался 1 МБ или 1 миллионом байт. После активации SegWit транзакции блоки принято измерять в «единицах веса», и размер блока в этом исчислении ограничивается 4 млн wu.

    В обычной биткойн-транзакции один байт эквивалентен 4 wu. Однако в SegWit-транзакциях каждый байт раздела Witness, в который обычно включаются подписи, учитывается как 1 wu. Это позволяет платить за такие транзакции меньшую комиссию по сравнению с биткойн-транзакциями старого типа. Таким образом, если блок состоит целиком из транзакций старого типа, лимит размера блока в 4 млн wu по-прежнему эквивалентен 1 МБ, но если блок включает в себя SegWit-транзакции, то допустимый размер валидного блока в байтах может быть увеличен вплоть до 4 МБ данных.

    а – я ↩

     

    З

    Заголовок блока (block header)

    Блок — это набор транзакций. Каждый блок также включает в себя метаданные со сводной информацией о блоке. Эти метаданные известны как «заголовок блока». В заголовок блока включается несколько фрагментов данных:

  • Высота блока указывает на то, сколько блоков было перед этим блоком.
  • Хеш блока. Хеш заголовка блока играет роль «доказательства работы» для данного блока.
  • Хеш предыдущего блока. Хеш заголовка предыдущего блока обеспечивает неизменность предыдущих блоков.
  • Метка времени указывает на то, когда блок был опубликован.
  • Корень хеш-дерева — хеш всех транзакций, включенных в этот блок.
  • Сложность. Сложность кодируется и называется «битами».
  • Nonce — случайное число, помогающее майнерам соответствовать требованиям proof-of-work.
  • Заголовок блока служит сводкой его содержания и может пересылаться по сети и обрабатываться быстрее, чем полный блок. Когда майнеры непрерывно хешируют свой блок в поиске валидного хеша, соответствующего требованиям proof-of-work, они фактически хешируют заголовок блока, а не весь блок.

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

    а – я ↩

     

    К

    Ковенант (covenant)

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

    Например, ковенант может обычно позволять отправлять биткойны только на скрипты из белого списка — например, возвращать биткойны на собственный баланс пользователя или отправлять на промежуточный адрес, с которого их можно будет потратить на любой адрес, но только через определенный промежуток времени.

    а – я ↩

    Код операции (опкод) (opcode)

    Код операции, или опкод, — это базовая команда в некоторых компьютерных языках. Скриптовый язык Биткойна, называемый Script, имеет свой набор кодов операций. Каждый опкод пронумерован и выполняет ограниченную предопределенную функцию. Из комбинации этих опкодов и дополнительных данных, таких как адреса, открытые ключи и подписи, можно создавать биткойн-скрипты.

    Например, самый распространенный из скриптов Биткойна — это P2PKH, который состоит из четырех опкодов и хеша открытого ключа. Этот скрипт представляет собой тип ScriptPubKey, который используется для блокировки BTC таким образом, что потратить их может только тот, кто сможет создать открытый ключ и валидную подпись.

    а – я ↩

    Комиссия за транзакции (transaction fee)

    Все биткойн-транзакции должны включать в себя комиссию, чтобы быть включенными в блокчейн. Эти комиссии составляют часть экономического стимула для майнеров. Чем выше комиссия за транзакцию, тем сильнее майнер заинтересован в том, чтобы включить ее в блок, а значит, тем быстрее она будет подтверждена. Поскольку майнеры могут включить в каждый блок только 4 МБ данных, они оценивают транзакции с точки зрения соотношения размера комиссии и используемого объема данных, а не просто по общей уплачиваемой комиссии. Поэтому большинство кошельков отображают комиссии в пересчете на сат./vБайт.

    Размер комиссий за биткойн-транзакции сильно колеблется: многие транзакции отправляются с более высокой комиссией, чтобы гарантировать быстрое подтверждение, другие отправляются с низкой комиссией и просто дольше ждут подтверждения. Большинство биткойнеров ожидают, что в дальнейшем размер комиссий будет увеличиваться по мере роста спроса на транзакции в сети. Существует несколько способов сэкономить на транзакциях, включая консолидацию UTXO, группирование платежей и использование новейших типов транзакций, особенно SegWit.

    а – я ↩

    Консенсус (consensus)

    Консенсус — это идеал и метод координации между отдельными лицами в децентрализованной системе, такой как Биткойн или другие проекты с открытым кодом. Консенсус не является формой демократии: в системе, основанной на консенсусе, нет форм голосования, представительства, наделения особыми полномочиями или централизованного контроля доступа в сообщество. Консенсус не подразумевает также и 100% согласия. Полный консенсус — это идеал в том смысле, что в большинстве случаев абсолютное согласие между всеми заинтересованными сторонами не достигается.

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

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

    а – я ↩

    Корень дерева хешей (корень Меркла) (Merkle root)

    Корень — это последний узел в дереве Меркла. Это хеш, который включает в себя все остальные хеши дерева. Если в дереве будет изменен хотя бы один хеш, это изменение будет передано по схеме дальше и полностью изменит корень дерева.

    Корневые хеши используются в Биткойне для эффективного подтверждения больших наборов данных. Корневой хеш всех ID транзакций (txid) в блоке включается в заголовок блока, так что если этот корень будет изменен, то proof-of-work для блока окажется недействительным. Это гарантирует, что после публикации блока никакая из включенных в него транзакций не будет изменена. Чтобы обеспечить ту же гарантию неизменности SegWit-транзакциям, корневой хеш всех ID SegWit-транзакций (wtxid) включается в выход coinbase-транзакции блока. Корни Меркла используются также MAST скриптами для отправки биткойнов в несколько различных скриптов.

    а – я ↩

    Кошелек (wallet)

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

    Кошельки наиболее полезны, чтобы несколько абстрагировать пользователей от технических нюансов Биткойна и криптографии и упростить для них хранение BTC и совершение транзакций с ними. Кошельки отображают для пользователей их балансы, историю транзакций и адреса, которые они могут публиковать для получения платежей.

    Важно выбирать кошелек с качественными практиками обеспечения безопасности и конфиденциальности, а также не забывать о резервном копировании на случай утери или поломки устройства.

    а – я ↩

    Кошелек только для просмотра (watch-only)

    Watch-only — это термин, используемый для описания кошельков, которые не хранят и не используют секретные ключи. Они используют только открытые ключи, позволяя пользователям просматривать свои балансы и получать биткойны. Однако при этом они не могут подписывать или расходовать биткойны.

    Такая конфигурация оптимальна для холодного хранения BTC, позволяя пользователям отслеживать свои средства, никак не раскрывая в интернете свои секретные ключи.

    а – я ↩

    Криптовалюта (cryptocurrency)

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

    а – я ↩

     

    М

    Майнинг (mining)

    Майнинг — это процесс построения блокчейна путем добавления к нему новых блоков, по одному за раз. Сначала майнеры создают блок, отобрав для него некоторое количество неподтвержденных транзакций из мемпула. Это сравнительно простой шаг. Затем майнеры ищут proof-of-work, или валидный хеш созданного блока. Этот поиск, по сути, представляет собой энергоемкую игру в «угадайку».

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

    У майнеров нет лучшего способа получить валидный хеш, чем создавать хеш наугад и проверять его валидность. Поэтому они стремятся получить как можно больше попыток, затратив на это как можно меньше времени и энергии. Скорость, с какой происходит процесс угадывания, называется хешрейтом или просто скоростью хеширования и измеряется в хешах в секунду. Совокупный хешрейт всех биткойн-майнеров — важный показатель безопасности Биткойна, поскольку от этого зависит, какой хешрейт потребуется злоумышленнику для атаки 51%.

    Этот процесс называется майнингом (от англ. mining, добыча ископаемых), потому что, как и с добычей золота, стоимость добычи нового биткойна примерно равна его стоимости. Другими словами, в Биткойне никто не может «напечатать» деньги бесплатно.

    а – я ↩

    Мемпул (mempool)

    Мемпул (от memory pool, пул памяти) — это меньшая база данных из неподтвержденных транзакций, которую хранит каждая нода. Когда транзакция получает подтверждение, будучи включенной в блок, она удаляется из мемпула. Ноды обмениваются данными мемпула, транслируя друг другу подписанные транзакции, однако единого мемпула нет и лишь немногие ноды, если таковые вообще имеются, хранят мемпул целиком. Майнеры отбирают транзакции из мемпула для включения в свои блоки.

    а – я ↩

    Метка времени (timestamp)

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

    а – я ↩

    Механизм консенсуса (consensus mechanism)

    Механизм консенсуса (consensus mechanism) блокчейна — это совокупность правил (алгоритмов) и устойчивый к отказам механизм, посредством которого каждый узел сети подтверждает либо отклоняет любые предлагаемые изменения в блокчейн, которым он управляет. Одно из применений механизма консенсуса заключается в ведении записей. Существуют различные типы алгоритмов механизма консенсуса с разными наборами правил (например, proof-of-work [PoW] и proof-of-stake [PoS]).

    а – я ↩

    Микширование (mixing)

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

    Сервисы микширования BTC становились предметом юридических разногласий, а некоторые из них были закрыты по обвинениям в отмывании денег. Это связано с тем, что микшеры, в отличие от CoinJoin-сервисов, для выполнения операции принимают средства пользователей на хранение.

    а – я ↩

    Мнемоническая фраза (mnemonic)

    Мнемоническая фраза — это упорядоченный список из 12–24 слов, используемых для резервного копирования кошелька. Эта фраза представляет собой способ выражения seed-значения, то есть фрагмента данных, на основе которого генерируются все ключи в HD-кошельке. Мнемоническую фразу иногда называют также seed-фразой или фразой восстановления.

    Мнемонические фразы — включены в стандарт Биткойна с принятием BIP-39, реализованным в большинстве кошельков. Значительная часть кошельков также позволяет пользователям добавлять в конец списка слов свою уникальную парольную фразу — для повышения безопасности.

    Мнемонические слова выбираются из определенного списка из 2048 слов, любая комбинация которых является допустимой мнемонической фразой, генерирующей валидный набор ключей. Таким образом, вероятность правильно угадать чью-либо мнемоническую фразу составляет 1 из 2048^24 или 2,96 * 10^79 попыток.

    а – я ↩

    Мультиподпись (многосторонняя подпись) (multisig)

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

    Настройки мультиподписи обычно описываются как m-из-n, где для выполнения транзакции требуются подписи как минимум m различных секретных ключей, и эти секретные ключи должны соответствовать любым из n определенных открытых ключей. Например, при типичной настройке «2-из-3» определяются три открытых ключа, и для того, чтобы разблокировать и потратить BTC с такого multisig-адреса, транзакцию должны будут подписать любые два из соответствующих секретных ключей.

    Большинство транзакций с мультиподписью выполняются как P2SH-транзакции, так что соответствующие адреса будут начинаться с «3». В этих случаях точный скрипт, определяющий то, какие ключи требуются для выполнения транзакции, не раскрывается в блокчейне до тех пор, пока биткойны не будут потрачены. Это означает, что для того чтобы потратить биткойны с multisig-адреса, получатели биткойнов, на основе чьих ключей был сформирован этот адрес, должны запомнить соответствующую настройку. Эта настройка называется RedeemScript и она позволяет востребовать и тратить биткойны с multisig-адреса.

    Рассмотрим пример: Элис, Боб и Чарли собираются основать компанию и хотят поместить на совместное хранение какое-то количество BTC. Чтобы гарантировать, что ни один из участников не сможет украсть общие средства, Элис, Боб и Чарли делятся одним открытым ключом каждый. Они также решают, что будут принимать решения на основе простого большинства голосов. Таким образом, для расходования общих BTC с адреса с мультиподписью будет достаточно двух подписей. Это требование двух подписей от любых из трех открытых ключей преобразуется в форму скрипта, который хешируется в адрес, на который все три партнера смогут отправлять взносы в фонд компании. Такую настройку можно описать как мультиподпись 2-из-3.

    а – я ↩

     

    Н

    Награда за блок (block reward)

    Награда за блок представляет собой сумму субсидии на блок и комиссий за все транзакции, включенные в этот блок. Когда майнер находит валидный блок, он получает предусмотренную протоколом субсидию в виде новосозданных BTC. Кроме того, все транзакции также включают комиссию, которая собирается майнерами. В сумме эти два значения составляют общую награду за блок. Поскольку размер субсидии сокращается вдвое каждые четыре года, комиссии постепенно будут составлять все большую часть награды за блок. Иногда термины «субсидия на блок» и «награда за блок» используют взаимозаменяемо.

    Награда за блок выплачивается в coinbase-транзакции с каждым блоком. Эта специальная транзакция добавляется в каждый блок первой и не имеет входов. Выходы coinbase-транзакции не могут быть потрачены в ближайшие 100 блоков, то есть майнеры могут потратить полученные в награду за блок BTC не раньше, чем через 100 блоков.

    а – я ↩

    Начальная загрузка блоков (initial block download)

    Начальная загрузка блоков — это процесс построения с нуля локальной копии полного блокчейна Биткойна. При настройке и подключении к сети новой ноды, она связывается с другими нодами и запрашивает у них блоки. Новая нода обрабатывает полученные блоки и выстраивает их в блокчейн до тех пор, пока он не догонит сеть и не синхронизируется с ней полностью.

    Хотя блоки запрашиваются с отдельных частных нод, процесс начальной загрузки также не подразумевает необходимости доверия другим участникам, потому что нода может получать данные с различных узлов сети по выбору оператора и самостоятельно проверяет эти данные, а также из-за самой природы proof-of-work блокчейна. Процесс начальной загрузки может занять несколько дней или недель, в зависимости от пропускной способности интернет-соединения и технических характеристик компьютера.

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

    а – я ↩

    Нода (node) или узел сети

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

    Подробнее о bitcoin-нодах:

  • Что такое Биткойн-нода
  • Для чего запускать свою биткойн-ноду?
  • Как запустить bitcoin-ноду
  • Полный узел Биткойна: руководство по обеспечению суверенитета
  • а – я ↩

     

    О

    Ончейн (on-chain)

    Термин «ончейн» используется для описания любых данных, зарегистрированных в основном блокчейне, в отличие от офчейн-данных, которые не хранятся в блокчейне. В Bitcoin ончейн-данные всегда представляют собой bitcoin-транзакции, в то время как офчейн-данные могут быть как неподтвержденными транзакциями, так и любым другим типом данных.

    а – я ↩

    Открытый ключ (public key)

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

    а – я ↩

    Орфанный блок (orphan block)

    В Биткойне блоки должны добавляться с интервалом в ~10 минут, но иногда два новых блока могут появляться в одно и то же время. Один блок может быть отправлен сначала в одну половину сети, а другой — в другую половину сети. Ноды сохраняют оба блока, так как оба они валидны. В результате образуются две валидные ветки блокчейна. Однако, по мере добычи майнерами новых блоков они будут добавляться либо к одной, либо к другой ветке. В конце концов одна из веток станет длиннее другой, и все ноды будут считать действительной ее, отказавшись от более короткой. Более короткая заброшенная ветка — это цепочка орфанных блоков. Чаще всего такая орфанная ветка имеет длину всего в один блок, однако нет никаких ограничений на количество блоков, которые могут стать орфанными в результате реорганизации или длительного периода неопределенности, когда две валидные ветки имеют равную длину.

    Поскольку это событие наносит значительный финансовый ущерб майнеру, чей блок стал орфанным, для сети важно минимизировать количество орфанных блоков. Для этого нужно, чтобы распространение новых блоков между нодами происходило как можно быстрее. И в этом состоит одна из причин ограничения веса (размера) блока.

    а – я ↩

    Офчейн (off-chain)

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

    а – я ↩

     

    П

    Пакетная ретрансляция (package relay)

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

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

    Основное препятствие для добавления поддержки пакетной ретрансляции в p2p протокол Биткойна состоит в том, чтобы удостовериться, что ее реализация не создает никаких новых векторов для DoS-атак.

    Первичный код и документация:

  • Package relay strawman proposal
  • Package relay design questions
  • а – я ↩

    Пиннинг транзакций (transaction pinning)

    Пиннинг (от англ. pin – пришпилить, пригвоздить) транзакций — это метод, позволяющий сделать ускорение обработки «застрявшей» в мемпуле транзакции через повышение комиссии запретительно дорогостоящим для другой стороны. Это достигается через злоупотребление защитой нод от атак, которые могут приводить к потере пропускной способности, чрезмерному расходу ресурсов CPU и памяти. Это может усложнить управление комиссиями в протоколах, работающих на основе контрактов с несколькими участниками (таких как Lightning Network).

    Ноды — как Bitcoin Core, — позволяющие заменять транзакции по replace-by-fee (RBF) или ускорять их обработку по схеме «ребенок платит за родителя» (CPFP), накладывают ограничения на такие способы ускорения, чтобы предотвратить различные DoS-атаки. Однако когда две (или более) стороны могут ускорить транзакцию через повышение комиссии, эти ограничения позволяют одной из сторон исчерпать один из лимитов по определенной транзакции и лишить остальных возможности воспользоваться таким ускорением.

    Некоторые из ограничений, которые можно использовать для пиннинга транзакций, включают:

  • Replace-by-fee правило #3 из BIP 125 требует, чтобы замещающая транзакция платила более высокую комиссию в абсолютном выражении (а не только имела более высокую ставку комиссии), чем заменяемая и любая из ее дочерних транзакций. Это открывает для злоумышленника возможность присоединить к транзакции, которую он хочет «запиннить», крупную транзакцию с низкой ставкой комиссии, вынуждая другую сторону, если она захочет ускорить обработку транзакции через повышение комиссии, платить также за замещение большой дочерней транзакции. Например, при настройках по умолчанию Bitcoin Core 2019, атакующий может вынудить честного участника заплатить за ускорение транзакции минимум 0,001 BTC (или даже большие суммы в некоторых случаях).
  • Ограничения на размер пакета не позволяют использовать CPFP, если транзакция имеет более чем 101 000 vБайт дочерних транзакций в мемпуле или более чем 25 дочерних или родительских транзакций. Это позволяет злоумышленнику блокировать попытки ускорения определенной транзакции, создав максимальное количество дочерних транзакций. Если злоумышленнику приходится создавать эти транзакции по другим причинам (например, он управляет неким сервисом, делающим частые выплаты пользователям), то такая атака может быть для него даже бесплатной. В некоторых протоколах, работающих на основе двусторонних контрактов (как нынешняя Lightning Network), эта проблема обходится за счет политики исключения для CPFP (CPFP carve out).
  • а – я ↩

    Пластичность (malleability)

    Пластичностью транзакции называют способность транзакции иметь более одного валидного ID. Пластичность возникает, когда часть транзакции можно изменить после ее подписания, не сделав подпись недействительной. Поскольку txid представляет собой хеш транзакции, любое изменение транзакции приведет к изменению txid. Однако изменения, которые приводят к изменению txid и делают подпись недействительной, не являются проблемой; проблему пластичности создают только те изменения, которые изменяют txid, но не делают подпись транзакции недействительной.

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

    Вызвать проблему пластичности, изменив транзакцию, можно двумя способами. Во-первых, после подписания в ScriptSig могут быть добавлены дополнительные данные. Во-вторых, может быть изменена сама подпись, содержащаяся в ScriptSig. Оба эти варианты возможны, потому что подпись не может подписывать сама себя.

    Проблема пластичности транзакций была устранена с обновлением SegWit, что позволило реализовать больше инноваций на основе Биткойна, включая Lightning Network и Taproot. SegWit устранил проблему пластичности транзакций, за счет перемещения ScriptSig — подписи транзакции и ее изменяемой части — из тела транзакции в отдельный раздел Witness.

    Публичные (public) (или открытые) реестры и блокчейны

    Публичные (public) (или открытые) реестры и блокчейны открыты для всех, то есть каждый может получить к ним доступ пользоваться ими.

    а – я ↩

    Подпись (signature)

    Теоретически цифровая подпись похожа на подпись физическую, но гораздо более надежна и безопасна. Как и ее физический аналог, цифровая подпись указывает на подтверждение и/или заверение подписываемых данных. В отличие от физической, цифровую подпись нельзя скопировать и вставить, поскольку подпись уникальна для каждого подписываемого фрагмента данных.

    Например, если вы создадите подпись для текста «Привет», она будет недействительна для текста «Здравствуй». Эта особенность позволяет публиковать цифровые подписи без риска мошенничества.

    Цифровая подпись состоит из трех частей: подписываемых данных, открытого ключа подписывающего лица и самой подписи. Данные могут быть любыми цифровыми — текст, картинка, аудиофайл и прочее. Открытый ключ — это псевдонимная форма идентификации, информирующая общественность о том, что данное сообщение подписал владелец соответствующего секретного ключа. Наконец, подпись — это математическое доказательство того, что владелец открытого ключа и соответствующего ему секретного ключа подписал в точности представленные данные.

    Магия здесь в том, что секретный ключ необходим для создания подписи, но не требуется для ее проверки. Кто угодно может проверить валидность подписи с помощью только открытого ключа. Кроме того, поскольку подпись создается с использованием хеша подписываемых данных, проверяющий может быть уверен в том, что предоставленные данные не изменились с того момента, как были подписаны.

    а – я ↩

    Подпись Шнорра (Schnorr signature)

    Подпись Шнорра — это тип схемы цифровой подписи, аналогичный схеме ECDSA, которая используется в Биткойне с момента его создания. Схема Шнорра имеет ряд преимуществ перед ECDSA и ее поддержка была реализована в Биткойне недавно с обновлением Taproot.

    Во-первых, схема Шнорра доказуемо безопасна и непластична — два улучшения по сравнению с ECDSA. Во-вторых, в сравнении с ECDSA, подписи Шнорра требуют меньше времени на проверку. Подписи Шнорра могут быть объединены с открытыми ключами, то есть несколько сторон с уникальными секретными ключами могут гораздо эффективнее подписывать одно и то же сообщение. Благодаря этому свойству, подписи Шнорра можно проверять пакетами, а не по отдельности, что еще больше ускоряет проверку.

    Кроме того, агрегирование ключей и подписей повышает конфиденциальность за счет сокрытия количества подписей, присутствующих в транзакции. Наконец, подписи Шнорра компактнее, чем ECDSA, что дает экономию на комиссиях для тех, кто тратит выходы Шнорра.

    На момент запуска Биткойна схема Шнорра еще была защищена патентом, поэтому Сатоши Накамото решил использовать в Биткойне другую схему подписи, ECDSA. С тех пор срок действия патента истек, и подписи Шнорра стало возможно использовать в Биткойне.

    Подробнее о схеме Шнорра

    а – я ↩

    Подтверждение (confirmation)

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

    Когда биткойн-транзакция отправляется из кошелька в сеть, расчет по ней не происходит немедленно. Сначала она попадает в мемпул, где считается ожидающей обработки. Формируя блоки, майнеры отбирают наиболее прибыльные транзакции с самым высоким соотношением размера комиссий к объему обрабатываемых данных. После того как транзакция была включена в валидный блок, она удаляется из мемпула и считается подтвержденной.

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

    а – я ↩

    Проблема дискретного логарифмирования (Discrete Log Problem, DLP)

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

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

    Безопасность Биткойна тоже строится на проблеме дискретного логарифмирования. Для реализации криптографии с открытым ключом в Биткойне используется эллиптическая кривая secp256k1. Секретные ключи — это большие случайные числа. Секретный ключ sk умножается на публично определенную генераторную точку G, чтобы получить другую точку на кривой P, открытый ключ. Благодаря проблеме дискретного логарифмирования, такое умножение не может быть обращено вспять, поэтому открытый ключ нельзя использовать для получения секретного ключа.

    Невозможность деления точек на эллиптических кривых также позволяет этой схеме поддерживать схемы цифровых подписей, таких как ECDSA или подписи Шнорра. Цифровая подпись подтверждает, что подписант знает секретный ключ и передает определенное сообщение без раскрытия самого секретного ключа.

    а – я ↩

    Проблема оракула (oracle problem)

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

    Однако бездоверительное (trustless) включение в смарт-контракт внешних данных — таких, как счет спортивной игры, — пока невозможно. В настоящее время не существует подтвержденного способа гарантировать, что информация, предоставленная контрагентом по контракту или третьей стороной, является корректной. Хотя в нескольких проектах и схемах предпринимались попытки свести доверительный характер оракула к минимуму.

    а – я ↩

    Прообраз (preimage)

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

    Прообразом может быть любой фрагмент данных. Например, адреса создаются путем хеширования открытого ключа. Аналогичным образом, заголовок блока является прообразом для proof-of-work блока, который представляет собой хеш заголовка.

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

    Lightning Network тоже использует прообразы для подтверждения оплаты lightning-счета. В этом контексте HTLC-контракт выступает как обязательство, обещая выплатить узлу маршрутизации комиссию в обмен на маршрутизацию желаемого платежа, в то время как прообраз, (нехешированный) контракт с блокировкой по времени, является подтверждением того, что обязательство выполнено. HTLC отправляются с ноды плательщика, через маршрутизирующий узел, на принимающую ноду, которая возвращает прообраз HTLC узлу маршрутизации, а он использует этот прообраз для затребования обещанной комиссии.

    а – я ↩

    Путь вывода (путь деривации) (derivation path)

    Путь вывода — это фрагмент даных, который сообщает иерархическому детерминированному (HD) кошельку, как получить определенный ключ в дереве ключей. Пути вывода используются как часть стандарта Биткойна и были введены вместе с HD-кошельками в BIP32.

    Каждый ключ в дереве HD-кошелька может быть описан через его путь вывода, содержащий информацию о глубине и индексе, т. е. о положении ключа в древовидной структуре. Главный ключ обозначается просто как ‘m’ (от master key).

    Первый дочерний элемент главного ключа имеет путь вывода «m/0», а пятый дочерний элемент этого дочернего ключа — «m/0/4». Глубина каждого дочернего элемента определяется количеством уровней, каждый из которых отделяется слэшем, между ним и главным ключом. Индекс каждого дочернего элемента — это его номер на соответствующем уровне, начиная с нуля. Например, ключ «m/0/4» имеет глубину 2 и индекс 4.

    Bitcoin Improvement Proposal 32 позволяет по каждому родительскому ключу выводить 2^32 дочерних. Дочерние ключи с номерами 0-2^31 — 1 считаются unhardened («неусиленными»), что означает, что родительский открытый ключ может выводить дочерние открытые ключи. В то время как для дочерних элементов с номерами 2^31-2^32 — 1 родительские открытые ключи не могут выводить дочерние. Только родительский закрытый ключ может вывести дочерний закрытый ключ, который затем можно использовать для получения дочернего открытого ключа. Эта спецификация обеспечивает гибкость в рамках стандарта HD-кошелька. Когда ключ становится hardened («усиленным»), он обозначается штрихом: ‘.

    Например, первый hardened «ребенок» главного ключа имеет путь вывода «m/0», а пятый unhardened дочерний ключ этого ключа имеет путь вывода «m/0’/4».

    а – я ↩

    Пылевая атака (dust attack)

    Иногда злоумышленники могут отправлять микроскопические доли BTC, около 500 сатоши, на случайные кошельки (из записанных в блокчейне). Если владелец кошелька этого не заметит, он может непреднамеренно включить такой микро-UTXO в свою следующую транзакцию, выдав злоумышленнику информацию о том, какими биткойнами он владеет.

    Пылевая атака напоминает размещение на жертве устройства слежения, позволяющего отслеживать ее перемещения или, в данном случае, какими биткойнами жертва владеет. Высококачественные кошельки пытаются любыми способами избежать включения пользователями «пыли» в свои транзакции, чтобы защитить их от такого рода атак.

    Если вы заметили, что на ваш кошелек поступило микроскопическое количество биткойнов, вам не следует расходовать эту «пыль» в одной транзакции с другими принадлежащими вам UTXO. Пылевая атака сработает только в том случае, если вы включите такую постороннюю «пыль» в одну транзакцию со своими выходами.

    а – я ↩

    Пыль (dust)

    Частица биткойна, называемая UTXO, может быть настолько мала, что комиссия за ее трансфер будет превышать ее стоимость. По мере роста комиссий «пылью» может считаться все большее количество BTC. Чтобы минимизировать формирование «пыли», рекомендуется консолидировать UTXO с очень небольшими суммами биткойнов в один больший UTXO в периоды, когда комиссии сети невысоки.

    а – я ↩

     

    Р

    Разветвленные платежи (multipath payments)

    Разветвленный платеж (multi-path payment, или MPP) — это тип lightning-платежа, который выполняется как атомарный набор меньших платежей. Эти меньшие платежи более надежны и просты исполнении, а также обеспечивают бо́льшую приватность, поскольку отследить наборы из нескольких разветвленных платежей сложнее, чем единый платеж. Разветвленные lightning-платежи атомарны, то есть они все частичные платежи должны быть успешными, иначе все они пройдут. Это делается во избежание путаницы с частичными платежами.

    Разветвленные платежи решают несколько проблем, с которыми сталкивается Lightning Network. Lightning-каналы обладают определенной емкостью, которая зависит от количества внесенных в канал сторонами биткойнов. Каждый пользователь может отправить лишь столько биткойнов, сколько он выделил на канал. Таким образом, для более крупных платежей требуется бо́льшая емкость каналов, а если ее окажется недостаточно, то платеж не пройдет. Эта проблема особенно актуальна для маршрутизируемых платежей, которые на пути от отправителя к получателю проходят по нескольким каналам. Чтобы снизить нагрузку на каналы от крупных платежей и облегчить их маршрутизацию, реализации Lightning позволяют пользователям или их lightning-кошелькам разбивать платежи на более мелкие части. Каждый меньший платеж может быть направлен по своему отдельному пути, что распределяет нагрузку между множеством разных каналов.

    Разветвленный (multipath) платеж, MPP, — это общий термин, актуальный не только для Lightning Network. В различных реализациях Lightning существуют различные предложения и реализации концепции multipath-платежей, включая Basic MPP и Atomic Multipath Payments (AMP). Эти различные версии пытаются решить несколько проблем безопасности и надежности, возникающих при реализации базовой концепции.

    а – я ↩

    Размер блока (block size)

    Размер блока — это объем включенных в этот блок данных, измеряемый в байтах. Майнерам не позволяется создавать блоки с размером больше определенного лимита, что накладывает ограничение на количество транзакций, которые майнеры могут включить в каждый блок.

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

    До активации SegWit размер биткойн-блоков был строго ограничен 1 МБ. После активации SegWit блоки измеряются по весу, а не по размеру. Максимально возможный размер валидного блока после активации SegWit составляет 4 МБ.

    а – я ↩

    Распределенный консенсус (distributed consensus)

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

    а – я ↩

    Реестры и блокчейны с ограниченным доступом (permissioned)

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

    а – я ↩

    Реестры и блокчейны с неограниченным доступом (permissionless)

    Такие блокчейны позволяют любому участнику действовать в качестве узла сети, то есть принимать участие в проверке транзакций или даже в определении метода достижения консенсуса. Bitcoin и Ethereum – два примера (публичных) блокчейнов с неограниченным доступом.

    Обратите внимание: различие между блокчейнами с ограниченным и с неограниченным доступом заключается в том, кто может запускать и поддерживать ноды в их сети. И публичные, и частные блокчейны могут быть как с ограниченным, так и с неограниченным доступом.

    а – я ↩

    Реорганизация (reorganization)

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

    Допустим, что блокчейн в настоящее время находится на высоте блока 500, то есть насчитывает 500 блоков. Один майнер создает блок #501 — назовем его 501a — и транслирует в сеть. Позже другой майнер, который либо пропустил блок #501a, либо, может быть, намеренно его игнорирует, добывает другой блок #501 — назовем его 501b. Оба блока не могут быть блоком #501, поэтому теперь существуют две конкурирующие ветки блокчейна. Майнеры могут выбирать, к какой ветке добавлять следующий найденный блок, и если майнеры добавят новый блок поверх 501b, эта ветка станет длиннее, чем 501a. Все ноды отбросят блок #501a, который теперь называется орфанным, и примут в качестве валидной ветки блоки #501b и #502b.

    Ноды всегда принимают в качестве валидной наиболее длинную ветку блокчейна.

    Этот процесс может происходить не только с отдельными блоками. Насколько позволяют создавшиеся условия, реорганизовано может быть любое количество блоков. Если блокчейн насчитывает 510 блоков и майнер решит найти альтернативный блок #500, а также каким-то образом успеет найти еще 11 блоков вслед за ним, эта новая цепочка из 511 блоков узурпирует исходную ветку.

    Однако, пока наш злонамеренный майнер добывает свои 12 блоков, честные майнеры продолжат майнить на исходной ветке. И к тому времени, когда атакующий найдет блок #500, исходная ветка будет насчитывать 511 или более блоков. Таким образом, как указано в уайтпейпер Биткойна, единственный способ провести успешную масштабную реорганизацию — это сделать так, чтобы большинство майнеров добывали блоки на замещающей ветке, чтобы она росла быстрее, чем исходная. Вот почему децентрализация майнинга и высокий хешрейт имеют определяющее значение для модели безопасности Биткойна. Чем выше хешрейт и чем в большей мере децентрализованы хеширующие мощности, тем сложнее недобросовестному майнеру провести реорганизацию.

    а – я ↩

     

    С

    Сайдчейн (sidechain)

    Сайдчейн — это протокол, который полагается на основной блокчейн сети в отношении передачи данных или обеспечения безопасности, но свои внутренние операции выполняет в отдельном блокчейне. Сайдчейн может использоваться, например, чтобы сочетать безопасность Биткойна с обеспечением большей пропускной способности и/или более дешевых транзакций.

    К примеру, сайдчейн Liquid от Blockstream является федерализованным, а не децентрализованным, и создает блоки строго каждую минуту, в сравнении с 10-минутным вероятностным интервалом Биткойна. ION от Microsoft — это сайдчейн-проект, реализующий цифровую идентификацию и полагающийся на блокчейн Биткойна для обеспечения безопасности данных.

    а – я ↩

    Сатоши (satoshi)

    Сатоши (сат.) — мельчайшая неделимая частица биткойна, названная в честь создателя Биткойна, Сатоши Накамото. Один биткойн состоит из 100 миллионов сатоши (1 BTC = 100 000 000 сат.). Таким образом, если общий объем предложения Биткойна ограничен 21 миллионном BTC, то максимальное количество сатоши составит 2,1 квадриллиона. Эта опция делает биткойны более делимыми, теоретически позволяя производить платежи стоимостью менее $0,01 по цене на момент публикации.

    В кодовой базе Биткойна все значения на самом деле выражены в сатоши, а единица BTC используется только на рынках и при обсуждении Биткойна.

    а – я ↩

    Связывание выходов (output linking)

    Связывание (ассоциирование) выходов происходит, когда пользователь получает два и более платежей на один и тот же открытый ключ или другой уникальный элемент скрипта. Это может произойти из-за повторного использования одного адреса пользователем — по незнанию или в результате преднамеренного таргетинга, как при «пылевой» атаке. Методы ограничения ущерба приватности от связывания выходов подпадают в категорию предотвращения повторного использования.

    Когда вы получаете несколько платежей на один и тот же биткойн-адрес, другие пользователи могут сделать обоснованное предположение о том, что все эти платежи получены одним субъектом сети, даже если эти выходы будут потрачены позже в отдельных транзакциях. Чтобы не создавать такие возможности для кластеризации биткойн-адресов и UTXO по субъектам сети, рекомендуется избегать повторного использования, создавая новый адрес для каждого получаемого платежа.

    К сожалению, пользователи не имеют полного контроля над получаемыми платежами. В пылевой атаке злоумышленник отправляет микроплатежи в BTC на адреса, которые уже появились в блокчейне, навязывая повторное использование адреса даже сознательным пользователям, которые пытались этого избежать. Некоторые кошельки пытаются решить эту проблему введением обязательного выбора «монет» (coin control) при создании платежа, что помогает пользователям избежать расходования «пыли» в транзакциях, в которых они хотят защитить свою конфиденциальность. Другие кошельки предлагают дополнительные функции, подразумевающие расход всех полученных на один адрес монет одновременно, но только однократно, устраняя таким образом ущерб для приватности вследствие повторного использования адреса, но создавая риск невозможности потратить средства, полученные на ранее использованный адрес.

    а – я ↩

    Секретный ключ (private key)

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

    а – я ↩

    Сложность (difficulty)

    Сложность — это мера того, насколько трудно добавить к блокчейну новый блок. Чтобы это сделать, майнер должен предоставить «доказательство работы» в форме действительного хеша блока, который они намерены опубликовать. Хеш, в сущности, представляет собой большое число, и для того чтобы он был действителен, он должен быть меньше определенного целевого числа. Это целевое число определяет сложность майнинга и устанавливается набором правил Биткойна.

    Сложность — динамическое значение: оно корректируется каждые 2016 блоков — примерно каждые две недели — таким образом, чтобы сохранить ~10-минутный интервал между блоками. Если к сети присоединяется больше майнеров и они начинают «добывать» блоки быстрее, сложность возрастает. Если майнеры отключаются и блоки начинают поступать медленнее, чем каждые 10 минут, сложность снижается. Таким образом, сложность напрямую зависит от хешрейта (скорости хеширования) сети.

    Технически сеть Биткойна определяет целевое число, а не непосредственно сложность. Все действительные хеши («доказательства работы») должны быть ниже этого целевого числа. Следовательно, сложность обратно пропорциональна величине целевого числа. Если целевое число растет, майнерам становится проще найти хеш ниже его, так что сложность снижается. И наоборот, если целевое значение снижается, то сложность майнинга возрастает.

    Целевое число кодируется как часть каждого заголовка блока и называется «битами» блока. Это позволяет нодам напрямую проверять, является ли представленный в качестве доказательства работы хеш ниже целевого числа.

    а – я ↩

    Смарт-контракт (smart contract)

    Смарт-контракт — это контракт, созданный и исполняемый в цифровом виде. Как и обычные контракты, смарт-контракты могут быть настолько сложными, насколько это позволяет язык, на котором они написаны. Возможности скриптового языка Биткойна, называемого просто Script, намеренно ограничены во имя сохранения простоты и безопасности Биткойна. Однако другие слои или приложения, построенные на основе Биткойна, часто используют более сложные смарт-контракты. Смарт-контракты можно использовать для оформления займов, отправки транзакций с временной блокировкой и даже для создания производных финансовых продуктов.

    Подробнее о смарт-контрактах Биткойна.

    а – я ↩

    Софт-форк (soft fork)

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

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

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

    а – я ↩

    Субсидия на блок (block subsidy)

    Субсидия на блок — это количество новых BTC, создаваемых в каждом блоке. Каждый новый блок, добавляемый в блокчейн, позволяет создателю блока создать и получить в качестве вознаграждения определенное количество новых монет.

    Это количество строго определено в исходном коде Биткойна: изначально оно составляло 50 BTC на блок и сокращается вдвое каждые 210 000 блоков или примерно 4 года. Субсидия на блок — это то, как поступают в обращение новые BTC, но также это стимулирует майнеров выполнять свои обязанности добросовестно и находить и транслировать в сеть валидные блоки. Субсидия на блок выплачивается в coinbase-транзакции с каждым блоком. Эта специальная транзакция добавляется в каждый блок первой и не имеет входов. Выходы coinbase-транзакции не могут быть потрачены в ближайшие 100 блоков, то есть майнеры могут потратить полученные в субсидии на блок BTC не раньше, чем через 100 блоков.

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

    а – я ↩

     

    Т

    Тестовая сеть (testnet)

    Тестовая сеть — это блокчейн, параллельный блокчейну Биткойна. Он работает почти идентично основной сети, но используется для тестирования и разработки.

    Тестнет полностью отделен от основной сети Биткойна и не монетизируется. Это делается для того, чтобы разработчики могли тестировать свое ПО, не подвергая риску деньги, не платя комиссии и не перегружая основной блокчейн.

    В целях упрощения тестирования сложность в тестовой сети Биткойна намного ниже, чем в основной. Это позволяет быстрее находить блоки и подтверждать тестовые транзакции.

    а – я ↩

    Технология распределенного реестра (Distributed Ledger Technology, DLT)

    Технология распределенного реестра (Distributed Ledger Technology, DLT) — это технология совместного использования электронного реестра многими участниками сети (узлами, устройствами) таким образом, чтобы обеспечить безопасность реестра, защиту от несанкционированного доступа и синхронизацию актуального состояния реестра между всеми узлами (до тех пор, пока реестр существует и обновляется через сеть). Одной из итераций дизайна распределенного реестра является блокчейн, и он может быть как публичным, так и частным.

    а – я ↩

    Токенизированный актив (tokenized asset)

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

    а – я ↩

    Транзакция (transaction)

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

    Готовая транзакция транслируется на узлы (ноды) сети Bitcoin. Эти ноды добавляют транзакцию в пул ожидающих обработки транзакций, называемый мемпулом, до тех пор, пока майнеры не добавят ее в блок. Только после добавления в блок транзакция считается подтвержденной. Безопасная практика состоит в том, чтобы дождаться, пока после блока с транзакцией не будет добавлено по крайней мере 5 новых блоков, прежде чем считать ее окончательной.

    «Под капотом» транзакция состоит из трех основных частей: входов, выходов и подписи. Входы транзакции — это просто части биткойна, называемые UTXO, которые плательщик собирается потратить. Выходы отправляют определенную сумму в биткойнах на указанный адрес путем создания нового UTXO. Транзакция может содержать любое количество входов и выходов. Наконец, для того чтобы транзакция была валидной, плательщик должен ее подписать, тем самым подтвердив право собственности на входы, которые он пытается в ней потратить. Эта подпись создается с помощью секретного ключа плательщика.

    Давайте теперь рассмотрим пример транзакции: Элис владеет UTXO на сумму 1 BTC и хочет заплатить Бобу 0,4 BTC. В качестве входа своей транзакции она использует UTXO на сумму 1 BTC. Для того чтобы Боб получил ровно 0,4 BTC, создается два выхода: первый — для Боба, в размере 0,4 BTC, и второй — для Элис, в размере 0,59 BTC. Это подразумевает уплату комиссии за транзакцию в размере 0,01 BTC.

    Комиссия за транзакцию не является выходом. Она рассчитывается как сумма входов (1 BTC) минус сумма выходов (0,4 + 0,59 = 0,99 BTC) и собирается майнером.

    Наконец, с помощью секретного ключа, контролирующего используемый UTXO на 1 BTC, Элис подписывает транзакцию и передает ее в сеть Bitcoin. При добавлении транзакции в блокчейн UTXO на 1 BTC будет уничтожен и будут созданы два новых UTXO на суммы 0,4 BTC и 0,59 BTC, принадлежащие Бобу и Элис соответственно.

    а – я ↩

     

    У

    Уровень (слой) (layer)

    Блокчейн Биткойна обеспечивает окончательный расчет по транзакциям с BTC за счет сравнительно низкой пропускной способности. В среднем сеть Bitcoin обрабатывает 4–7 транзакций в секунду. Этого очевидно недостаточно для проведения всех финансовых транзакций в мире, на что, по мнению многих криптоэнтузиастов, должен претендовать Bitcoin. В то время как крупные расчеты, для обеспечения максимальной безопасности платежей, могут по-прежнему выполняться в блокчейне, более мелкие транзакции с менее критичными требованиями к безопасности можно выполнять офчейн с помощью другой службы или протокола, образующих дополнительный уровень (слой) над основным блокчейном. Многоуровневые решения позволяют увеличивать пропускную способность и снижать комиссии ценой сравнительно меньшей безопасности платежей.

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

    Эти уровни имеют свои аналоги и в традиционной финансовой системе: кредитные карты, PayPal или Qiwi — все они работают «поверх» основной системы банковских платежей и системы ACH. До отмены золотого стандарта физические наличные деньги тоже представляли собой надстройку, слой, поверх базовых денег — золота.

    а – я ↩

     

    Ф

    Фабрика каналов (channel factory)

    Фабрика каналов — это многопользовательский контракт, позволяющий открывать платежные каналы без записи в блокчейн транзакции открытия канала.

    К примеру, три пользователя создают фабрику каналов путем внесения средств от каждой из сторон на адрес с мультиподписью 3-из-3. Посредством не транслируемых в сеть (офчейн) транзакций с этого адреса они открывают платежные каналы друг с другом (Элис↔Боб, Элис↔Чарли и Боб↔Чарли). Затем они могут использовать эти каналы настолько же безопасно, как если бы открыли их в ончейн-транзакции, поскольку при необходимости они могут транслировать в сеть транзакции открытия каналов. Однако если обе стороны действуют совместно, то необходимости в этом нет, что позволяет сократить объем используемых блокчейн-данных.

    В идеальных условиях фабрики каналов могут уменьшить для большого числа пользователей ончейн-размер и стоимость открытия/закрытия lightning-каналов на 90% и более.

    а – я ↩

    Форк (fork)

    Форк (ветвление) подразумевает изменение протокола или кодовой базы. Форки обычно используются для обновления проекта. В контексте блокчейн-проектов форки образуются, потому что разные пользователи загружают и запускают одно и то же ПО в разное время, возможно, в различных версиях и не всегда его обновляют. Если два пользователя загружают и запускают версию 1 некой программы, и только один из этих пользователей обновляется до версии 2 при ее появлении, то обновившийся пользователь работает с форком версии 1.

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

    В контексте блокчейнов существуют два вида форков: софт-форк и хард-форк. Софт-форки не нарушают совместимость между старой и новой версиями и, следовательно, не требуют обновления всех нод; они обратно совместимы. Хард-форки не обладают обратной совместимостью, и, следовательно, требуют обновления используемого ПО всеми нодами. В биткойн-комьюнити хард-форков избегают любыми доступными способами, отдавая безусловное предпочтение софт-форкам.

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

    а – я ↩

     

    Х

    Халвинг (halving)

    Халвинг (от англ. halving, деление пополам) — это событие, происходящее раз в четыре года и сокращающее вдвое скорость выпуска новых биткойнов. График выпуска биткойнов точно определяется алгоритмом в программном коде Биткойна. Этот алгоритм позволяет с каждым блоком выпустить определенное количество новых биткойнов в качестве компенсации майнеру, нашедшему валидный блок.

    Эти новые биткойны называют субсидией на блок, и первоначально она составляла 50 BTC за один блок. Однако субсидия сокращается в два раза с каждым халвингом, происходящим каждые 210 000 блоков — примерно раз в четыре года. Этот процесс будет продолжаться до тех пор, пока субсидия на блок не достигнет нуля. К тому моменту будет добыто более 7 миллионов блоков и проведено 34 халвинга.

    Читайте также:

  • Механика, лежащая в основе циклов параболического роста биткойна. Визуализация
  • Всё, что вам нужно знать о халвинге Биткойна
  • а – я ↩

    Хард-форк (hard fork)

    Форк обычно подразумевает изменение кодовой базы проекта. Биткойн — это проект с открытым исходным кодом, что означает, что кто угодно может скопировать его кодовую базу и изменить ее по своему усмотрению без всяких разрешений.

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

    а – я ↩

    Хеш-указатель (hash pointer)

    Хеш-функция используется в блокчейнах также для привязки каждого звена цепи к предыдущему: хеш-указатели могут использоваться для построения связанного списка, который также называется блокчейном. Хеш, хранящийся в указателе, – это хеш всех данных предыдущего блока, включая хеш-указатель на блок перед ним. Поскольку любое изменение входных данных изменяет выходные данные, в результате любого изменения предыдущего блока изменится и его хеш-указатель, и так далее с каждым последующим блоком, что обеспечивает блокчейну защиту от несанкционированного доступа (tamper-proof).

    а – я ↩

    Хеш-функция (hash function)

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

  • Все криптографические хеш-функции принимают входные данные, называемые прообразом, и выдают выходные данные, имеющие фиксированную длину и называемые хешем или дайджестом. Длина выхода зависит от конкретной используемой функции.
  • Выход криптографической хеш-функции является детерминистическим. Для данного входа выход всегда будет одним и тем же.
  • Криптографическая хеш-функция — это односторонняя функция. Выход легко можно рассчитать на основе входа. Однако нет известного способа определить вход на основе выхода.
  • Выход является случайным и непредсказуемым. Не существует известного метода для получения определенного выхода и расчета правильного входа для него. Также нельзя установить связь между рядом входов и их выходов. Например, если во входной строке длиной в 100 символов изменить один символ, то новый выход не будет иметь никакого сходства со старым.
  • Эти свойства делают криптографические хеш-функции очень полезными для Биткойна. Хеширование носит случайный и неконтролируемый характер, что гарантирует честную конкуренцию в биткойн-майнинге. Получение адреса путем хеширования открытого ключа или скрипта обеспечивает более высокий уровень безопасности, конфиденциальности и удобства для пользователей. Хеширование транзакций и блоков обеспечивает простой способ создания универсально уникальных идентификаторов и для транзакций, и для блоков. Наконец, деревья Меркла используют хеширование для создания надежных, неизменяемых сводок всех транзакций в блоке, что значительно повышает эффективность майнинга и проверки блоков.

    Биткойн для различных своих аспектов использует лишь несколько хеш-функций. Хеш-функция SHA-256 используется для создания proof-of-work и она же применяется дважды для генерации идентификаторов транзакций, txid. Для генерации хешей открытого ключа или адресов используется функция hash160, представляющая собой комбинацию хеш-функций SHA-256 и RIPEMD160.

    а – я ↩

    Хешрейт (hash rate)

    Хешрейт, или скорость хеширования, — это показатель того, сколько суммарно хешей в секунду производят майнеры в сети Биткойна. Один хеш — это одна попытка создать «доказательство работы» для блока. Майнерами по всему миру предпринимаются миллиарды таких попыток в секунду. Хешрейт показывает, сколько денег, энергии и вычислительных мощностей тратится на обработку транзакций и обеспечение безопасности сети.

    Хешрейт — это также и показатель того, сколько будет стоить атака 51% на сеть. Поскольку для атаки 51% требуется, чтобы злонамеренный майнер контролировал по меньшей мере 51% хеширующих мощностей сети, чем выше хешрейт, тем дороже будет стоить такая атака для любого майнера.

    Хешрейт Биткойна в последнее десятилетие рос быстрыми темпами, потому что рост цены BTC побуждает больше майнеров присоединяться к сети. На хешрейт влияют несколько факторов, включая цену BTC, тарифы и доступные количества электроэнергии, местные погодные условия и нормативную среду.

    а – я ↩

    Холодное хранение (cold storage)

    Термин «холодное хранение» описывает любой способ хранения данных на устройстве, не подключенном к интернету или каким-либо другим устройствам. Холодный кошелек — это вариант холодного хранения, часто используемый биткойнерами для защиты BTC, которые они не планируют часто перемещать.

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

    Холодное хранение безопаснее «горячего», потому что практически все вредоносные программы попадают на устройства через интернет. Однако это преимущество достигается в какой-то мере ценой удобства пользования. Поэтому холодное хранение обычно используют для больших объемов BTC, не предназначенных для каждодневного использования.

    а – я ↩

     

    Ц

    Цифровой актив (digital asset) и криптоактив (cryptoasset)

    Эти термины используются взаимозаменяемо. Криптоактив – это цифровой актив, в котором используются криптография, пиринговая (peer-to-peer) сеть и электронный реестр для достижения трех целей: 1) регулирования генерации новых единиц актива, 2) подтверждения транзакций и 3) обеспечения безопасности этих транзакций без необходимости в посреднике. Существуют различные типы криптоактивов: криптовалюты, токены протокола (protocol tokens), утилитарные токены (utility tokens), токены-акции (security tokens), токены на природные активы (natural asset tokens), стейблкойны (stablecoins), цифровые валюты центральных банков (CBDC), цифровые предметы коллекционирования.

    а – я ↩

     

    Ч

    Частные (private) реестры и блокчейны

    Частные (private) реестры и блокчейны не являются открытыми для всех по умолчанию, однако публике может быть предоставлен к ним доступ.

    Обратите внимание: различие между публичными и частными блокчейнами заключается в праве доступа к пользованию сетью: в одном случае оно есть у каждого по умолчанию, в другом оно может быть предоставлено, отнято либо ограничено.

    а – я ↩

     

    Э

    Эвристика по общему владению входами (common input ownership heuristic)

    Эвристика по общему владению входами (common input ownership) — одно из основных эвристических правил, используемых в блокчейн-анализе для определения владельца конкретных UTXO. В настоящее время эта эвристика основывается на предположении о том, что все входы той или иной транзакции принадлежат одному владельцу.

    Это эвристическое правило никогда не давало 100% надежного результата и по мере эволюции Биткойна надежность этого допущения продолжает снижаться. Такие технологии, как CoinJoin, CoinSwap, обычные мультиподписи и, в будущем, MuSig, все противоречат этому эвристическому правилу, объединяя в одной транзакции входы от многих пользователей.

    а – я ↩

    Эвристика по типу скрипта (script type heuristic)

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

    Например, если пользователь получает платеж на P2PKH-адрес, а затем тратит этот выход на создание двух выходов — один на P2SH-адрес и один на P2PKH-адрес, — можно предположить, что P2SH-выход принадлежит другому пользователю, тогда как P2PKH-выход является выходом для сдачи, принадлежащим отправителю.

    Как и все эвристические правила, используемые в блокчейн-анализе, это является допущением, и полученный с его помощью результат не может использоваться как окончательный источник истины. Кроме того, Taproot и будущие обновления протокола Биткойна могут значительно ограничить полезность этой эвристики, поскольку типы транзакций станут менее различимыми между собой.

    а – я ↩

     

    Я

    Якорные выходы (anchor outputs)

    Якорные выходы — это специальные выходы в commitment-транзакциях (транзакциях-обязательствах) Lightning Network, предназначенные для того, чтобы обработку транзакции можно было ускорить за счет повышения комиссии. Более раннее название этого предложения — simplified commitments (упрощенные обязательства).

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

    Возможное решение этой проблемы заключается в том, чтобы первоначально предусматривать в commitment-транзакции минимальную ставку комиссии, а затем любой участник канала мог бы ускорить обработку этой транзакции путем увеличения комиссии. Ранние решения, достигавшие этой цели через опцию Replace-By-Fee (RBF), столкнулись с проблемой «пиннинга» транзакций. В более поздних реализациях использовалось ускорение транзакций по схеме «ребенок платит за родителя» (CPFP), а проблема пиннинга обходилась через принятие политики CPFP carve-out, позволяющей одной CPFP-транзакции умеренно превышать пределы размера пакета и глубины узла, если эта транзакция имеет одного неподтвержденного предшественника.

    На момент написания самые последние версии дизайна добавляют в commitment-транзакции два выхода — по одному для каждой стороны lightning-канала — и требуют, чтобы все остальные выходы commitment-транзакции имели в своих скриптах условие 1 OP_CHECKSEQUENCEVERIFY (CSV), предотвращающее их расходование по крайней мере на один блок.

    Реализация всех возможностей протокола зависит также от внедрения на полных нодах Биткойна пакетной ретрансляции (package relay), позволяющей ускорить обработку commitment-транзакций через CPFP, даже если их комиссии ниже минимальной ставки за ретрансляцию, установленной нодой. Но до тех пор, пока пакетная ретрансляция не станет доступна, lightning-ноды могут просто устанавливать несколько более высокую комиссию для своих commitment-транзакций, чтобы гарантировать их принятие нодами.

    Первичный код и документация:

  • Anchor outputs
  • Zero HTLC fee anchor outputs
  •  

    A  B  C  D  E  G  H  I  J  L  M  N  P  R  S  T  U  V  W  X

    А  Б  В  Г  Д  Е  З  К  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Э  Я

     

     

    На основе источников:

  • River Financial glossary
  • Bitcoin Optech
  • Источник: bitnovosti.com

    Оставьте ответ

    Ваш электронный адрес не будет опубликован.