يحدد Gap Limit عدد العناوين غير المستخدمة المتتالية التي تتوقف بعدها المحفظة عن البحث. عند الاستعادة من نسخة احتياطية، تعيد المحفظة حساب العناوين وتتحقق من وجود معاملات تخصها. تحتاج إلى قاعدة توقف حتى لا تواصل البحث بلا نهاية في عدد هائل من الاحتمالات. لذلك قد تغيب دفعة تقع بعد هذا الحد عن الشاشة رغم أن صاحبها يملك المفاتيح الصحيحة. تجاوز الحد لا يمحو الأموال ولا يحدّ من عدد المفاتيح الممكن اشتقاقها.
تستخدم آنا محفظة، وهي تطبيق أو جهاز لاستلام بيتكوين وإرسالها. أنشأت مسبقاً عناوين استقبال كثيرة، أي البيانات التي يحتاجها الآخرون لإرسال دفعة إليها، لكنها لم تستخدم بعضها. بعد استعادة المحفظة وجدت أن بعض الدفعات لا تظهر. لنتصور بحثًا حده 20: للعنوان ذي الفهرس 0 سجل معاملات، بينما لا سجل للعناوين ذات الفهارس التالية 1–20، وقد وصلت دفعة إلى الفهرس 21. الفهرس مجرد رقم يحدد موضع العنوان في التسلسل، ويبدأ الترقيم من الصفر. يتوقف الفحص بعد السلسلة الفارغة وقبل بلوغ 21، فتفوته تلك الدفعة. ولو ظهر عنوان مستخدم ضمن السلسلة المفحوصة، لبدأ عدّ الفجوة من جديد. إذن لا يعني الحد أن المحفظة كلها لا يجوز أن تضم أكثر من عشرين عنوانًا. [1] [6]
ماذا نعني بغير مستخدم هنا؟ لا نعني عنوانًا لا توجد عليه أموال الآن. ربما استقبلت آنا دفعة ثم أنفقتها بالكامل. يصبح الرصيد صفرًا، لكن سجل المعاملات يبقى، ويظل العنوان محسوبًا ضمن العناوين المستخدمة. لهذا يعتمد BIP 44 على السجل لا على الرصيد الحالي وحده. اعتبار كل عنوان فارغ عنوانًا لم يُستخدم قط قد يوقف الاستعادة مبكرًا. حتى الدفعة التي أُنفقت منذ زمن تفيد في التحقق من المحفظة المستعادة. [1]
BIP 44 معيار يصف تنظيم الحسابات والعناوين في المحفظة الهرمية، التي ترتب المفاتيح والعناوين كشجرة ذات فروع مختلفة. تضع قاعدة Address gap limit حدًا قدره 20 للبحث في فرع الاستقبال الخارجي، أي تسلسل العناوين المخصص لاستقبال المدفوعات. وعلى البرنامج أن يحذر المستخدم عند إنشاء عنوان يتجاوز هذا الحد. هذه اتفاقية لتنظيم الاستعادة، وليست قاعدة إجماع تقرر قبول الشبكة للمعاملة. قد تستخدم محافظ أخرى إعدادات أو طرق بحث مختلفة. كما أنها ليست توصية بإعادة استعمال عنوان الاستقبال نفسه باستمرار. [1]
قد تعرف المحفظة الأصلية عناوين أُنشئت مسبقًا في مواقع بعيدة من التسلسل. أما البرنامج الجديد الذي يستعيد نسخة من المفاتيح فقط، فقد لا يعرف إلى أين وصلت سابقًا. تنبّه وثائق Electrum صراحة إلى أن العناوين الواقعة بعد Gap Limit قد لا تُكتشف تلقائيًا في الاستعادة المعتادة. وتصف رفع الحد أو اشتقاق مزيد من العناوين حتى الوصول إلى الموضع المستخدم. لكن الإعداد المناسب يتوقف على البرنامج ونوع المحفظة. القيمة الافتراضية 20 الواردة في FAQ تخص Electrum 2.0، ولا تمثل قيمة موحدة لكل المحافظ الحالية. [2]
تخيّل المحفظة شجرة مرتبة. تفصل الحسابات مجموعات الأموال، وداخل الحساب توجد فروع مختلفة للعناوين. وفق BIP 44، يشير change=0 إلى فرع الاستقبال وchange=1 إلى فرع الباقي الخاص بك، أي المبلغ الذي يبقى للمرسل بعد الدفع. يبدأ اكتشاف الحسابات بالحساب 0 وفحص فرعه الخارجي. إن وُجد سجل ينتقل البحث إلى الحساب التالي، ويتوقف عند أول حساب بلا سجل. لذلك ينص المعيار على عدم إنشاء حساب جديد إن لم يكن للسابق سجل. الفجوة في عناوين فرع واحد وتجاوز حساب فارغ مشكلتان مختلفتان. رفع حد واحد لا يحدد وحده أي حسابات أخرى سيبحث فيها البرنامج. [1]
يصف BIP 32 الاشتقاق الحتمي للمفاتيح: البيانات الابتدائية نفسها والمسار نفسه ينتجان المفاتيح نفسها. Derivation Path هو الطريق داخل هذه الشجرة، ويحدد مع نوع السكربت، أي قواعد الإنفاق، العناوين التي تتابعها المحفظة. لذلك فإن Seed Phrase الصحيحة، وهي كلمات النسخة الاحتياطية، ليست سوى جزء من المعلومات المطلوبة. في BIP 39 تدخل passphrase الاختيارية أيضًا في حساب seed، السر الابتدائي الذي تُشتق منه المفاتيح. إنها نص سري إضافي يختلف عن كلمة مرور التطبيق. استخدام passphrase أخرى يؤدي إلى محفظة أخرى، ولا يصلح رفع Gap Limit ذلك. المفتاح الخاص قيمة عددية سرية تستخدمها المحفظة لإنشاء توقيع رقمي يجيز إنفاق الأموال. وللقارئ المتقدم، xpub مفتاح عام موسع لاشتقاق مفاتيح عامة أخرى. يساعد في متابعة العناوين والمدفوعات، لكنه لا يجيز الإنفاق بمفرده. كما أنه لا يستطيع وحده تجاوز خطوة hardened التي تحتاج إلى المفتاح الخاص للأصل. توسيع البحث لا يوفر هذه القدرة المفقودة. [4] [5] [6]
يتيح Bitcoin Core 29.0 الأمر importdescriptors عبر RPC، واجهة البرمجة الخاصة بالعقدة. يصف Descriptor كيفية تكوين شروط الإنفاق والعناوين المراد متابعتها انطلاقًا من المفاتيح. يحدد range نطاق الفهارس المطلوب اشتقاقها، وليس قاعدة توقف عند فجوة فارغة. وعندما يكون descriptor نشطًا، يحدد next_index فهرس العنوان التالي الذي سيُنشأ. أما timestamp فيحدد منذ أي وقت تُبحث المعاملات. القيمة now مخصصة للمخرجات التي نعرف أنها لم تُستخدم قط، ولا تعوض استعادة الدفعات القديمة. تشمل الوثائق أيضًا الكتل حتى ساعتين قبل أقدم timestamp بين الأوصاف المستوردة، وكذلك Mempool الذي يحتفظ محليًا بالمعاملات غير المؤكدة. لذلك قد لا يظهر حتى العنوان المشتق بصورة صحيحة إن لم تُفحص الفترة المطلوبة. [3]
لنعد إلى آنا. إن كان لديها عنوان استقبال معروف أو سجل دفعة من المحفظة الأصلية، تستطيع التحقق من أن الجديدة وجدته فعلًا. ومن المفيد مقارنة الدفعات الواردة التي أُنفقت أيضًا، لا الرصيد النهائي وحده. قد يكشف فحص أطول سجلًا أُغفل، لكنه يستغرق وقتًا ويحتاج إلى استعلامات أكثر. وعند استخدام خادم بعيد، قد يكشف له مزيدًا من العناوين المرتبطة ببعضها. البحث وحده لا ينقل المال ولا يغيّر سلسلة الكتل. إن بقي السجل مختلفًا، يجب التحقق من بيانات النسخة والحساب والمسار ونوع العنوان وتوافر البيانات التاريخية، بدل الاكتفاء برفع الحد. العثور على عنوان واحد لا يثبت اكتمال الاستعادة كلها. [1] [2] [4]
للحصول على صورة أوضح، اقرأ هذا المدخل مع HD Wallet, Derivation Path, Extended Public Key (xpub), Output Descriptor, Change Address, Seed Phrase. تشير إلى هذا المدخل أيضًا HD Wallet, Derivation Path.