Extended Public Key (xpub)

تحتفظ آنا بمفاتيح محفظتها على جهاز مادي، وتريد التأكد من هاتفها أن أحد العملاء دفع لها. تنقل إلى الهاتف الإعداد العام للحساب المختار، وفيه xpub من دون أي مفتاح خاص. يصبح الهاتف بذلك Watch-only Wallet: يتابع العناوين المعنية، ويجهّز عنوانًا جديدًا، ويمكنه إعداد معاملة غير موقعة. أما إرسال الأموال فيظل بحاجة إلى توقيع الجهاز الذي يحتفظ بالمفاتيح السرية. وبالطريقة نفسها، يستطيع متجر إلكتروني إنشاء عنوان استقبال مختلف لكل طلب من دون تخزين مفاتيح الإنفاق على الخادم. يقلل هذا الفصل عواقب اختراق الخادم، لكنه لا يعالج كل شيء: قد يعرض المهاجم عنوانه الشخصي للعميل كي يتلقى دفعة جديدة. [1] [5]

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

تنشئ محفظة BIP32 شجرة مفاتيح من أصل واحد. والمقصود بالفرع هنا مجموعة مفاتيح مشتقة، لا جزء من الشبكة أو سلسلة البلوكات. يمكن الانطلاق من xpub إلى أسفل الشجرة عبر خطوات non-hardened فقط. أما النوع الآخر، Hardened Derivation، فيحتاج إلى بيانات خاصة ويشكّل حدًا لا يعبره xpub وحده. يضع التنظيم المعتاد وفق BIP44 هذا الحد قبل كل حساب. لذلك لا يكشف تصدير xpub حساب واحد بقية الحسابات بمفرده. ويهم أيضًا مستوى التصدير: xpub فرع الاستقبال وحده يتيح رؤية أضيق من xpub الحساب بأكمله، الذي يشمل عادةً عناوين الباقي أيضًا. [1] [6]

يمكن للمفاتيح العامة نفسها أن تنتج عناوين Bitcoin مختلفة بحسب القواعد المستخدمة. مخرج المعاملة سجلّ لمبلغ والشروط التي تسمح بإنفاقه لاحقًا. لذلك يحتاج التطبيق إلى معرفة نوع المخرجات، مثل Native SegWit أو Taproot، والفرع والأرقام التي سيشتقها. قد توحي بادئتا ypub وzpub وفق SLIP-0132 بنوع العناوين، لكنهما لا تصفان المحفظة كاملة. Output Descriptor أدق: إنه وصف نصي للمفاتيح وقواعد إنشاء العناوين وشروط الإنفاق. وقد يتضمن أصل المفتاح ومسار الاشتقاق ومجموع تحقق لكشف أخطاء الكتابة. يؤكد مجموع التحقق سلامة النص، لا موثوقية مرسله. وليست كل أوصاف descriptor عامة فقط؛ فقد يحتوي الوصف على مفتاح خاص، لذلك يجب التمييز بين الحالتين قبل مشاركته. [2] [3] [4]

تحقق أولًا من الشبكة والحساب المختار ونوع العناوين ومسار الاشتقاق، أي التعليمات التي تحدد موضع المفتاح في الشجرة. قارن عدة عناوين استقبال بالمحفظة الأصلية. وفي المحفظة المادية استخدم شاشة الجهاز الموثوقة وفق تعليمات الشركة المصنّعة. تطابق اسم الحساب وحده لا يكفي. ظهور رصيد صفري بعد الاستيراد لا يعني بالضرورة ضياع المال: ربما تتابع حسابًا آخر أو نوع عناوين مختلفًا، أو تفحص نطاقًا ضيقًا جدًا من أرقام العناوين. لا تدخل كلمات الاستعادة في موقع عشوائي لمعالجة ذلك. إن كنت تريد المتابعة فقط، فابحث عن تصدير الإعداد العام، لا Seed Phrase ولا xprv، وهو المفتاح الخاص الموسّع. [4] [5]

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

قد تتطلب محفظة Multisig توقيعين من ثلاثة مفاتيح مثلًا. لكن معرفة أنك تستطيع استعادة مفتاحين لا تكفي وحدها. لإعادة بناء شروط الإنفاق الصحيحة، تحتاج كذلك إلى البيانات العامة لبقية المفاتيح المشاركة، وترتيبها، وعدد التوقيعات المطلوبة، وقواعد الاشتقاق. لذلك تُحفظ إعدادات المحفظة إلى جانب النسخ السرية، مثل descriptor عام يضم كل مفاتيح xpub المطلوبة. لا يمنح هذا الإعداد حق الإنفاق، لكنه قد يكون ضروريًا للاستعادة. ويساعد master fingerprint، معرّف من ثمانية محارف ست عشرية للمفتاح الأصلي، على مطابقة الإعداد. لكنه ليس هوية فريدة مضمونة؛ فقد يكون لمفتاحين مختلفين fingerprint متطابق. [4] [5]

المفتاح العام بيانات تسمح بالتحقق من توقيعات أنشأها المفتاح الخاص المقابل. يضيف BIP32 إليه chain code، وهي قيمة من 32 بايت تُستخدم لاشتقاق مفاتيح أخرى. يشكّل الاثنان المفتاح العام الموسّع. ويحمل تنسيقه القابل للنقل معلومات أخرى عن الإصدار والموضع في الشجرة: العمق، وfingerprint الأب المباشر، ورقم الابن. وهذا ليس المسار الكامل من أول مفتاح في المحفظة. إذن xpub ليس عنوان استقبال منفردًا، ولا كلمة مرور لحساب، ولا يتضمن قائمة معاملات. تبحث محفظة المتابعة عن تلك المعاملات في السلسلة للعناوين المعنية. [1]

تأخذ دالة CKDpub وفق BIP32 المفتاح العام للأب وchain code ورقم الابن. وتستخدم HMAC-SHA512، وهي عملية حسابية تشفيرية بهذه المدخلات، لإعداد بيانات المفتاح العام التالي وchain code جديد. تتراوح الأرقام القابلة للاشتقاق العام بين ⁦0⁩ و⁦2³¹−1⁩. وتبدأ أرقام hardened من ⁦2³¹⁩، وتُكتب عادةً في المسارات بعلامة اقتباس مفردة أو حرف h؛ وهنا لا تكفي CKDpub اعتمادًا على xpub وحده. ينتج عن تكرار الخطوات المسموحة أحفاد للمفتاح المصدّر، لا إخوته أو أسلافه. وإذا ظهرت إحدى النتائج النادرة غير الصالحة المذكورة في BIP32، ينتقل التنفيذ إلى الفهرس التالي. لا يحتاج المستخدم العادي إلى إجراء هذه الحسابات؛ المهم نقل الإعداد الصحيح. [1]

قبل الترميز النصي، يشغل سجل BIP32 القياسي 78 بايت: للإصدار 4، وللعمق 1، وfingerprint الأب 4، ورقم الابن 4، وchain code عدد 32، ولبيانات المفتاح 33 بايت. يضيف Base58Check مجموع تحقق ويحوّل السجل إلى 111 محرفًا. تبدأ النسخة العامة للشبكة الرئيسية بـ xpub، ونسخة شبكة الاختبار بـ tpub؛ وتقابلهما النسختان الخاصتان xprv وtprv. لا تعني tpub تقنية Taproot. تأتي البادئة من بايتات الإصدار، ولا تصف جميع قواعد العناوين. عند الاستيراد، يجب على البرنامج التحقق أيضًا من صلاحية المفتاح العام نفسه، لا من الحروف الأولى أو الطول فقط. [1] [3]