PSBT v2

تريد آنا ويان دفع فاتورة واحدة معًا. يساهم كل منهما بجزء من الأموال ويضيف توقيعه على جهازه الخاص. ما يحتاجان إلى تبادله هو مقترح متفق عليه، لا مفاتيحهما الخاصة. المفتاح الخاص عدد سري تستخدمه المحفظة لإنشاء توقيع رقمي يجيز إنفاق الأموال. يعمل PSBT كظرف عمل يضم المعاملة والبيانات المساندة لها. تشير المدخلات إلى مبالغ سابقة ستُنفَق، وتحدد المخرجات مبالغ جديدة وشروط إنفاقها لاحقًا. تحتفظ صيغة PSBT v0 الأصلية بهذا الهيكل داخل معاملة ثابتة غير موقعة في قسم البيانات المشتركة للملف. أما في v2، فيمكن إضافة المدخلات والمخرجات تدريجيًا وفق القواعد ذات الصلة. الميزة هي البناء المشترك، وليست إعادة كتابة ما وقّعه شخص آخر بلا قيود. [1] [2]

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

الإعلان عن دعم PSBT في تطبيق أو جهاز لا يثبت دعم v2. المطلوب فحص المسار كاملًا: الإنشاء والاستيراد والتوقيع وإعادة النتيجة بين البرامج والأجهزة المحددة. لا يمكن استخدام PSBT v0 وv2 بدلًا من بعضهما مباشرة. فالتحويل إلى v0 يتطلب بناء معاملة غير موقعة وضبط الحقول وفق قواعد ذلك الإصدار؛ تغيير رقم لا يكفي. كذلك فإن Taproot، وهو أسلوب أحدث لتحديد شروط إنفاق مخرجات Bitcoin، ليس هو نفسه v2. يحدد BIP 371 بيانات التوقيع الخاصة به لكلا إصداري PSBT. تجربة المسار كاملًا بمبلغ صغير تتحقق من توافق هذه المجموعة، لا من صحة كل دفعة مستقبلية. [1] [3]

لإصدار صيغة الملف وإصدار معاملة Bitcoin معنيان مختلفان. في v2، يجب أن يحتوي PSBT_GLOBAL_VERSION على 2، وأن يغيب الحقل القديم PSBT_GLOBAL_UNSIGNED_TX. ويحدد حقل إلزامي مستقل، هو PSBT_GLOBAL_TX_VERSION، إصدار المعاملة نفسها. كما يجب تحديد عدد المدخلات والمخرجات. يتيح هذا الفصل وضع المعلومات بجوار كل عنصر، بدل أن يبحث البرنامج عنها أيضًا في هيكل مشترك. إذا فوّض المنشئ استكمال البناء إلى مشاركين آخرين، فإن BIP 370 يشترط ضبط أعلام التعديل المناسبة وأن يكون إصدار المعاملة على الأقل 2. تبقى هذه صيغة عمل، وليست قواعد إجماع جديدة للشبكة. [1]

يحتاج كل مدخل إلى TXID، أي معرّف المعاملة السابقة، وإلى فهرس المخرج المحدد الذي سيُنفق منها. لا يكفي TXID وحده، لأن المعاملة قد تضم عدة مخرجات. ويحمل كل مخرج جديد مبلغًا بوحدة satoshi، أصغر وحدات Bitcoin، وحقل scriptPubKey، وهو السكربت الذي يحدد شروط الإنفاق. يجب أن يصاحب إضافة العنصر تحديث عدده العام أيضًا. يحمل الحقل الاختياري sequence قيمة تحكم أخرى للمدخل؛ وإذا غاب تُستخدم 0xffffffff. تصف هذه البيانات كيفية تركيب المعاملة، لكنها لا تستبدل بيانات قيمة UTXO وشروط إنفاقها، التي يحتاج إليها الجهاز لتقييم التوقيع والرسوم بأمان. [1]

لنفترض أن يان يحتاج إلى إضافة مدخل آخر. لا يجوز للبرنامج افتراض أن ذلك مسموح لمجرد أنه يملك الملف. في PSBT_GLOBAL_TX_MODIFIABLE يشير البت 0 إلى إمكانية تغيير المدخلات، والبت 1 إلى إمكانية تغيير المخرجات. وينبّه البت 2 إلى وجود توقيع SIGHASH_SINGLE، الذي يربط مدخلًا بالمخرج الموجود في الموضع المقابل. يجب الحفاظ على هذا الارتباط عند إدراج عناصر إضافية أيضًا. لذلك يفحص منشئ المعاملة التوقيعات الفعلية وقيودها. تنقل الأعلام معلومات إلى البرامج المتعاونة؛ لكنها لا تتجاوز توقيعًا تشفيريًا ولا تجعل تعديلًا غير صالح صالحًا. [1]

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

يقلّ مجال التعديلات اللاحقة مع إضافة التوقيعات. يشترط BIP 370 تعطيل تغييرات المدخلات عند عدم استخدام SIGHASH_ANYONECANPAY، وتغييرات المخرجات عند عدم استخدام SIGHASH_NONE؛ ومع SIGHASH_SINGLE يُسجّل الارتباط الواجب الحفاظ عليه. تصف هذه الأسماء نطاقات مختلفة لحماية التوقيع، وليست خيارات يبدّلها المبتدئ عشوائيًا. عندما تصبح جميع المدخلات جاهزة، تجمع مرحلة الإنهاء بيانات التوقيع اللازمة، ثم ينشئ المستخرج من الحقول معاملة بصيغة الشبكة. وحده بثها يتيح للعقد تقييمها ولأحد المعدّنين إدراجها في كتلة. لذا تميّز آنا ويان بين مقترح ونتيجة موقعة ودفعة مؤكدة؛ فتبادل PSBT وحده لا يعني التوقيع ولا التأكيد. [1] [2] [4]