BIP 110، وعنوانه Reduced Data Temporary Softfork، مقترح مغلق لتشديد قواعد قبول الكتل مؤقتاً. والعقدة حاسوب يتحقق بنفسه من السجل والمدفوعات. أراد المقترح تصعيب بعض طرق تخزين البيانات وتعزيز دور الشبكة النقدي من وجهة نظر مؤيديه. لكن ذلك لم يجعله تلقائياً قاعدة تتبعها شبكة بيتكوين كلها.
تخيّل مشغّلين لعقدتين يستقبلان الكتلة نفسها. يقبلها أحدهما وفق القواعد القائمة، ويرفضها الآخر بسبب قيد جديد. هذا هو المستوى الذي استهدفه BIP 110: تغيير صلاحية الكتل، وليس مجرد قرار تمرير معاملة أو الاحتفاظ بها في mempool، أي قائمة الانتظار المحلية للمدفوعات غير المؤكدة. عند المراجعة في 2026-10-23 كانت النسخة 1.0.1 من المواصفة تحمل الحالة Closed، أي مغلق. رقم BIP أو نشر برنامج ليس شهادة على تبنّي الشبكة له. يحتفظ سجل المقترحات بالوثيقة وتاريخها، ولا يبدّل قواعد العقد عن بُعد. [1] [2]
لكل مخرج جديد scriptPubKey، وهو برنامج نصي يحدد شروط إنفاقه لاحقاً. سمح المقترح بحد أقصى قدره 34 بايت، أو 83 بايت إذا بدأ بـ OP_RETURN، وهي تعليمة تجعل المخرج غير قابل للإنفاق بصورة قابلة للإثبات. ويُحتسب البرنامج النصي كله. أما حد 256 بايت المنفصل فيخص بيانات كل OP_PUSHDATA* وعناصر الوسائط في witness، أي المعلومات المصاحبة للتحقق من الإنفاق. ويُستثنى إدراج redeemScript، برنامج الشروط الذي يُكشف عنه، في scriptSig وفق BIP16. أما witness scripts وTapleaf scripts نفسها فليست تلك الوسائط، لكن تعليماتها لإدراج البيانات تظل خاضعة للقيد. إذن تُقاس أجزاء محددة، لا طول المعاملة بالكامل ولا witness بأكمله. [1]
طال المقترح أيضاً Taproot، وهي طريقة للتعبير عن شروط الإنفاق. منع إنفاق إصدارات witness أو Tapleaf غير المعرّفة، لكنه لم يمنع إنشاء تلك المخرجات. كما منع annex، وهو حقل إضافي، وcontrol block الذي يتجاوز 257 بايت، أي دليل الانتماء الطويل إلى البنية المثبتة مسبقاً. ولا يجوز أن يحتوي Tapscript على OP_SUCCESS* حتى داخل شيفرة لا تُنفّذ، أو أن ينفّذ OP_IF أو OP_NOTIF مهما كانت نتيجة الشرط. وللمقارنة التقنية تشمل الصيغ المعرّفة P2WPKH وP2WSH وP2TR مع إصدار Tapleaf بقيمة 0xc0 وP2A مع البرنامج 0x4e73، والأخير فقط مع مكدس witness فارغ. هذه أسماء دقيقة للصيغ، وليست حقولاً يجب أن يملأها المستخدم العادي في محفظته. [1]
UTXO مخرج لم يُنفق بعد: مبلغ محدد مع شروط استخدامه. يستثني المقترح المدخلات التي تنفق UTXO مؤكدة قبل التفعيل من القواعد الجديدة. لكنه لا يمنح المخرجات الجديدة في المعاملة نفسها حرية تجاوز القيود. والتوقيع المجهز مسبقاً لا يحمي مخرجاً لا يُنشأ إلا خلال الفترة النشطة. تقرّ المواصفة، في بعض تراكيب Taproot الموقّعة مسبقاً، باحتمال تجميد أموال أو فقدانها إذا أبطلت القيود مسارات الإنفاق المقصودة ولم يبق بديل قابل للاستخدام. وهذا يثير أيضاً أثرها على Miniscript، أداة تركيب شروط الإنفاق، وBitVM، تراكيب للتحقق من الحسابات. لذلك لا يصح الوعد بأن التأثير سيقتصر على المحتوى غير النقدي. [1] [3]
يمكن للمعدّن وضع إشارة دعم في الكتلة: هنا البت 4، بعتبة 1109 من أصل 2016 كتلة، أي نحو 55 بالمئة. لكن المقترح لم يتوقف عند الإشارة الطوعية. إذا لم تتحقق العتبة مبكراً، ألزم بالإشارة عند الارتفاعات 961632–963647، ثم LOCKED_IN بدءاً من 963648 وACTIVE بدءاً من 965664، بشرط وصول السلسلة المعنية إلى تلك الارتفاعات. والارتفاع هو موضع الكتلة في السلسلة. تعني LOCKED_IN تثبيت الانتقال، بينما تعني ACTIVE تطبيق قيود البيانات فعلياً. سيرفض البرنامج الكتل التي لا تحمل الإشارة خلال الفترة الإلزامية نفسها، لذا قد تفترق العقد قبل بدء قيود البيانات. وكان مقرراً استمرار هذه القيود 52416 كتلة من التفعيل الفعلي، ثم الانتقال إلى EXPIRED والتوقف عن تطبيقها؛ وليس ذلك سنة تقويمية محسوبة بدقة. [1] [4]
أراد المؤيدون تخفيض تكلفة تشغيل العقد والضغط على مجموعة UTXO والمحتوى غير المرغوب فيه، مع إعطاء الأولوية للمدفوعات. هذه دوافع، وليست دليلاً على النتائج. أشار منتقدون إلى أثر القيود على البرامج النصية المفيدة والتطوير المستقبلي وخطر انقسام الشبكة. ويمكن أيضاً تقسيم البيانات إلى أجزاء أصغر: عرض Peter Todd في النقاش الأولي معاملة تضم كامل نص المقترح آنذاك بهذه الطريقة. وحتى المواصفة لا تعد بإزالة إخفاء المعلومات داخل بيانات أخرى، المعروف بالستيغانوغرافيا، إزالة كاملة. جعل التخزين أغلى ومنعه تماماً نتيجتان مختلفتان. وبالمثل، لا يثبت القلق من المسؤولية القانونية عن المحتوى وحده وجود واجب قانوني محدد. [1] [3]
يصف سجل PR 2247 انقساماً في 2026-08-08 عند الارتفاع 961632. احتوت السلسلة الرئيسية على كتلة بلا الإشارة المطلوبة، بينما عدّن OCEAN بديلاً يحملها. وفي 2026-08-09 أفاد Murch بأن فرع الأقلية أنتج كتلتين فقط (2) ثم توقف، بينما تقدمت السلسلة الرئيسية بأكثر من 100 كتلة. ينبغي قراءة هذا التقرير مع تاريخه وصاحبه: فهو ليس إعادة تحقق مستقلة من blockchain أُجريت لهذا المقال، ولا وصفاً لحالة فرع الأقلية اليوم. ويوضح أيضاً أن الانقسام بسبب الإشارة لا يعني بلوغ ACTIVE أو بدء تطبيق قيود البيانات ذاتها. [5] [6]
مرّت الوثيقة بحالة Complete، أي مواصفة مكتملة، وانتهت إلى Closed. دُمج PR 2245 لإغلاقها في 2026-08-10، بينما يحمل سجل تغييرات المواصفة تاريخ 2026-08-09. التاريخان يخصان سجلين مختلفين، لا تفعيلًا آخر. يوثّق إصدار البرنامج v0.4.1 حالة EXPIRED وحقل vbrequired الذي يحدد بت الإشارة الإلزامي في قالب الكتلة. وجود هذا البرنامج لا يعني تبنّيه في Bitcoin Core. وتتوفر كذلك test vectors، أي معاملات نموذجية بنتائج متوقعة، واختبارات وظيفية. لا يشغّل هذا المقال تلك الاختبارات ولا يتحقق من سلسلة الأقلية الحالية. الغرض فهم المقترح ومساره الموثّق، لا عرض وثيقة تاريخية على أنها قواعد الشبكة المشتركة اليوم. [7] [1] [4]
بايت إضافي قد يغيّر النتيجة
تخيّل فحص مخرج جديد وفق القواعد النشطة افتراضاً. يجتاز scriptPubKey العادي بطول 34 بايت اختبار الطول هذا، لكنه لا يجتازه عند 35 بايت. ويمكن أن يبلغ البرنامج النصي الذي يبدأ بـ OP_RETURN مقدار 83 بايت، بينما تتجاوز 84 بايت الحد. نقيس دائماً برنامج المخرج كله، لا النص المدرج وحده. واجتياز الاختبار لا يثبت صلاحية المعاملة كاملة، كما أن إنفاق UTXO قديمة لا يعفي مخرجاً جديداً.
للحصول على صورة أوضح، اقرأ هذا المدخل مع Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. تشير إلى هذا المدخل أيضًا OP_RETURN.
01هل تعني Closed أنه لم يعد مسموحاً بتشغيل البرنامج؟+
Closed حالة وثيقة وليست حظراً على استخدام برنامج. تتبع العقد قواعد برامجها. لكن اختيار قواعد مختلفة قد يقود إلى فرع آخر من السلسلة؛ وإغلاق السجل لا يلغي هذا الاختلاف.
02هل بدأت قيود البيانات خلال الإشارة الإلزامية؟+
لا. الإشارة الإلزامية تسبق LOCKED_IN وACTIVE. يمكن للبرنامج رفض كتلة بلا الإشارة المطلوبة قبل بدء قواعد البيانات. لذلك لا يكفي تاريخ التقويم وحده؛ بل تهم حالة السلسلة المعنية وارتفاعها.