Miniscript

تريد آنا استخدام عملاتها عادةً بمفتاحها الخاص. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. وتريد آنا أيضاً إتاحة مسار لبيتر، بحيث يستطيع إنفاقها بمفتاحه بعد مرور 144 كتلة على تأكيد ذلك المخرج. تسمى هذه النية spending policy، أي سياسة الإنفاق. يساعد Miniscript على تحويلها إلى وصف دقيق تستطيع المحفظة التعامل معه. يظل بيتر محتاجاً إلى مفتاحه؛ فالانتظار لا يحل محله. هذا مثال بسيط لمسارات وصول بديلة، وليس تحويلاً تلقائياً ولا آلية لاكتشاف أن آنا فقدت مفتاحها. [1] [2] [10]

القاعدة المكتوبة بالكلمات ليست بعد برنامجاً تتحقق منه الشبكة. يستطيع المترجم اختيار تعبير محدد بلغة Miniscript وتحويله إلى Bitcoin Script. ثم يصف Output Descriptor السكربتات الناتجة مع المفاتيح ومسارات اشتقاقها عند الحاجة؛ ويمكن أن يتضمن قيمة تحقق تكشف أخطاء النسخ. عند الإنفاق تفحص الشبكة السكربت الفعلي والبيانات المقدمة، لا الجملة الأصلية. لا يضيف Miniscript تعليمة جديدة ولا يغير الإجماع، أي قواعد الصلاحية المشتركة. كما لا يستطيع تمثيل كل Bitcoin Script يمكن تصوره. [1] [3] [6]

تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. في مثال بيتر تُحسب 144 كتلة من تأكيد المخرج، وهو مبلغ محدد مرتبط بشروط إنفاق. ليست المدة يوماً مضبوطاً، ولا تبدأ من إنشاء المحفظة. يعبّر Miniscript عن الانتظار النسبي باستخدام older(n)، اعتماداً على CSV وحقل nSequence في المدخل الذي ينفق ذلك المخرج. وتحدد BIP 68 معنى هذا الحقل عند التحقق من العمر. أما after(n) فيستخدم CLTV وحقل nLockTime المطلق لتحديد ارتفاع ثابت أو حد زمني. على المحفظة ضبط حقول المعاملة وتحقيق بقية الشروط. لا يجوز جمع أقفال الارتفاع والزمن بطريقة غير متوافقة؛ وانقضاء الانتظار لا يرسل شيئاً تلقائياً. [1] [7] [8] [9] [11]

عرض وصف القواعد لا يكفي. يجب تقديم بيانات تحقق أحد المسارات المسموح بها، مثل التوقيعات أو سر تطابق قيمة تجزئته القيمة المطلوبة، ويسمى preimage. قيمة التجزئة، أو hash، بصمة رقمية للبيانات؛ وهنا يُفحص ما إذا كان السر المقدم ينتج البصمة المطلوبة. يسمى هذا التحقيق satisfaction، وتدخل البيانات اللازمة ضمن witness المعاملة. وقد يتطلب الجمع بين الفروع جعل شرط جزئي غير متحقق بالطريقة المقررة كي يُستخدم مسار آخر. يسمى ذلك dissatisfaction، ولا يعني أن الدفع كله غير صالح. يستطيع البرنامج تجهيز المسار المناسب، لكنه لا يخترع مفتاحاً خاصاً مفقوداً أو سراً مجهولاً. [1] [12]

PSBT صيغة لنقل معاملة جاهزة ومعلومات مكملة بين المحفظة وأجهزة التوقيع. دعم PSBT وحده لا يكفي؛ يجب أن يفهم البرنامج وجهاز Hardware Wallet الـ descriptor وشروطه. أضاف Bitcoin Core مراقبة Miniscript في P2WSH بالإصدار 24، ثم التوقيع بالإصدار 25، واستخدامه في Taproot descriptors بالإصدار 26. لذلك فمراقبة العملات ليست القدرة على إنفاقها. عند الإعداد، تحقق على شاشة موثوقة من المفاتيح والتوقيعات المطلوبة وفترات الانتظار وكل المسارات البديلة، وفق إمكانات الجهاز الفعلية. [3] [4] [5]

تستعيد Seed Phrase المفاتيح، لكنها قد لا توضح في الشروط المخصصة كيف جُمعت مع مفاتيح أخرى ومع السكربت. هذه نسخة احتياطية مكتوبة كسلسلة مرتبة من الكلمات تستطيع المحفظة اشتقاق مفاتيحها منها. احتفظ بالـ descriptor الدقيق وقيمة التحقق الخاصة به، وخريطة المفاتيح ومسارات الاشتقاق، والتمييز بين عناوين الاستلام وعناوين الباقي. سجّل الشبكة ونطاق العناوين ونقطة بدء فحص السجل بصورة منفصلة. الـ descriptor العام ليس مفتاحاً خاصاً، لكنه قد يكشف سجل المدفوعات. قبل الاستخدام اختبر استعادة محفظة المراقبة وكل مسار إنفاق مخطط له في بيئة Regtest أو Signet التجريبية. [5] [6]

تمثل pk() وolder() وafter() وsha256() التوقيع أو الانتظار أو اشتراط سر. وتجمع and_v() وor_d() وthresh() الشروط. تعدل أغلفة مثل v: أسلوب التقييم مع الحفاظ على معنى التعبير الجزئي. تضبط الأنواع B وV وK وW كيفية تبادل المكونات للعناصر على المكدس، وهو مساحة عمل السكربت؛ فليس كل مكونين قابلين للتركيب معاً. يستطيع فحص الأنواع كشف تركيب غير متوافق. لكنه لا يقرر بمن ينبغي أن تثق آنا، ولا ما إذا اختارت مساراً احتياطياً معقولاً. [1] [2]

تتيح البنية تحليل حجم السكربت وwitness وعدد العمليات وفحوص التوقيع وعناصر المكدس قبل الإنفاق. يساعد ذلك على تقدير تكلفة المسارات وكشف تجاوز الحدود المسموح بها. لكن السياق مهم: يضع P2WSH الشروط ضمن SegWit، بينما يشير Tapscript إلى السكربتات المستخدمة في Taproot. ليست الحدود متطابقة في كل شيء. وإلى جانب الإجماع، تسري قواعد ترحيل المعاملات المعتادة. لذلك لا تُعد نتيجة التحليل ضماناً بأن كل محفظة تستطيع تنفيذ الإجراء المقصود. [1]

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

قد يصوغ المترجم القواعد نفسها بطرق تختلف في حجم السكربت وwitness، ويختار وفق نموذج للتكلفة. علامة مثل 9@ على فرع في لغة إدخال السياسات تلمح إلى احتمال استخدامه النسبي، ولا تعني عدد التوقيعات أو إذناً من الشبكة. وقد تنتج ترجمة مختلفة سكربتاً مختلفاً، وبالتالي عناوين مختلفة. لذلك لا تكفي إعادة وصف القواعد بالكلمات وترجمتها لاستعادة المحفظة. المهم هو التمثيل الدقيق المحفوظ، والتحقق من العناوين المشتقة، ومسار توقيع جرى اختباره. [2] [5]