Peter Todd

Представьте, что нужно доказать: определённая версия договора существовала до начала спора. Именно такую задачу решает OpenTimestamps, проект, связанный с Peter Todd. Его историческое объявление 2016 года представляло публичную тестовую версию и благодарило Riccardo Casatta за разработку и тестирование. Это свидетельство тогдашнего сотрудничества, а не утверждение, что проект до сих пор экспериментальный. Todd также работал над условиями будущего расходования средств и платежами, ожидающими подтверждения. Сначала рассмотрим эти два направления. [1]

BIP 65, написанный Todd, ввёл OP_CHECKLOCKTIMEVERIFY, сокращённо CLTV. Эта инструкция позволяет поставить определённый способ расходования bitcoin в зависимость от высоты блока или временной границы. Представьте резервный доступ к общим сбережениям, которым получатель сможет воспользоваться только позднее. До этого момента временное условие закрывает такой путь. Когда оно выполнено, монеты не отправляются сами: нужна действительная транзакция и выполнение остальных требований, например подпись. Если существует другой путь расходования, он подчиняется собственным условиям; блокировка не обязательно охватывает все способы использования средств. [2]

Временная блокировка не просто следует часам в кошельке. BIP 65 проверяет соотношение между скриптом, то есть инструкциями с условиями расходования, и полем nLockTime транзакции. Оба должны использовать одинаковый тип границы: высоту блока или время. Поле nSequence входа также не должно иметь окончательного значения, которое исключило бы проверку. Это абсолютная граница, а не относительный возраст выхода с момента подтверждения. Выполнение условий не обещает включения в конкретную секунду: майнеру ещё нужно добавить транзакцию в действительный блок. [2]

Разосланная транзакция может остаться в mempool — наборе неподтверждённых транзакций конкретного узла. Если комиссии выросли, отправитель может предложить больше через заменяющую транзакцию. David A. Harding и Peter Todd описали первоначальные правила замены opt-in в BIP 125. Возможность замены обозначалась через nSequence либо наследовалась от неподтверждённой транзакции-предка, выход которой расходует платёж. Таким образом, учитывались и зависимости между транзакциями. Повышенная комиссия может помочь, но не гарантирует немедленного подтверждения. [3]

Замена в mempool меняет кандидата на подтверждение, которого хранит узел. Она не переписывает подтверждённую историю. Кроме того, BIP 125 описывает историческую политику opt-in, а не неизменное правило всех программ. Более поздние версии Bitcoin Core сделали замену без такого сигнала стандартным поведением, сохранив условия принятия замены. Для получателя вывод прост: отсутствие сигнала не доказывает окончательности платежа. Сообщение «отправлено» в кошельке тоже не означает, что транзакция включена в подтверждённый блок. [3] [6]

Вернёмся к договору. OpenTimestamps создаёт проверяемое доказательство того, что определённые данные существовали до засвидетельствованной временной границы. Оно использует hash, короткий цифровой отпечаток содержимого, и доказательство, закреплённое в Bitcoin. Изменённый документ при проверке даст другой отпечаток. Однако метка сама по себе не подтверждает авторство, правдивость содержания или точный момент создания. Ложный текст тоже можно своевременно снабдить меткой. Доказательство ограничивает самый поздний возможный момент появления данных, но не говорит, сколько времени они существовали до этого. [1] [4]

Клиент OpenTimestamps не отправляет документ календарным серверам. Он обрабатывает отпечаток вместе со случайным значением, чтобы сервер не мог определить содержание по полученным данным. Календарь здесь — сервис, который собирает запросы и помогает закреплять их в Bitcoin. Защита содержания не означает полной анонимности: близость по времени или совместно созданные доказательства могут выявить связи между запросами. Файл .ots не является резервной копией документа. Храните его вместе с точным оригиналом; отпечаток не восстановит потерянный текст, а изменённая копия содержит уже другие данные. [5]

Новая временная метка может ещё не быть связана с подтверждённым блоком. Поэтому само наличие файла .ots не означает завершения процесса. Клиент OpenTimestamps различает ожидающее доказательство и полное, содержащее путь до блока. Команда ots upgrade может получить и сохранить дополнение, когда оно доступно, но не заставляет майнеров добыть блок. Затем доказательство нужно проверить по исходным данным и цепочке Bitcoin. Как и с ожидающим платежом, важен фактический статус, а не просто появление файла или уведомления. [5]