Timelock

يمكن لآنا وبافل ترتيب أموالهما المشتركة بحيث يستطيعان إنفاقها معًا في أي وقت، بينما لا تستطيع آنا إنفاقها وحدها إلا بعد مدة انتظار. إذا توقف بافل عن الرد، يوفر الفرع المؤجل مسار استعادة متفقًا عليه مسبقًا. يعني الفرع هنا إحدى طرق الإنفاق المسموحة؛ وقد تكون لكل طريقة شروط مختلفة. لذلك لا يلزم أن يقفل القيد جميع الخيارات في الوقت نفسه. يجب أن تكون القواعد جزءًا من المخرج منذ إنشائه. لا تكفي إضافة ملاحظة «افتح بعد أسبوع» لاحقًا في محفظة عادية. حتى بعد الانتظار، تحتاج آنا إلى المفتاح المناسب والمعلومات اللازمة لإنشاء معاملة صالحة. يساعد Timelock على تنظيم الوصول، لكنه لا يستعيد المفاتيح المفقودة. [3]

يحدد القيد المطلق حدًا ثابتًا يُسجّل في حقل nLockTime بالمعاملة. إذا كانت nLockTime الفعالة لمعاملة مضبوطة على ارتفاع ⁦1 000 000⁩، فأول كتلة يمكن أن تستوفي هذا الشرط هي ⁦1 000 001⁩؛ فالمساواة لا تكفي بعد. أما القيد النسبي فيقيس مدة منذ تأكيد المخرج المراد إنفاقه. إذا أُنشئ مخرج آنا في الكتلة ⁦1 000 000⁩ وكان الفرع المعني يتطلب تأخير 6 كتل، فيمكن لإنفاقه استيفاء هذا الشرط ابتداءً من الكتلة ⁦1 000 006⁩. هذه أرقام توضيحية وليست ارتفاع الشبكة الحالي. تظل شروط التوقيعات والمدخلات الأخرى وأي قيود إضافية سارية. وست كتل ليست ساعة بالضبط؛ فالكتل تأتي بفواصل غير منتظمة. لا يبدأ الانتظار النسبي عند إنشاء المحفظة أو عندما تقرر آنا استخدام المال. [1] [2] [5]

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

تستخدم الشروط الزمنية Median Time Past، واختصارها MTP. بالنسبة إلى الكتلة التي تُفحص، هي وسيط الطوابع الزمنية لآخر 11 كتلة تنتهي بالكتلة السابقة. رتّب أوقاتها وخذ القيمة الوسطى، أي السادسة: هذا هو الوسيط، لا المتوسط الحسابي. يصف BIP113 القاعدة ويستخدم Bitcoin Core الدالة GetMedianTimePast لحسابها. إذن الوقت الحاسم ليس الساعة الحالية في هاتف آنا ولا الطابع الزمني للكتلة المقترحة. لا يلزم أن يكون منتصف الليل في التقويم هو لحظة استيفاء القيد. أما القيود القائمة على الارتفاع فتنتظر الكتل ولا تعدّ الثواني تنازليًا. [4]

يمكن الآن التمييز بين أربعة أسماء في الوثائق. nLockTime حقل في المعاملة كلها يحدد حدًا مطلقًا. وتحمل nSequence في المدخل تأخيرًا نسبيًا وفق BIP68. لكن nLockTime وحدها لا تقفل UTXO، أي مخرجًا لم يُنفق بعد، أمام معاملة أخرى بإعدادات مختلفة. يستطيع صاحب صلاحية الإنفاق إنشاء تلك المعاملة ما لم تمنعه قواعد المخرج. Bitcoin Script هي اللغة التي تُكتب بها قواعد الإنفاق هذه. تفرض التعليمة OP_CHECKLOCKTIMEVERIFY، أو CLTV وفق BIP65، الإعداد المطلق المناسب في الفرع المستخدم. وتفحص OP_CHECKSEQUENCEVERIFY، أي CSV وفق BIP112، الإعداد النسبي، بينما يفرض BIP68 التأخير الفعلي. لا ترسل CLTV ولا CSV الأموال ولا تضيف توقيعًا مفقودًا. وقد يكون فرع آخر مسموح به قابلًا للاستخدام بشروط مختلفة. [1] [2] [3]

الأقسام التالية مرجع تقني. الحقل معلومة محفوظة في المعاملة؛ والمدخل يشير إلى المخرج المراد إنفاقه. لكل مدخل nSequence. وقد تعطل قيمة خاصة تأثير nLockTime، لذلك لا يكفي ملء التاريخ وحده. nLockTime حقل من 32 بت يخزّن أعدادًا غير سالبة؛ تعطل القيمة صفر الشرط الزمني المطلق. إذا استخدمت جميع المدخلات SEQUENCE_FINAL بالقيمة ⁦0xffffffff⁩، يجري تجاهل nLockTime غير المستوفى. يتطلب القيد المطلق الفعال مدخلا واحدا على الأقل بقيمة nSequence مختلفة. التقييم يخص هذه المعاملة المحددة، وليس تجميدا دائما لمدخلاتها. [5] [7]

يمكن للحقل نفسه التعبير عن أمرين مختلفين يفصل بينهما حد عددي. يمثّل Unix timestamp الوقت بعدد الثواني منذ بداية عام 1970 بتوقيت UTC. والكتلة المرشحة هي التي يُراد إدراج المعاملة المفحوصة فيها. قيمة LOCKTIME_THRESHOLD هي ⁦500000000⁩. تعني قيمة nLockTime الأقل ارتفاع كتلة، والمساوية أو الأعلى Unix timestamp. عند تفعيل الفحص المطلق، يجب أن تكون nLockTime أصغر تماما من ارتفاع الكتلة المرشحة أو MTP المعني. المساواة لا تكفي؛ ليس هذا مبلغا أو متوسط ارتفاع أو تاريخ تفعيل للبروتوكول. [5] [8]

