Глоссарий / Транзакции и комиссии
Locktime
Другие названия: nLockTime.
- Что такое Locktime?
- Locktime (блокировка по времени) занимает последние четыре байта транзакции и задает минимальную высоту блока или время по часам, начиная с которых сеть примет ее в блок.
Представьте locktime как выписанный на будущую дату чек, встроенный в протокол. Одно поле, два значения, и выбор между ними определяется порогом: любое значение ниже 500 000 000 считается числом блоков, а любое значение на этом уровне или выше считается секундами с 1970. Большинство транзакций, которые вы когда-либо отправите, будут нести locktime, и он не сделает ничего, кроме защиты от тонкой уловки майнеров.
Как это работает
Locktime стоит в самом конце сериализованной транзакции и проверяется раньше, чем рассматривается что-либо еще в отношении расхода.
Правило порога и позволяет одному полю выполнять две задачи. Locktime, равный 900 000, означает, что транзакция не может попасть в блок ниже высоты 900 000. Locktime, равный 1 800 000 000, представляет собой метку времени Unix и означает, что транзакция не может попасть в блок, пока медианное время предыдущих одиннадцати блоков не пройдет этот момент. Разделительная линия 500 000 000 соответствует 5 ноября 1985 года, что с запасом предшествует появлению биткоина и с запасом превышает любую правдоподобную высоту блока. Поле занимает четыре байта, поэтому максимально выразимое время приходится на 7 февраля 2106 года.
Есть переключатель. Locktime соблюдается только в том случае, если хотя бы у одного входа номер последовательности меньше 0xffffffff. Если у всех входов стоит 0xffffffff, поле полностью игнорируется, и именно так транзакции работали годами, пока кошельки не нашли ему применения.
Это применение состоит в защите от охоты за комиссиями (anti-fee-sniping). Когда комиссии высоки, у майнера, проигравшего гонку за блок, есть стимул попытаться заново намайнить предыдущий блок и забрать его комиссии вместо того, чтобы строить цепочку дальше. Если кошельки устанавливают locktime каждой транзакции на текущий кончик цепи, эти транзакции становятся недействительными в любом более раннем блоке, что устраняет большую часть добычи и сам стимул. Bitcoin Core делает это при обычных расходах и примерно в одном случае из десяти выбирает высоту равномерно из предыдущих 100 блоков, чтобы транзакции из разного кошелькового программного обеспечения не выделялись на фоне друг друга.
Где это видно
Откройте любую недавнюю транзакцию в обозревателе блоков, и поле locktime обычно содержит число, близкое к высоте, на которой она была добыта.
Это и есть поведение защиты от охоты за комиссиями, и его наличие представляет собой слабый отпечаток программного обеспечения, построившего платеж. Кошельки, которые оставляют поле нулевым, тоже о чем-то сообщают. Фирмы, занимающиеся анализом цепочки, читают это поле именно потому, что очень мало пользователей о нем задумываются.
Намеренные применения уже. Locktime в будущем создает транзакцию, которую можно подписать и передать сейчас, но не транслировать до более позднего момента, и это основа простых схем наследования и путей возврата. Транзакции принудительного закрытия в Lightning и submarine swaps используют временные блокировки, чтобы контрагент, который исчезнет, не мог навсегда заморозить ваши средства. Тому, кто строит такие транзакции, следует учитывать очевидную слабость: заблокированная транзакция стоит ровно столько, сколько стоят биткоины за ней, и если отправитель сначала потратит эти входы иным способом, транзакция с отложенной датой становится бесполезной.
Locktime vs OP_CHECKLOCKTIMEVERIFY
Locktime ограничивает транзакцию; OP_CHECKLOCKTIMEVERIFY ограничивает выход. Разница важна потому, что только один из них обязывает кого-либо, кроме подписывающего.
Locktime выбирает тот, кто строит транзакцию, поэтому он никого не защищает: отправитель может просто построить другую транзакцию без него. OP_CHECKLOCKTIMEVERIFY, определенный в BIP65 и действующий в сети с блока 388 381 от 14 декабря 2015 года, помещает условие в собственный скрипт выхода. Любой будущий расход этого выхода сам должен нести locktime на указанном моменте или позже, и никакая подпись не может это обойти. Именно это превращает временную блокировку из намерения в правило, и именно поэтому схемы хранилищ, эскроу и наследования пишутся с помощью опкода, а не поля.