HD Wallet

تفتح أليس شاشة الاستلام، فتعرض المحفظة عنوانًا. يصل إليه 10 000 ساتوشي، وهي الوحدات الصغيرة للبيتكوين. للدفعة التالية، يقترح التطبيق عنوانًا آخر يصل إليه 20 000 ساتوشي. إذا كان هذان هما المبلغان الوحيدان اللذان تلقتهما ولم تنفقهما، فستعرض المحفظة مجموعًا قدره 30 000 ساتوشي. لم يُنشئ العنوان الجديد حسابًا مستقلًا، ولم تنتقل الأموال السابقة تلقائيًا. يدير التطبيق مفاتيح الدفعتين. تجعل HD Wallet ذلك عمليًا. تعني HD عبارة Hierarchical Deterministic: هرمية لأن المفاتيح تشكل بنية متفرعة، وحتمية لأن البذرة والمسار نفسيهما ينتجان المفاتيح نفسها، حتى عند الاستعادة. والمسار سلسلة أرقام تحدد للبرنامج أي فرع وأي مفتاح يحسب. لا تحتاج أليس عادةً إلى التعامل معه عند الاستلام، لكن الاستعادة تتطلب استخدام المسارات الصحيحة. لذا يمكن لنسخة واحدة من السر الأصلي أن تشمل العناوين المستقبلية أيضًا، مع ضرورة حفظ إعدادات المحفظة. تساعد العناوين الجديدة على تجنب إعادة استخدام العنوان، لكنها لا تضمن إخفاء الهوية وحدها. [1] [12]

يسمح المفتاح العام الموسع، الذي يُسمى عادةً xpub، بحساب المفاتيح العامة لجزء من هذه البنية. ولا يتضمن المفاتيح الخاصة اللازمة لتوقيع دفعة. لذلك لا يكفي xpub وحده لإنفاق الأموال؛ ولإنشاء عناوين محددة، يحتاج التطبيق أيضًا إلى معرفة تنسيقها. تستطيع محفظة watch-only ذات xpub مناسب إنشاء العناوين ومتابعة الدفعات دون مفاتيح توقيع. لكن تسرب xpub قد يربط عناوين الفرع السابقة والمستقبلية وأرصدتها ومعاملاتها. شارك الفرع المطلوب فقط. حتى xpub الصحيح لا يمنع حاسوبًا مخترقًا من عرض عنوان شخص آخر. تحقّق من عنوان الاستلام على جهاز توقيع موثوق يعرف إعدادات هذه المحفظة. [1] [12] [14]

يمكن للمتجر إنشاء عنوان مختلف لكل طلب. يحتاج الموقع إلى معرفة العناوين، لكن ينبغي ألا يملك مفاتيح إنفاق الإيرادات. يسمح BIP32 بفصل فرع الاستلام هذا عن بقية المحفظة. كتب Pieter Wuille المقترح، وتاريخ تخصيصه هو 11 فبراير 2012. إنه معيار للمحافظ، لا قاعدة إجماع. أما كلمات النسخ الاحتياطي BIP39 وأنواع السكربت وإجراءات الاستعادة الكاملة فتتناولها طبقات أخرى. [1] [11] [12]

يضيف BIP32 إلى المفتاح chain code بطول 256 بت، أي 32 بايتًا للاشتقاق اللاحق. تتكون الصيغة الخاصة من القيمة العددية k على منحنى secp256k1 ومن chain code c؛ وتستخدم الصيغة العامة K = point(k) مع c نفسه. يُنشأ المفتاح الرئيسي بواسطة HMAC-SHA512، مع النص الدقيق «Bitcoin seed» مفتاحًا للدالة والبذرة بياناتٍ لها. أول 32 بايتًا هي مرشح المفتاح الخاص، وآخر 32 بايتًا هي chain code. الصفر أو قيمة لا تقل عن رتبة المنحنى n تجعل المفتاح الرئيسي غير صالح. [1]

الاشتقاق عملية حسابية، وليس بحثًا في قائمة محفوظة. هناك اشتقاق عادي واشتقاق hardened. يتيح العادي حساب المفاتيح العامة التالية من المفتاح العام الموسع الأب؛ أما خطوة hardened فتحتاج إلى المفتاح الخاص الموسع الأب. يحسب CKDpriv القيمة I = HMAC-SHA512(cpar, data)، ويقسمها إلى IL وIR، ثم يجمع parse256(IL) مع المفتاح الخاص الأب بترديد n. تصبح IR قيمة chain code الجديدة. يستخدم الاشتقاق العادي serP(Kpar) || ser32(i)، ويستخدم hardened الصيغة 0x00 || ser256(kpar) || ser32(i)، حيث i ≥ 2^31. أما CKDpub فينتج الفروع العامة العادية فقط، بإضافة point(parse256(IL)) إلى Kpar. تغيير رقم الفرع يغيّر المفاتيح المشتقة بعده. [1]

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

