CLTV

تصمم آنا طريقة لحفظ الأموال تتطلب موافقتها وموافقة بيتر معًا على الدفعات المعتادة. وتريد، تحسبًا لغياب طويل، مسارًا احتياطيًا لا يُستخدم إلا بعد حدّ تختاره. تتيح CLTV وضع هذا الشرط الزمني في السكربت، أي قواعد إنفاق العملات المستلمة سابقًا. أما حقل nLockTime وحده فيؤخر معاملة بعينها فقط. تمنع CLTV تجاوز شرط هذا المسار بمعاملة جديدة ذات حدّ أقل. ومع ذلك قد تكون للفروع الأخرى قواعد مختلفة. [1] [5]

لا تتعرف CLTV على المالك ولا ترسل المال. إذا كان مسار الاسترداد يتطلب توقيع آنا، فعليها تقديمه حتى بعد استيفاء الشرط الزمني. المفتاح الخاص قيمة عددية سرية تُستخدم لإنشاء هذا التوقيع. مرور الوقت لا يستعيد مفتاحًا خاصًا مفقودًا. ولا تنتقل العملات تلقائيًا إلى عنوان آخر: يجب أن يُعدّ شخص معاملة صالحة ويوقّعها ويبثها. وإذا سمح فرع آخر بإنفاق أبكر، فإن القفل في فرع الاسترداد لا يقيّد ذلك البديل بمفرده. [1]

تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. تناسب CLTV شرطًا مربوطًا بنقطة محددة سلفًا، لا مطلب الانتظار عددًا معينًا من الكتل بعد استلام هذه العملات. تتولى CSV مع BIP 68، قواعد القفل النسبي، الحالة الثانية. عندها يعتمد الانتظار على تأكيد مخرج معين: مبلغ مستلم سابقًا مع شروط إنفاقه. ولا يضمن أي النهجين تاريخًا دقيقًا في التقويم. فوتيرة التعدين متغيرة، وقد تغير إعادة تنظيم السلسلة سجل التأكيدات. عند إعادة التنظيم، تعتمد الشبكة فرعًا صالحًا آخر من السلسلة، فيحل محل جزء من سجل الكتل السابق. [1] [7] [8] [9]

تميّز CLTV بين نوعين من القيم. ما دون 500000000 يعني ارتفاع الكتلة، أي موضعها في السلسلة. ومن هذا الحدّ فما فوق، تعني القيمة طابعًا زمنيًا، أي وقتًا مكتوبًا بالأرقام. يجب أن يستخدم شرط السكربت وnLockTime في معاملة الإنفاق النوع نفسه. لا يكفي مقارنة حجم العددين: فموضع كتلة ووقت ما ليسا الشيء نفسه. [1] [3] [5]

تتحقق Full Node، وهي عقدة تفحص القواعد بنفسها، من الحدّ غير السالب في السكربت بمقارنته مع nLockTime المطلق للمعاملة. يجب ألا يتجاوز الحدّ nLockTime، والتساوي مقبول في هذا الفحص. لكن يجب أيضًا اجتياز قواعد إدراج المعاملة في كتلة محددة. لا تقرأ CLTV ساعة حاسوبك ولا توقف برنامجًا حتى الصباح. فشل الفحص يعني أن محاولة استخدام مسار الإنفاق هذا غير صالحة. [1] [3] [4]

يحدد مدخل المعاملة العملات المستلمة سابقًا التي يجري إنفاقها. ومن حقوله nSequence. في المدخل الذي تفحصه CLTV، لا يجوز أن تكون قيمته 0xffffffff، وهي القيمة الخاصة للتسلسل النهائي. لو استخدمتها جميع المدخلات، لأمكن تعطيل nLockTime. تمنع CLTV ذلك باشتراط قيمة غير نهائية لهذا المدخل. لكن هذا لا يحدد تلقائيًا مدة انتظار نسبية بعينها؛ فهذه تتبع قواعد أخرى. [1] [3] [4]

لنأخذ معاملة افتراضية لها nLockTime يساوي 900000 ومدخل غير نهائي. من ناحية هذا الشرط الزمني، فإن أول كتلة ممكنة هي 900001. إذ يتطلب الإدراج أن يكون nLockTime أصغر تمامًا من ارتفاع الكتلة المرشحة. لذلك لا تكفي الكتلة 900000، حتى لو سمحت مقارنة CLTV الداخلية بالتساوي. «النهائية» هنا تعني أهلية الإدراج، لا استحالة عكس الدفعة. وقد تؤخر الرسوم والشروط الأخرى واختيار المعدّن التأكيد أكثر. [4]

بالنسبة للطابع الزمني، تستخدم BIP 113 قيمة Median Time Past للكتلة السابقة: القيمة الوسطى بعد ترتيب أوقات آخر ما يصل إلى 11 كتلة. ليست هذه ساعة يدك ولا وقت الكتلة التي يجري تعدينها الآن. يجب أن يكون nLockTime الزمني أصغر تمامًا من هذه القيمة. لذلك لا يمكن الوعد بإمكان الإنفاق عند الظهر المحلي بالضبط. للشرط معنى تستطيع الشبكة التحقق منه، لكنه ليس جدولًا دقيقًا للدفعات. [2] [4]

أثناء التقييم، يستخدم السكربت مكدسًا، أي مساحة عمل تتراكم فيها البيانات. تفحص CLTV معامل الوقت لكنها لا تزيله. لذا تتبع OP_CHECKLOCKTIMEVERIFY في مخطط بسيط تعليمة OP_DROP لإزالته؛ ثم يُضاف المفتاح العام وتتحقق OP_CHECKSIG من التوقيع. يُستخدم المفتاح العام للتحقق من التوقيعات، ولا يلزم إبقاؤه سرياً. يوضح هذا أدوار التعليمات، وليس وصفة جاهزة لقفل الأموال. يجب أيضًا أن تكون نسخة السكربت والبيانات الأولية وجميع مسارات الإنفاق الأخرى صحيحة. [1] [3]

قدمت BIP 65 تعليمة CLTV عبر soft fork، أي تشديد للقواعد استبدل OP_NOP2 السابقة. فهي ليست مجرد اقتراح لميزة مستقبلية. ومع ذلك ينبغي فحص التصميم كله: نوع الحدّ وnLockTime وnSequence والتوقيعات والفروع البديلة. توثّق Bitcoin Core v29.0 والمواصفات المرتبطة التفاصيل التقنية. أما للمستخدم، فالسؤال الأهم هو من يستطيع الإنفاق قبل الحدّ وبعده، وهل يفهم خيارات الاسترداد. [1] [3] [6] [10]