Bitcoin Vault

في محفظة عادية أحادية التوقيع، يستطيع لص يملك المفتاح إنشاء دفعة مباشرة. يهدف vault إلى تقييد هذا الخروج الفوري: يبدأ المفتاح التشغيلي العملية، لكنه لا ينبغي أن يتجاوز وحده الانتظار ومسار الاستعادة. السؤال هو أي توليفات مفاتيح تستطيع الدفع مباشرة وأيها يجب أن تمر بحالة وسيطة. لا يثبت اسم vault أو تحويل يؤخره التطبيق فرض القيود على blockchain. [BIP 345 — OP_VAULT]

يميّز النموذج بين UTXO المودع ومخرج unvault الوسيط المؤكد والدفعة المكتملة. إذا تطلب فرع السحب المعتاد لمخرج وسيط تأكد في الكتلة H انتظار 144 كتلة، فأبكر استخدام له يكون عند H+144 مع استيفاء الشروط الأخرى. ينبغي لمسار الاستعادة إتاحة التدخل قبل ذلك. ليست المدة 24 ساعة بالضبط ولا عكسًا تلقائيًا للدفعة؛ إذ يجب أن يسبق التدخل الفعال الإنفاق النهائي المؤكد. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]

تستخدم بعض البنى القواعد الحالية ومعاملات موقعة مسبقًا. وتقيّد الإنفاق البديل باشتراط حذف مفاتيح التوقيع أحادية الاستخدام بأمان، أو موافقة أطراف مستقلة إضافية. لكن الشبكة نفسها لا تثبت حذف المفتاح. قد تتيح نسخة سرية محفوظة تجاوز المسار المقصود. والمعاملات الموقعة مسبقًا جزء من الاستعادة أيضًا؛ فقد لا يعيد seed وحده إنشاء توقيعات مفتاح حُذف بالفعل. [BIP 345 — OP_VAULT] [Revault — Transaction specification]

تميّز مواصفات Revault بين stakeholders وmanagers وcosigning servers. يستخدم مخرج deposit مفاتيح stakeholders بنظام N-of-N؛ ويسمح مخرج unvault بمسارهم أو بمسار managers وcosigners بعد X كتل. تعيد Cancel المخرج إلى سياسة deposit، بينما تنقله emergency إلى Emergency Deep Vault. ويوجد أيضًا bypass يوقّعه stakeholders. لذلك لا يضمن النموذج تأخيرًا عند اختراق جميع مفاتيحهم، وليس وصفًا عامًا لكل vault. [Revault — Transaction specification]

بحسب مراجعة 8 سبتمبر 2026، حالة BIP 345 هي Closed ويشير إلى BIP 443 بصفة Proposed-Replacement. كان يجمع أصلًا OP_VAULT وOP_VAULT_RECOVER مع OP_CHECKTEMPLATEVERIFY. يقترح BIP 443 التعليمة الأعم OP_CHECKCONTRACTVERIFY، أو OP_CCV، وحالته Draft؛ ولم تُحدد آلية تفعيله. كذلك BIP 119 هو Draft. لا يثبت رقم BIP أو تنفيذ تجريبي أو مثال vault منشور بحد ذاته تفعيل هذه القواعد على Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]

يجب أن يتعرف المراقب على سحب غير متوقع، لا أن يرى معاملة فقط. تحتاج الاستجابة إلى معاملة إنقاذ صالحة وشبكة متاحة ورسوم كافية. الإرسال إلى mempool ليس تأكيدًا؛ فقد يهدر الازدحام أو pinning أو أسلوب غير مناسب لرفع الرسوم النافذة. يحدد Revault استخدام CPFP وALL | ANYONECANPAY لبعض معاملات الإنقاذ لإضافة مدخلات تدفع الرسوم. معدلاته التاريخية ليست توصيات برسوم اليوم. [BIP 345 — OP_VAULT] [Revault — Transaction specification]

لا يفيد التحويل إلى سكربت استعادة إلا إذا استطاع المالك المخوّل استيفاء شروطه لاحقًا. قد تستبدل المفاتيح غير المتاحة أو الإعدادات الناقصة أو التوقيعات المسبقة المفقودة السرقة بقفل دائم على المالك نفسه. وقد يسمح مسار إنقاذ سهل التشغيل أكثر من اللازم بالمضايقة عبر إلغاء السحوبات مرارًا. لذا افصل صلاحية إطلاق النقل الوقائي عن صلاحية الإنفاق من وجهته، وتحقق من الدورين. [BIP 345 — OP_VAULT] [Revault — Transaction specification]

ينبغي أن يسرد التحقق جميع مسارات السحب وbypass وافتراضات الإجماع والنسخ المطلوبة ووقت الاستجابة. يجب أن تغطي بيئة اختبار منفصلة السحب العادي والمحاولة المبكرة وunvault غير المتوقع وتعطل المراقب وعدم توافر أموال الرسوم. ويجب التمييز بين توقيع صالح وقبول mempool والتأكيد. نجاح عرض سيناريو واحد لا يثبت سلامة جميع الفروع؛ وليست هذه النماذج تعليمات لإيداع أموال حقيقية في سكربت تجريبي. [BIP 345 — OP_VAULT] [Revault — Transaction specification]