على mainnet، يبدأ الترميز العام القياسي بـ xpub والخاص بـ xprv؛ وقيمتا الإصدار هما 0x0488B21E و0x0488ADE4. قبل Base58Check يبلغ السجل 78 بايتًا: الإصدار 4، العمق 1، بصمة الأب 4، رقم الابن 4، chain code بطول 32، وبيانات المفتاح 33. يتكون الناتج من 111 محرفًا. تساعد البصمة القصيرة في مطابقة المفاتيح، لكنها ليست إثبات هوية. قد تشير بادئتا ypub/zpub في SLIP132 إلى نوع السكربت؛ وتغيير البادئة وحده لا يغيّر المفاتيح ولا قواعد المحفظة. [1] [9]

خصّص BIP43 أول مستوى hardened لغرض الاستخدام. يستخدم BIP44 المسار m / 44' / coin_type' / account' / change / address_index. بعد الحساب يأتي الفرع 0 للاستلام أو 1 للباقي، ثم رقم العنوان. تشير العلامة ' أو h إلى فهرس زيد بمقدار 2^31. يستخدم بحث BIP44 حد gap limit بقيمة 20: يتوقف بعد 20 عنوان استلام متتاليًا لم يُستخدم. يصف BIP48 نظام Multisig، ويخصص BIP84 الغرض 84' لـ SegWit الأصلي، وBIP86 الغرض 86' لـ Taproot ذي المفتاح الواحد. هذه اتفاقات لا تُخزّن في البذرة نفسها ولا تفرضها العقد. [2] [3] [4] [5] [6]

المفاتيح وحدها لا تحدد السكربت الذي يحمي الأموال. يمكن لـ Output Descriptor تسجيل أصل المفاتيح ومساراتها وبنية مثل wpkh() وعدد التوقيعات المطلوب ومشاركي Multisig الآخرين ومجموع تحقق. ويمكن لـ multipath descriptor جمع فرعي الاستلام والباقي. بذرة مشارك واحد لا تعيد بناء قيم xpub الأخرى ولا القواعد المشتركة. احتفظ أيضًا بوصف عام متحقق منه أو بتصدير الإعدادات، واحمِ خصوصيته. إذا احتوى التصدير على مفاتيح خاصة فتعامل معه بوصفه سرًا. [7] [8] [10] [13]

تسمح البذرة باشتقاق المفاتيح مجددًا، لكن التطبيق يحتاج إلى صيغة البذرة وBIP39 passphrase المستخدمة والشبكة ونوع السكربت وcoin type والحسابات والفرعين ونطاق البحث. يحتاج Multisig كذلك إلى الإعدادات المشتركة. الرصيد الصفري بعد الاستعادة لا يعني بالضرورة فقدان العملات؛ فقد يكون البحث في مسار مختلف. ينبغي للاختبار الآمن على جهاز موثوق أن يجد UTXO الصحيحة، أي مخرجات المعاملات التي لم تُنفق بعد، ويتحقق من التوقيع. لا تُدخل بذرة حقيقية أو كلمات نسخة احتياطية في أداة ويب أو حاسوب عادي متصل بالإنترنت. [3] [7] [10] [11]

يعالج BIP32 نتائج غير صالحة نادرة: parse256(IL) ≥ n، أو مفتاحًا خاصًا مشتقًا يساوي صفرًا، أو نقطة عامة عند اللانهاية. عندئذ يُجرّب الفهرس التالي. الأكثر شيوعًا في الاستعادة هو غياب المسار أو فرع الباقي أو دعم نوع السكربت. قبل تغيير التطبيق، تحقّق من العثور على الأموال ومن تحويل تجريبي صغير. احتفظ بالنسخة والإعدادات الأصليتين إلى أن يعمل الإجراء الجديد. يتيح xprv اشتقاق مفاتيح التوقيع، ويكشف xpub الروابط المالية، ويصف descriptor كيفية بناء المحفظة. [1] [7] [9] [10]