عنوان بيتكوين

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

انسخ العنوان الطويل أو امسح رمز QR بدل كتابته يدويًا. لكن التحقق لا ينتهي هنا: قد يستبدل برنامج خبيث العنوان في الحافظة بعنوان آخر. قارن العنوان كاملًا بالبيانات التي حصلت عليها من المستلم عبر وسيلة موثوقة. وإذا كنت تستخدم Hardware Wallet، فتحقق أيضًا من شاشة الجهاز نفسه. لا تكفي البداية والنهاية، فقد يقلدهما عنوان احتيالي. تتضمن العناوين مجموع تحقق يساعد في كشف أخطاء الكتابة، لكنه لا يحدد ما إذا كان العنوان الصحيح في صياغته يخص الشخص المقصود. ويجب أن تدعم المحفظة الصيغة والشبكة أيضًا. قد تساعد دفعة تجريبية صغيرة، لكنها لا تغني عن مراجعة العنوان عند التحويل التالي. لا يوفر البروتوكول إلغاءً بسيطًا لدفعة مؤكدة أُرسلت إلى عنوان خاطئ لكنه صالح. [2] [7] [8] [18]

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

تدير المحفظة المفاتيح، وتبحث عن الدفعات التي تستطيع إنفاقها، وتعرض مجموعها. لذلك قد يأتي رصيدها من عناوين كثيرة. تنشئ HD Wallet المعتادة عائلات من المفاتيح انطلاقًا من أصل مشترك؛ فلا يعني العنوان الجديد إنشاء محفظة أخرى. وعند الدفع قد يعيد التطبيق المبلغ المتبقي إلى عنوان يخصه يسمى Change Address، أي عنوان الباقي. لكن العناوين وحدها لا تكفي للاستعادة. يجب أن تتيح النسخة الاحتياطية استعادة المفاتيح اللازمة وقواعد استخدامها. تستخدم محافظ كثيرة Seed Phrase، وهي مجموعة كلمات للاستعادة؛ وقد تحتاج الإعدادات الأكثر تعقيدًا إلى معلومات إضافية. لا يحتاج الدافع أبدًا إلى تلك الكلمات أو إلى مفاتيحك الخاصة. [10] [14]

رمز QR مجرد طريقة لتمثيل المعلومات. قد يحمل عنوانًا وحده أو طلب دفع يبدأ بـ bitcoin: ويضيف المبلغ أو تسمية المستلم أو رسالة. وصف BIP21 هذه الآلية ويوسعها BIP321. راجع ما قرأته المحفظة فعلًا قبل الموافقة. تستخدم طلبات Lightning Network، مثل invoice لدفعة واحدة أو offer يمكن استخدامه لطلب invoice جديدة في كل مرة، مسار دفع مختلفًا؛ وتسهّل Lightning Address الحصول على مثل هذا الطلب. وقد يتيح الطلب الواحد عدة طرق للدفع. وبالمثل، لا يثبت التوقيع الرقمي لرسالة الهوية تلقائيًا: يتيح BIP322 إثبات القدرة على استيفاء شروط سكربت، لكنه لا يثبت بمفرده الهوية القانونية ولا الموافقة على أي فاتورة كيفما كانت. [15] [16] [17]

يجمع Base58Check بايت الإصدار مع البيانات المسماة payload. ثم يضيف أول أربعة بايتات من SHA256(SHA256(version || payload)) ويرمّز النتيجة بأبجدية Base58. في mainnet يشير 0x00 إلى P2PKH ويشير 0x05 إلى P2SH، لذلك تبدأ العناوين عادة بـ 1 أو 3. تستخدم شبكات الاختبار إصدارات أخرى. وتستبعد الأبجدية الرموز المتشابهة 0 وO وI وl. يكشف مجموع التحقق هذا، بطول 32 بت، كثيرًا من أخطاء الكتابة، لكنه لا يثبت هوية المستلم. [2] [3]

