Peter Todd

تخيّل أنك تحتاج إلى إثبات أن نسخة محددة من عقد كانت موجودة قبل بدء نزاع. يعالج OpenTimestamps، وهو مشروع مرتبط بـ Peter Todd، هذا النوع من الاحتياجات. قدّم إعلانه التاريخي في 2016 نسخة اختبار عامة، وشكر Riccardo Casatta على التطوير والاختبار. يسجل ذلك التعاون في حينه، ولا يعني أن المشروع بقي تجريبيًا إلى اليوم. وعمل Todd أيضًا على شروط الإنفاق المستقبلية وعلى المدفوعات التي تنتظر التأكيد. لنبدأ بهذين المجالين قبل العودة إلى المستندات. [1]

قدّم ⁦BIP 65⁩ الذي كتبه Todd التعليمة OP_CHECKLOCKTIMEVERIFY، واختصارها CLTV. تتيح اشتراط بلوغ ارتفاع كتلة أو حد زمني لاستخدام مسار إنفاق معين. تصوّر مسارًا احتياطيًا إلى مدخرات مشتركة لا يستطيع المستفيد استخدامه إلا لاحقًا. يمنع الشرط الزمني استخدام هذا المسار حتى ذلك الحين. وعند تحققه لا تُرسل العملات وحدها؛ فلا بد من إنشاء معاملة صالحة واستيفاء بقية المتطلبات، مثل تقديم توقيع. وإذا وُجد مسار إنفاق آخر فله شروطه الخاصة، ولا يمتد القفل بالضرورة إلى كل طرق استخدام الأموال. [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]

قد لا يكون الختم الزمني الجديد مرتبطًا بعد بكتلة Bitcoin مؤكدة. لذلك لا يثبت وجود ملف .ots وحده انتهاء العملية. يميز عميل OpenTimestamps بين دليل ينتظر الاكتمال وآخر كامل يتضمن المسار حتى الكتلة. يستطيع الأمر ots upgrade جلب المعلومات المكملة وحفظها عندما تصبح متاحة، لكنه لا يفرض تعدين كتلة. بعد ذلك يجب التحقق من الدليل بالرجوع إلى البيانات الأصلية وسلسلة Bitcoin. وكما في الدفعة المنتظرة، المهم هو الحالة الفعلية، لا مجرد ظهور ملف أو إشعار. [5]