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]