يتضمن تمثيل SegWit الأصلي البادئة bc لشبكة mainnet أو tb لشبكة testnet، والفاصل 1، وإصدار witness، وبيانات مقسمة إلى مجموعات من 5 بتات. وينتهي بـ 6 أحرف لمجموع التحقق. قدّم BIP173 ترميز Bech32، وبعد اكتشاف ضعف عند بعض عمليات الإدراج والحذف، أبقى BIP350 على Bech32 للإصدار 0 وحدد Bech32m للإصدارات 1–16. يجوز أن تكون الأحرف كلها صغيرة أو كلها كبيرة، ولا يجوز خلط الحالتين. حد الترميز هو 90 حرفًا. وحتى التمثيل الصحيح قد يشير إلى شبكة خاطئة أو إصدار غير مدعوم. [7] [8]

يشير P2PKH وP2WPKH إلى HASH160 للمفتاح العام بطول 20 بايتًا. يستخدم P2SH قيمة HASH160 للسكربت redeemScript، بينما يستخدم P2WSH قيمة SHA256 للسكربت witnessScript. لذلك يميز SegWit v0 بين P2WPKH بطول 20 بايتًا وP2WSH بطول 32 بايتًا. أما P2TR وفق BIP341 فمختلف: برنامجه من الإصدار 1 يحتوي على مفتاح المخرج Q المعدّل، بصيغة x-only وطول 32 بايتًا، وليس هاش مفتاح استقبال عادي. ويمكن أيضًا إدخال جذر شجرة سكربتات إضافية في حساب Q، فيرتبط المفتاح تشفيريًا بشروط الإنفاق التي تحددها تلك السكربتات. لذلك لا يكشف العنوان وحده كل طرق الإنفاق. [6] [9]

كانت مخرجات بيتكوين المبكرة كثيرًا ما تدفع مباشرة إلى مفتاح عام. وأجّل P2PKH كشفه حتى الإنفاق. أتاح BIP13 وBIP16 نقل هاش سكربت أكثر تعقيدًا باستخدام P2SH. وأضاف BIP141 برامج witness ذات إصدارات، وBIP173 ترميز Bech32، ثم BIP341 مع BIP350 صيغة Taproot باستخدام Bech32m. وراء اختلاف المظهر توجد شروط تحقق مختلفة. لا «تحوّل» العنوان بتبديل بادئته يدويًا؛ فقد تنشئ مخرجًا مختلفًا أو غير قابل للإنفاق. بعض السكربتات غير القياسية والمخرجات المبكرة من نوع pay-to-pubkey ليس لها عنوان قياسي معتاد. [4] [5] [6] [7] [8] [9] [3]

تشتق HD Wallet وفق BIP32 مفاتيح كثيرة من جذر مشترك. تميز المسارات أنواع المخرجات: يستخدم BIP44 الغرض 44' لـ P2PKH، وBIP84 الغرض 84' لـ P2WPKH، وBIP86 الغرض 86' لـ P2TR ذي المفتاح الواحد. ثم يأتي نوع العملة (coin type)، والحساب، وفرع الاستقبال أو الباقي، وفهرس العنوان. قد لا تكفي Seed Phrase وحدها لتحديد جميع المسارات والحسابات وقواعد Multisig. ويسجل Output Descriptor أصل المفاتيح وبناء السكربت أيضًا. يجب أن تستعيد عملية الاسترداد الأموال الفعلية، لا أن تعرض عنوانًا مألوفًا واحدًا فحسب. [10] [11] [12] [13] [14]

في P2PKH وP2WPKH يظهر عادة هاش المفتاح في البداية، ثم يُكشف المفتاح العام عند الإنفاق. ويكشف P2SH وP2WSH السكربت المستخدم، redeemScript أو witnessScript. أما Taproot فيحتوي أصلًا على مفتاح عام معدّل داخل المخرج. يضيف الإنفاق عبر key path عادة Schnorr Signature، بينما يكشف الإنفاق عبر script path السكربت المختار وcontrol block ومسار Merkle؛ وقد تبقى الفروع غير المستخدمة مخفية. لذلك لا يصح القول إن كل عنوان يخفي المفتاح العام. [6] [9]