المعامل هنا قيمة تُمرر إلى تعليمة؛ وopcode هو تعليمة Script نفسها. تقارن CLTV المتطلب المحفوظ في الفرع بإعداد المعاملة. ويفحص تحقق آخر ما إذا كانت السلسلة قد تقدمت بما يكفي. ليست المسألة مجرد مقارنة تاريخ اليوم بعدد واحد. يتطلب OP_CHECKLOCKTIMEVERIFY معاملا غير سالب، من نوع الارتفاع أو الوقت نفسه الذي تستخدمه nLockTime، وقيمته لا تتجاوز nLockTime. يجب ألا تكون nSequence لمدخل الإنفاق المعني هي ⁦0xffffffff⁩. لا يقرأ opcode الساعة أو ارتفاع السلسلة مباشرة؛ تفحص إعدادات المعاملة بشكل منفصل عند تقييم صلاحيتها الزمنية. وتبقى بقية شروط Script لازمة. [1] [6]

يتضمن عدد nSequence مدة انتظار ومفاتيح تحدد معناه. البت صفر أو واحد في هذا التمثيل؛ وقد يؤدي ضبطه إلى تفعيل خيار. مواضع البتات التالية جزء من التنسيق التقني وليست أعداد تأكيدات. في المعاملات ذات الإصدار 2 أو أعلى، يفعّل BIP68 شرطا نسبيا للمدخلات التي لم يضبط فيها البت 31. تحدد البتات الـ16 الدنيا مدة التأخير؛ يختار البت 22 وحدات من 512 ثانية، وإلا فالقياس بالكتل. يبدأ تأخير الكتل من ارتفاع تأكيد المخرج المنفق. أما التأخير الزمني فمن MTP الكتلة السابقة لتأكيده إلى MTP الكتلة السابقة للكتلة المرشحة. ليس زمنا منذ إنشاء المعاملة في المحفظة. [2] [5]

تجري CSV فحصًا مشابهًا للانتظار النسبي. يختار القناع بتات nSequence المعنية، وdisable flag مفتاح تعطيل. Lightning Network شبكة من قنوات الدفع، يحدّث المشاركون فيها التوزيع المتفق عليه لأموال مقفلة معًا. تتيح المهلة للطرف الآخر وقتًا للرد إذا نشر أحدهم حالة قديمة سبق إبطالها. تسجّل commitment transaction توزيع الأموال؛ ويتيح مفتاح الإبطال للطرف الآخر إنفاق المخرج المعني من النسخة المُبطلة عبر فرع العقوبة. يتطلب OP_CHECKSEQUENCEVERIFY ذو المعامل الفعال غير السالب إصدارا لا يقل عن 2، وعدم ضبط disable flag للمدخل، وتطابق نوع التأخير، وقيمة nSequence كافية بعد تطبيق القناع. يفرض BIP68 العمر الفعلي بشكل منفصل. يتيح CSV فرع استرداد مؤجلا. في مخرج Lightning المسمى to_local، يقيد to_self_delay مالك commitment transaction؛ ويمكن للطرف الآخر ذي مفتاح الإبطال الصحيح استخدام فرع العقوبة دون هذا التأخير. [3] [9]

قد يكون لعددين متشابهين جدًا أثران مختلفان. القيم التالية التي تبدأ بـ0x مكتوبة بالنظام الست عشري. تشير NOP إلى تعليمة لا تضيف هنا قيدًا زمنيًا. ويهم أيضًا ما إذا كان المفتاح في مدخل المعاملة أو في القيمة الممررة إلى CSV. البت 31 هو SEQUENCE_LOCKTIME_DISABLE_FLAG ويعطل تفسير BIP68 النسبي لهذا المدخل وحده. تحتوي القيمة ⁦0xfffffffe⁩ عليه لكنها ليست SEQUENCE_FINAL، لذلك تسمح بفعالية nLockTime وCLTV. القيمة ⁦0xffffffff⁩ هي final. يتصرف معامل CSV غير السالب ذو disable flag المضبوط كتعليمة NOP؛ لكن ضبط العلم في المدخل لا يستوفي متطلب CSV الفعال. يجب عدم الخلط بين الحالتين. [3] [7]

RPC أمر للعمل مع عقدتك، أي البرنامج الذي يتحقق من كتل البيتكوين ومعاملاته. يحوّل فك الترميز البيانات المحفوظة إلى قائمة مقروءة فقط؛ ثم يفحص أمر الاختبار ما إذا كانت معاملة موقعة محددة ستنجح. Mempool قائمة العقدة المحلية للمعاملات المنتظرة. يعرض RPC المسمى decoderawtransaction في ⁦Core 31⁩ الحقول version وlocktime وsequence لكل مدخل. لتحليل CLTV/CSV، افحص Script المستخدم فعليا والمخرج المنفق؛ فك الترميز وحده ليس دليلا على الصلاحية. يختبر RPC المسمى testmempoolaccept مرشحا موقّعا وفق السلسلة الحالية وقواعد صلاحية البيتكوين والقواعد المحلية للعقدة لقبول المعاملات، دون قبوله في mempool ودون بثه. افحص allowed وسبب الرفض؛ النجاح ليس وعدا بتأكيد مستقبلي. [10] [11] [12]