Wallets & SchlüsselverwaltungWallets & Key ManagementWallets & Gestión de ClavesWallets & Gestão de Chavesウォレット & 鍵管理钱包 & 密钥管理المحافظ & إدارة المفاتيح
Miniscript & Descriptors: Programmierbare Regeln für die SelbstverwahrungMiniscript & Descriptors: Programmable Rules for Self-CustodyMiniscript & Descriptors: Reglas programables para la autocustodiaMiniscript & Descriptors: Regras programáveis para a autocustódiaMiniscript & Descriptors: セルフカストディのためのプログラム可能なルールMiniscript & Descriptors：可编程的自托管规则Miniscript & Descriptors: قواعد قابلة للبرمجة للحضانة الذاتية
Alle acht Quellen-URLs wurden live abgerufen und sind gültig; die Kernfakten (BIP-379-Merge und -Status, BIP-388-Status, Bitcoin-Core-Versionen, Ledger 2.1.0 inkl. Security Bulletin 019, BitBox02-Firmware 9.15.0/9.21.0, Jade-Blogpost vom 23.07.2024, Liana-1.0-Release, Liana-Business-Preis 0,016 %) wurden gegen Primärquellen wie GitHub-Releases, das BIP-Verzeichnis, Hersteller-Blogs und Bitcoin Optech geprüft. Fünf Fehler des Entwurfs wurden dabei gefunden und korrigiert. Zwei Jahresangaben (BitBox02 9.15.0, Liana 1.0) mussten aus Kontextdaten abgeleitet werden, da die Release-Seiten das Jahr nicht direkt anzeigten – daher kein Verified-Level.All eight source URLs were fetched live and are valid; the core facts (BIP 379 merge and status, BIP 388 status, Bitcoin Core versions, Ledger 2.1.0 including Security Bulletin 019, BitBox02 firmware 9.15.0/9.21.0, Jade blog post of 23 July 2024, Liana 1.0 release, Liana Business pricing of 0.016%) were checked against primary sources such as GitHub releases, the BIP repository, vendor blogs and Bitcoin Optech. Five errors in the draft were found and corrected. Two year figures (BitBox02 9.15.0, Liana 1.0) had to be inferred from context because the release pages did not directly show the year – hence no verified level.Las ocho URLs de fuentes fueron consultadas en tiempo real y son válidas; los datos fundamentales (fusión y estado de BIP 379, estado de BIP 388, versiones de Bitcoin Core, Ledger 2.1.0 incluido el Boletín de Seguridad 019, firmware de BitBox02 9.15.0/9.21.0, entrada de blog de Jade del 23 de julio de 2024, lanzamiento de Liana 1.0, precio de Liana Business del 0,016 %) fueron verificados contra fuentes primarias como versiones de GitHub, el repositorio BIP, blogs de fabricantes y Bitcoin Optech. Se encontraron y corrigieron cinco errores en el borrador. Dos datos de año (BitBox02 9.15.0, Liana 1.0) tuvieron que inferirse a partir del contexto, ya que las páginas de lanzamiento no mostraban el año directamente; de ahí que no se haya alcanzado el nivel de verificado.As oito URLs de fontes foram acessadas em tempo real e são válidas; os fatos centrais (merge e status do BIP 379, status do BIP 388, versões do Bitcoin Core, Ledger 2.1.0 incluindo o Boletim de Segurança 019, firmware do BitBox02 9.15.0/9.21.0, post do blog do Jade de 23 de julho de 2024, lançamento do Liana 1.0, preço do Liana Business de 0,016%) foram verificados em fontes primárias, como releases do GitHub, o repositório BIP, blogs de fabricantes e o Bitcoin Optech. Cinco erros no rascunho foram encontrados e corrigidos. Dois dados de ano (BitBox02 9.15.0, Liana 1.0) precisaram ser inferidos a partir do contexto, pois as páginas de release não exibiam o ano diretamente — por isso, não foi atribuído o nível de verificado.8つのソースURLはすべてライブで取得済みであり、有効です。主要な事実（BIP 379のマージおよびステータス、BIP 388のステータス、Bitcoin Coreのバージョン、セキュリティ情報019を含むLedger 2.1.0、BitBox02ファームウェア9.15.0/9.21.0、2024年7月23日付けのJadeブログ投稿、Liana 1.0リリース、Liana Businessの価格0.016%）は、GitHubリリース、BIPリポジトリ、メーカーブログ、Bitcoin Optechといった一次情報源と照合して確認されました。下書きにおける5つの誤りが発見・修正されました。2つの年の情報（BitBox02 9.15.0、Liana 1.0）はリリースページに年が直接表示されていなかったため、文脈から推定する必要がありました。そのため、検証済みレベルには達していません。所有八个来源URL均已实时抓取且有效；核心事实（BIP 379的合并与状态、BIP 388的状态、Bitcoin Core版本、含安全公告019的Ledger 2.1.0、BitBox02固件9.15.0/9.21.0、Jade于2024年7月23日发布的博客文章、Liana 1.0发布、Liana Business定价0.016%）已与GitHub发布页、BIP存储库、厂商博客及Bitcoin Optech等一手来源进行了核实。草稿中发现并纠正了五处错误。由于发布页面未直接显示年份，两个年份数据（BitBox02 9.15.0、Liana 1.0）需从上下文中推断——因此未达到已验证级别。تم جلب جميع روابط المصادر الثمانية مباشرةً وهي صالحة؛ وقد جرى التحقق من الحقائق الجوهرية (دمج BIP 379 وحالته، وحالة BIP 388، وإصدارات Bitcoin Core، وLedger 2.1.0 بما يشمل النشرة الأمنية 019، وإصدارات البرنامج الثابت لـ BitBox02 بالإصدارين 9.15.0 و9.21.0، ومنشور مدونة Jade بتاريخ 23 يوليو 2024، وإصدار Liana 1.0، وسعر Liana Business البالغ 0.016%) مقارنةً بمصادر أولية كإصدارات GitHub، ومستودع BIP، ومدونات الشركات المصنِّعة، وموقع Bitcoin Optech. وقد تم العثور على خمسة أخطاء في المسودة وتصحيحها. واضطُر إلى استنتاج تاريخَي السنة لكلٍّ من (BitBox02 9.15.0 وLiana 1.0) من السياق، نظرًا لعدم عرض صفحات الإصدار للسنة بشكل مباشر — ولهذا السبب لم يُمنح مستوى التحقق.
Die stärkste verbleibende Gegenposition: Der Artikel ist trotz aller Kaveats eine Technik-Erzählung aus der Perspektive der Bauenden. Sämtliche Anwendungsfälle und Sicherheitsversprechen stammen von wirtschaftlich interessierten Herstellern, und es gibt keine einzige unabhängige Messung, dass Miniscript-Policies in der Praxis Verluste reduzieren. Solange diese Evidenz fehlt, ist die redliche Default-Empfehlung für fast alle Nutzer ein langweiliges, breit unterstütztes Single-Sig- oder Standard-Multisig-Setup – und Miniscript ein Werkzeug für die kleine Minderheit, die ihre Wartungsdisziplin realistisch einschätzen kann.The strongest remaining counterposition: despite all caveats, the article is a technology narrative told from the builders' perspective. Every use case and safety promise originates from commercially interested vendors, and there is not a single independent measurement showing that Miniscript policies reduce losses in practice. Until that evidence exists, the honest default recommendation for almost all users is a boring, widely supported single-sig or standard multisig setup – with Miniscript as a tool for the small minority who can realistically assess their own maintenance discipline.La contraposición más sólida que subsiste: a pesar de todos los matices, el artículo es una narrativa tecnológica contada desde la perspectiva de quienes construyen. Todos los casos de uso y las promesas de seguridad provienen de fabricantes con intereses comerciales, y no existe ni una sola medición independiente que demuestre que las políticas de Miniscript reducen las pérdidas en la práctica. Mientras esa evidencia no exista, la recomendación predeterminada honesta para casi todos los usuarios es una configuración aburrida y ampliamente compatible de single-sig o multisig estándar, siendo Miniscript una herramienta para la pequeña minoría que puede evaluar de forma realista su propia disciplina de mantenimiento.A contraposição remanescente mais forte: apesar de todos os ressalvas, o artigo é uma narrativa tecnológica contada sob a perspectiva de quem constrói. Todos os casos de uso e as promessas de segurança partem de fornecedores com interesses comerciais, e não existe uma única medição independente que demonstre que as políticas do Miniscript reduzem perdas na prática. Enquanto essa evidência não existir, a recomendação padrão honesta para quase todos os usuários é uma configuração entediante e amplamente suportada de single-sig ou multisig padrão — sendo o Miniscript uma ferramenta para a pequena minoria que consegue avaliar de forma realista sua própria disciplina de manutenção.残る最も強力な反論：あらゆる注意書きにもかかわらず、本記事は構築者の視点から語られた技術的な物語である。すべてのユースケースと安全性の約束は商業的な利害を持つベンダーから来ており、Miniscriptのポリシーが実際に損失を減らすことを示す独立した測定は一つも存在しない。その証拠が存在しない限り、ほぼすべてのユーザーにとって誠実なデフォルトの推奨は、退屈で広くサポートされているsingle-sigまたは標準的なmultisigのセットアップであり、Miniscriptは自らのメンテナンス規律を現実的に評価できるごく少数の人々のためのツールに留まる。最有力的残余反驳观点：尽管有种种说明，本文本质上仍是一篇从建构者视角讲述的技术叙事。所有用例和安全承诺均来自有商业利益的厂商，且没有任何一项独立测量能证明 Miniscript 策略在实践中减少了损失。在该证据出现之前，对几乎所有用户而言，诚实的默认建议是采用无聊但获得广泛支持的 single-sig 或标准 multisig 方案——而 Miniscript 只是适合那一小部分能够切实评估自身维护纪律的少数人的工具。أقوى موقف مضاد لا يزال قائماً: على الرغم من جميع التحفظات، فإن المقال روايةٌ تقنية مُقدَّمة من منظور البنّائين. كل حالات الاستخدام والوعود الأمنية صادرةٌ عن موردين ذوي مصالح تجارية، وليس ثمة قياسٌ مستقل واحد يُثبت أن سياسات Miniscript تُقلّل الخسائر في الواقع العملي. وما لم تتوفر هذه الأدلة، فإن التوصية الافتراضية الأمينة لجميع المستخدمين تقريباً هي إعداد مملٌّ وواسع الدعم من نوع single-sig أو multisig القياسي — فيما يظل Miniscript أداةً للأقلية الصغيرة القادرة على تقييم انضباطها الصيانيّ بصورة واقعية.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Eine der größten Verlustursachen bei selbstverwahrten Bitcoin ist kein Hack des Protokolls, sondern der banale Verlust des einen Schlüssels, an dem alles hängt. Eine Standard-Wallet kennt genau eine Ausgaberegel: Wer die Signatur zum Schlüssel liefert, darf ausgeben – für immer, ohne Plan B. Dabei beherrscht Bitcoins Skriptsprache weit mehr, als fast alle Wallets nutzen: Mehrfachsignaturen und verschachtelte Bedingungen von Anfang an, skriptbasierte Zeitschlösser seit den Soft Forks von 2015/2016 (OP_CLTV, OP_CSV). Genutzt wurde davon jahrelang fast nichts, denn handgeschriebene Skripte waren fehleranfällig und für Wallet-Software praktisch nicht analysierbar. Zwei Bausteine haben das geändert: Output-Descriptors und Miniscript.
Ein Descriptor ist eine standardisierte Textzeile, die vollständig beschreibt, wie eine Wallet ihre Adressen bildet – Skripttyp, Schlüssel, Ableitungspfade. Miniscript ist eine strukturierte Teilmenge von Bitcoin Script innerhalb solcher Descriptors, die Software automatisch auf Korrektheit, Ausgabbarkeit und Gebührenbedarf prüfen kann.
Vom Skript zum Descriptor: Wallets werden beschreibbar
Vor Descriptors war die Frage „Welche Adressen gehören zu diesem Seed?" erstaunlich schlecht definiert: Jede Wallet-Software nutzte eigene Konventionen für Ableitungspfade und Skripttypen – ein bekanntes Wiederherstellungsproblem, das wir im Artikel zu HD-Wallets und Ableitungspfaden ausführlich behandeln. Pieter Wuille führte Descriptors 2018 mit Bitcoin Core 0.17 ein; die 2021 vorgeschlagene Familie der BIPs 380 bis 386 standardisierte die Sprache später formal. Ein Descriptor wie wpkh(xpub.../84h/0h/0h/0/*) beantwortet die Frage eindeutig und maschinenlesbar. Seit Bitcoin Core 23.0 (April 2022) sind Descriptor-Wallets der Standard für neu erstellte Wallets.
Der entscheidende Punkt: Ein Descriptor ist ein vollständiges, portables Backup der Konstruktionsanleitung einer Wallet – nicht nur der Schlüssel. Genau diese Eigenschaft macht komplexere Ausgaberegeln überhaupt erst verwaltbar.
Miniscript: Bitcoin Script, aber analysierbar
Miniscript wurde 2019 von Pieter Wuille, Andrew Poelstra und Sanket Kanjalkar vorgestellt; die Referenz-Spezifikation lebte zunächst auf einer eigenen Projektseite und ist seit Ende Juni 2024 als BIP 379 im offiziellen BIP-Verzeichnis dokumentiert (Status: Entwurf). Die Idee: Statt beliebiges Bitcoin Script zuzulassen, definiert Miniscript einen strukturierten Baukasten aus Fragmenten – Schlüsselprüfungen, Schwellenwerte, Hash-Locks, Zeitschlösser – die sich nach festen Regeln kombinieren lassen. Aus einer lesbaren Policy wie or(pk(A),and(pk(B),older(52560))) („Schlüssel A jederzeit, oder Schlüssel B nach rund einem Jahr Wartezeit") erzeugt ein Compiler deterministisch das zugehörige Skript.
Weil die Struktur formal definiert ist, kann Software drei Dinge automatisch beweisen, die bei handgeschriebenen Skripten Expertenarbeit waren: dass das Skript konsensgültig und tatsächlich ausgebbar ist, dass Dritte die Transaktion nicht verformen können (Malleability), und wie groß die Witness-Daten im schlimmsten Fall werden – also was die Ausgabe kostet. Bitcoin Core integrierte Miniscript schrittweise: beobachtende Wallets in Version 24.0 (Ende 2022), Signieren in 25.0 (Mai 2023), Taproot-Descriptors in 26.0 (Dezember 2023).
Output-Descriptors erscheinen in Bitcoin Core 0.17 – Wallets werden erstmals vollständig beschreibbar.
Wuille, Poelstra und Kanjalkar stellen Miniscript vor; erste Referenzimplementierung und Compiler.
Bitcoin Core 24.0 versteht Miniscript-Descriptors (watch-only); Descriptor-Wallets sind seit 23.0 Standard.
Bitcoin Core 25.0 signiert Miniscript. Ledger liefert Miniscript-Support in Bitcoin-App 2.1.0 aus (Februar), BitBox02 folgt mit Firmware 9.15.0 (August); Liana 1.0 erscheint im Mai als erste produktive Miniscript-Wallet.
Miniscript wird als BIP 379 ins offizielle BIP-Verzeichnis aufgenommen (Juni); Blockstream Jade zieht mit Firmware 1.0.30 bei der Hardware nach, BitBox02 ergänzt Taproot-Miniscript (Firmware 9.21.0).
Was Policies praktisch können: Recovery statt Alles-oder-nichts
Der Wallet-Hersteller Wizardsardine hat mit Liana das bekannteste Anwendungsmuster etabliert: einen primären Ausgabepfad plus zeitverzögerte Recovery-Pfade. Die Wartefrist läuft dabei relativ zum letzten Ausgabezeitpunkt der Coins (via older(), also relative Zeitschlösser): Solange der Besitzer aktiv ist und seine Coins regelmäßig bewegt, bleiben die Ersatzpfade wirkungslos – ein programmierter Totmannschalter, wie ihn unser Artikel zur Erbschaft per Timelock konzeptionell beschreibt.
Verfallende Multisig
Heute 3-von-3, nach sechs Monaten Inaktivität 2-von-3, nach einem Jahr genügt ein einzelner Schlüssel. Der Verlust einzelner Schlüssel führt nicht mehr zum Totalverlust – die Policy „verfällt" kontrolliert in Richtung Wiederherstellbarkeit.
Erbschafts-Policy
Erben erhalten einen Schlüssel, der erst nach langer Inaktivität ausgabefähig wird. Kein Anwalt, kein Verwahrer, keine Schlüsselkopie zu Lebzeiten – die Kette selbst setzt die Frist durch.
Firmen-Treasury
Abgestufte Berechtigungen: kleine Beträge mit einer Signatur, große nur mit Quorum plus Wartezeit. Blockstream nennt dies als Kernszenario für Miniscript auf dem Jade-Signer.
Anti-Backdoor-Setup
Ledger begründet den eigenen Miniscript-Support damit, dass Nutzer mehrere Geräte verschiedener Hersteller kombinieren können – ein einzelner kompromittierter Hersteller kann dann keine Coins stehlen.
Das Ökosystem, Stand Juli 2026
Miniscript ist der Nische entwachsen, aber kein Massenphänomen. Auf der Hardware-Seite unterstützen Specter-DIY (als Pionier seit April 2021), Ledger (seit Februar 2023), BitBox02 (seit August 2023), Coldcard und Blockstream Jade (seit 2024) Miniscript-Policies – teils inklusive Taproot (Ledger seit März 2024, BitBox02 seit Firmware 9.21.0, September 2024). BIP 388 („Wallet Policies" von Salvatore Ingala, Status „Complete") standardisiert, wie Signiergeräte solche Policies registrieren und dem Nutzer verständlich anzeigen; Coldcard nutzt das Format inzwischen als natives Speicherformat. Liana bleibt die Referenz-Software und wird aktiv weiterentwickelt; für Unternehmen und vermögende Privatkunden bietet Wizardsardine eine Business-Variante an (Stand Juli 2026: 0,016 % des verwalteten Vermögens pro Monat).
Die Kehrseite: Konfigurationsrisiko ersetzt Schlüsselrisiko nicht – es kommt dazu
Die Kernfrage dieses Artikels lässt sich nicht wegjubeln. Timelock-basierte Policies erzeugen eine Wartungspflicht: Relative Zeitschlösser laufen pro UTXO. Wer seine Coins nicht vor Ablauf der Frist bewegt („Refresh"), aktiviert den Recovery-Pfad – und damit potenziell den Zugriff von Erben, Dienstleistern oder Dieben eines Recovery-Schlüssels, während der Besitzer noch lebt und handlungsfähig ist. Wizardsardine dokumentiert diese Refresh-Pflicht selbst als integralen Bestandteil des Modells.
Bei Miniscript-Wallets ist der Seed allein kein vollständiges Backup mehr. Ohne den Descriptor (inklusive aller beteiligten xpubs) lassen sich die Adressen nicht rekonstruieren – die Coins sind trotz intaktem Seed praktisch unauffindbar. Der Descriptor muss separat und redundant gesichert werden; er verrät keine Schlüssel, wohl aber die Policy.
Hinzu kommt die Privatsphäre: Bei P2WSH-basierten Policies landet beim Ausgeben das komplette Skript on-chain – Beobachter sehen Schlüsselzahl, Schwellen und Fristen. Taproot mildert das erheblich, weil nur der tatsächlich genutzte Pfad offengelegt wird; der Schlüsselpfad bleibt von einer Normalzahlung ununterscheidbar. Und schließlich die Reife: Verglichen mit Single-Sig und klassischer Multisig sind exotische Policies seltener im Einsatz, seltener auditiert und auf weniger Software wiederherstellbar. Dass das keine theoretische Sorge ist, zeigte Ledgers Bitcoin-App: Die Versionen 2.1.0 und 2.1.1 erzeugten bei einem bestimmten Miniscript-Fragment falsche Adressen (Security Bulletin 019); der Fehler wurde in späteren Versionen behoben.
| Risiko | Single-Sig | Miniscript-Policy mit Recovery-Pfad |
|---|---|---|
| Verlust des Hauptschlüssels | Totalverlust | Recovery-Pfad greift nach Frist |
| Backup-Umfang | Seed genügt | Seed(s) + Descriptor zwingend |
| Laufende Wartung | keine | UTXO-Refresh vor Fristablauf |
| Fehlkonfiguration | kaum möglich | reale Gefahr (falsche Fristen, falsche Schlüssel) |
| Privatsphäre beim Ausgeben | hoch | P2WSH: Policy sichtbar; Taproot: nur genutzter Pfad |
Einordnung
Miniscript und Descriptors beseitigen Risiko nicht, sie machen es gestaltbar. Der Fortschritt ist real: Was früher handgeschriebene, unprüfbare Skripte erforderte, ist heute in BIPs dokumentiert (379, 380–386, 388), in Bitcoin Core integriert und auf verbreiteter Hardware signierbar – die Fehlerklasse „kaputtes Skript" ist weitgehend eliminiert. Die Fehlerklassen „vergessene Wartung" und „verlorener Descriptor" sind neu hinzugekommen. Ob die Bilanz positiv ausfällt, hängt weniger von der Kryptografie ab als von Disziplin und Werkzeugqualität: Für Nutzer, deren größtes Risiko der eigene Schlüsselverlust oder der ungeklärte Erbfall ist, verschiebt eine gut gewartete Policy das Risiko strukturell in die richtige Richtung – belastbare Verlustdaten, die das beziffern, existieren allerdings noch nicht. Für alle anderen gilt die alte Ingenieursregel: Die sicherste Komplexität ist die, die man nicht braucht.
Weiterführend
One of the largest causes of loss in self-custodied bitcoin is not a protocol hack but the mundane loss of the one key everything depends on. A standard wallet knows exactly one spending rule: whoever produces the signature for the key may spend – forever, with no plan B. Yet Bitcoin's scripting language is capable of far more than almost any wallet uses: multiple signatures and nested conditions from the very beginning, script-level timelocks since the 2015/2016 soft forks (OP_CLTV, OP_CSV). For years almost none of it was used, because hand-written scripts were error-prone and practically impossible for wallet software to analyse. Two building blocks have changed that: output descriptors and Miniscript.
A descriptor is a standardised line of text that fully describes how a wallet constructs its addresses – script type, keys, derivation paths. Miniscript is a structured subset of Bitcoin Script inside such descriptors that software can automatically check for correctness, spendability and fee requirements.
From Script to Descriptor: Wallets Become Describable
Before descriptors, the question "which addresses belong to this seed?" was surprisingly ill-defined: every wallet application used its own conventions for derivation paths and script types – a well-known recovery problem covered in depth in our article on HD wallets and derivation paths. Pieter Wuille introduced descriptors in 2018 with Bitcoin Core 0.17; the BIP 380–386 family, proposed in 2021, later standardised the language formally. A descriptor such as wpkh(xpub.../84h/0h/0h/0/*) answers the question unambiguously and machine-readably. Since Bitcoin Core 23.0 (April 2022), descriptor wallets have been the default for newly created wallets.
The crucial point: a descriptor is a complete, portable backup of a wallet's construction blueprint – not just of its keys. Precisely this property is what makes more complex spending rules manageable in the first place.
Miniscript: Bitcoin Script, but Analysable
Miniscript was introduced in 2019 by Pieter Wuille, Andrew Poelstra and Sanket Kanjalkar; its reference specification initially lived on a dedicated project site and has been documented as BIP 379 in the official BIP repository since late June 2024 (status: draft). The idea: instead of permitting arbitrary Bitcoin Script, Miniscript defines a structured toolkit of fragments – key checks, thresholds, hash locks, timelocks – that combine according to fixed rules. From a readable policy such as or(pk(A),and(pk(B),older(52560))) ("key A at any time, or key B after roughly one year of waiting") a compiler deterministically produces the corresponding script.
Because the structure is formally defined, software can automatically prove three things that used to require expert review of hand-written scripts: that the script is consensus-valid and actually spendable, that third parties cannot mutate the transaction (malleability), and how large the witness data can become in the worst case – i.e. what spending will cost. Bitcoin Core integrated Miniscript in stages: watch-only wallets in version 24.0 (late 2022), signing in 25.0 (May 2023), taproot descriptors in 26.0 (December 2023).
Output descriptors appear in Bitcoin Core 0.17 – wallets become fully describable for the first time.
Wuille, Poelstra and Kanjalkar present Miniscript; first reference implementation and compiler.
Bitcoin Core 24.0 understands Miniscript descriptors (watch-only); descriptor wallets have been the default since 23.0.
Bitcoin Core 25.0 signs Miniscript. Ledger ships Miniscript support in Bitcoin app 2.1.0 (February), BitBox02 follows with firmware 9.15.0 (August); Liana 1.0 launches in May as the first production Miniscript wallet.
Miniscript is added to the official BIP repository as BIP 379 (June); Blockstream Jade follows on the hardware side with firmware 1.0.30, BitBox02 adds taproot Miniscript (firmware 9.21.0).
What Policies Can Do in Practice: Recovery Instead of All-or-Nothing
Wallet maker Wizardsardine established the best-known usage pattern with Liana: a primary spending path plus time-delayed recovery paths. The waiting period runs relative to when the coins were last moved (via older(), i.e. relative timelocks): as long as the owner is active and moves their coins regularly, the fallback paths remain inert – a programmed dead man's switch, as described conceptually in our article on inheritance via timelock.
Decaying Multisig
3-of-3 today, 2-of-3 after six months of inactivity, a single key suffices after one year. Losing individual keys no longer means total loss – the policy "decays" in a controlled way towards recoverability.
Inheritance Policy
Heirs receive a key that only becomes spendable after prolonged inactivity. No lawyer, no custodian, no key copy during the owner's lifetime – the chain itself enforces the waiting period.
Corporate Treasury
Tiered authority: small amounts with one signature, large ones only with a quorum plus waiting period. Blockstream cites this as a core scenario for Miniscript on the Jade signer.
Anti-Backdoor Setup
Ledger justifies its own Miniscript support by noting that users can combine several devices from different manufacturers – a single compromised vendor then cannot steal any coins.
The Ecosystem, as of July 2026
Miniscript has outgrown its niche but is no mass phenomenon. On the hardware side, Specter-DIY (a pioneer since April 2021), Ledger (since February 2023), BitBox02 (since August 2023), Coldcard and Blockstream Jade (since 2024) support Miniscript policies – partly including taproot (Ledger since March 2024, BitBox02 since firmware 9.21.0, September 2024). BIP 388 ("Wallet Policies", by Salvatore Ingala, status "Complete") standardises how signing devices register such policies and display them intelligibly to the user; Coldcard now uses the format as its native storage format. Liana remains the reference software and is under active development; for businesses and high-net-worth individuals, Wizardsardine offers a business tier (as of July 2026: 0.016% of assets under management per month).
The Flip Side: Configuration Risk Does Not Replace Key Risk – It Adds to It
This article's core question cannot be cheered away. Timelock-based policies create a maintenance obligation: relative timelocks run per UTXO. Anyone who fails to move their coins before the deadline ("refresh") activates the recovery path – and with it, potentially, access by heirs, service providers or thieves of a recovery key while the owner is still alive and fully capable. Wizardsardine itself documents this refresh obligation as an integral part of the model.
With Miniscript wallets, the seed alone is no longer a complete backup. Without the descriptor (including all participating xpubs), the addresses cannot be reconstructed – the coins are practically unfindable despite an intact seed. The descriptor must be backed up separately and redundantly; it reveals no keys, but it does reveal the policy.
Then there is privacy: with P2WSH-based policies, the complete script lands on-chain when spending – observers see the number of keys, thresholds and deadlines. Taproot mitigates this considerably, because only the path actually used is revealed; the key path remains indistinguishable from an ordinary payment. And finally, maturity: compared with single-sig and classic multisig, exotic policies are less widely deployed, less frequently audited, and recoverable on less software. That this is no theoretical concern was demonstrated by Ledger's Bitcoin app: versions 2.1.0 and 2.1.1 produced wrong addresses for a particular Miniscript fragment (Security Bulletin 019); the bug was fixed in later versions.
| Risk | Single-sig | Miniscript policy with recovery path |
|---|---|---|
| Loss of the primary key | Total loss | Recovery path kicks in after the delay |
| Backup scope | Seed suffices | Seed(s) + descriptor mandatory |
| Ongoing maintenance | None | UTXO refresh before the deadline |
| Misconfiguration | Barely possible | Real hazard (wrong delays, wrong keys) |
| Privacy when spending | High | P2WSH: policy visible; taproot: only the used path |
Assessment
Miniscript and descriptors do not eliminate risk; they make it designable. The progress is real: what used to require hand-written, unverifiable scripts is now documented in BIPs (379, 380–386, 388), integrated into Bitcoin Core and signable on widely available hardware – the "broken script" failure class has largely been eliminated. The failure classes "forgotten maintenance" and "lost descriptor" are new additions. Whether the balance is positive depends less on the cryptography than on discipline and tooling quality: for users whose greatest risk is their own key loss or an unresolved inheritance, a well-maintained policy shifts risk structurally in the right direction – though robust loss statistics quantifying this do not yet exist. For everyone else, the old engineering rule applies: the safest complexity is the complexity you do not need.
Related
Una de las mayores causas de pérdida en Bitcoin bajo autocustodia no es un hackeo del protocolo, sino la banal pérdida de la única clave de la que depende todo. Una wallet estándar conoce exactamente una regla de gasto: quien aporte la firma correspondiente a la clave puede gastar, para siempre, sin plan B. Sin embargo, el lenguaje de scripting de Bitcoin es capaz de mucho más de lo que casi ninguna wallet aprovecha: firmas múltiples y condiciones anidadas desde el principio, timelocks a nivel de script desde los soft forks de 2015/2016 (OP_CLTV, OP_CSV). Durante años no se usó casi nada de esto, porque los scripts escritos a mano eran propensos a errores y prácticamente imposibles de analizar para el software de wallets. Dos bloques constructivos han cambiado eso: output descriptors y Miniscript.
Un descriptor es una línea de texto estandarizada que describe completamente cómo una wallet construye sus direcciones: tipo de script, claves y rutas de derivación. Miniscript es un subconjunto estructurado de Bitcoin Script dentro de dichos descriptors que el software puede verificar automáticamente en cuanto a corrección, gastabilidad y requisitos de comisión.
Del script al descriptor: las wallets se vuelven describibles
Antes de los descriptors, la pregunta «¿qué direcciones pertenecen a esta seed?» estaba sorprendentemente mal definida: cada aplicación de wallet usaba sus propias convenciones para rutas de derivación y tipos de script, un conocido problema de recuperación que tratamos en profundidad en nuestro artículo sobre HD wallets y rutas de derivación. Pieter Wuille introdujo los descriptors en 2018 con Bitcoin Core 0.17; la familia de BIPs 380 a 386, propuesta en 2021, estandarizó el lenguaje formalmente con posterioridad. Un descriptor como wpkh(xpub.../84h/0h/0h/0/*) responde a la pregunta de forma inequívoca y legible por máquina. Desde Bitcoin Core 23.0 (abril de 2022), las descriptor wallets son el estándar para las wallets recién creadas.
El punto decisivo: un descriptor es una copia de seguridad completa y portátil del plano de construcción de una wallet, no solo de sus claves. Precisamente esta propiedad es la que hace que reglas de gasto más complejas sean gestionables en absoluto.
Miniscript: Bitcoin Script, pero analizable
Miniscript fue presentado en 2019 por Pieter Wuille, Andrew Poelstra y Sanket Kanjalkar; su especificación de referencia vivió inicialmente en un sitio de proyecto propio y está documentada como BIP 379 en el repositorio oficial de BIPs desde finales de junio de 2024 (estado: borrador). La idea: en lugar de permitir Bitcoin Script arbitrario, Miniscript define un conjunto estructurado de fragmentos —verificaciones de clave, umbrales, hash locks, timelocks— que se combinan según reglas fijas. A partir de una policy legible como or(pk(A),and(pk(B),older(52560))) («clave A en cualquier momento, o clave B tras aproximadamente un año de espera»), un compilador produce de forma determinista el script correspondiente.
Dado que la estructura está formalmente definida, el software puede demostrar automáticamente tres cosas que antes requerían revisión experta de scripts escritos a mano: que el script es válido según el consenso y realmente gastable, que terceros no pueden mutar la transacción (maleabilidad), y cuán grandes pueden llegar a ser los datos del witness en el peor caso, es decir, cuánto costará el gasto. Bitcoin Core integró Miniscript de forma gradual: wallets de solo observación en la versión 24.0 (finales de 2022), firma en la 25.0 (mayo de 2023) y taproot descriptors en la 26.0 (diciembre de 2023).
Los output descriptors aparecen en Bitcoin Core 0.17: las wallets se vuelven completamente describibles por primera vez.
Wuille, Poelstra y Kanjalkar presentan Miniscript; primera implementación de referencia y compilador.
Bitcoin Core 24.0 comprende los Miniscript descriptors (watch-only); las descriptor wallets son el estándar desde la versión 23.0.
Bitcoin Core 25.0 firma Miniscript. Ledger distribuye el soporte de Miniscript en la app Bitcoin 2.1.0 (febrero); BitBox02 le sigue con el firmware 9.15.0 (agosto); Liana 1.0 se lanza en mayo como la primera wallet Miniscript en producción.
Miniscript se incorpora al repositorio oficial de BIPs como BIP 379 (junio); Blockstream Jade se suma en el lado del hardware con el firmware 1.0.30; BitBox02 añade Miniscript con Taproot (firmware 9.21.0).
Lo que las policies pueden hacer en la práctica: recuperación en lugar de todo o nada
El fabricante de wallets Wizardsardine estableció el patrón de uso más conocido con Liana: una ruta de gasto principal más rutas de recuperación con retardo temporal. El período de espera transcurre de forma relativa al último momento en que se movieron las monedas (mediante older(), es decir, timelocks relativos): mientras el propietario esté activo y mueva sus monedas con regularidad, las rutas de respaldo permanecen inactivas, un interruptor de hombre muerto programado, tal como describe conceptualmente nuestro artículo sobre herencia mediante timelock.
Multisig decreciente
3-de-3 hoy, 2-de-3 tras seis meses de inactividad, una sola clave es suficiente después de un año. Perder claves individuales ya no supone una pérdida total: la policy «decae» de forma controlada hacia la recuperabilidad.
Policy de herencia
Los herederos reciben una clave que solo se vuelve gastable tras una prolongada inactividad. Sin abogado, sin custodio, sin copia de la clave en vida del propietario: la propia cadena hace cumplir el plazo.
Tesorería corporativa
Permisos escalonados: cantidades pequeñas con una firma, las grandes solo con quórum más período de espera. Blockstream cita esto como escenario central para Miniscript en el firmador Jade.
Configuración anti-puerta trasera
Ledger justifica su propio soporte de Miniscript señalando que los usuarios pueden combinar varios dispositivos de distintos fabricantes: un único fabricante comprometido no puede robar las monedas.
El ecosistema a julio de 2026
Miniscript ha superado su nicho, pero no es un fenómeno masivo. En el lado del hardware, Specter-DIY (pionero desde abril de 2021), Ledger (desde febrero de 2023), BitBox02 (desde agosto de 2023), Coldcard y Blockstream Jade (desde 2024) admiten policies Miniscript, en parte incluyendo Taproot (Ledger desde marzo de 2024, BitBox02 desde el firmware 9.21.0, septiembre de 2024). BIP 388 («Wallet Policies», de Salvatore Ingala, estado «Complete») estandariza cómo los dispositivos firmadores registran dichas policies y las muestran de forma comprensible al usuario; Coldcard ya usa el formato como formato de almacenamiento nativo. Liana sigue siendo el software de referencia y está en desarrollo activo; para empresas y clientes privados de alto patrimonio, Wizardsardine ofrece una variante de negocio (a julio de 2026: 0,016 % de los activos gestionados al mes).
La otra cara: el riesgo de configuración no reemplaza al riesgo de clave, se suma a él
La pregunta central de este artículo no puede ignorarse. Las policies basadas en timelocks generan una obligación de mantenimiento: los timelocks relativos corren por UTXO. Quien no mueva sus monedas antes de que venza el plazo («refresh») activa la ruta de recuperación, y con ella, potencialmente, el acceso de herederos, proveedores de servicios o ladrones de una clave de recuperación mientras el propietario aún está vivo y capaz de actuar. Wizardsardine documenta esta obligación de refresh como parte integral del modelo.
Con las wallets Miniscript, la seed por sí sola ya no es una copia de seguridad completa. Sin el descriptor (incluidos todos los xpubs participantes), las direcciones no pueden reconstruirse: las monedas son prácticamente inencontrables a pesar de tener la seed intacta. El descriptor debe respaldarse por separado y de forma redundante; no revela las claves, pero sí revela la policy.
A esto se suma la privacidad: con policies basadas en P2WSH, el script completo queda registrado en la cadena al gastar, por lo que los observadores ven el número de claves, los umbrales y los plazos. Taproot mitiga esto considerablemente, ya que solo se revela la ruta realmente utilizada; la ruta de clave resulta indistinguible de un pago ordinario. Y finalmente, la madurez: en comparación con single-sig y la multisig clásica, las policies exóticas están menos extendidas, se auditan con menos frecuencia y son recuperables en menos software. Que esto no es una preocupación teórica lo demostró la app Bitcoin de Ledger: las versiones 2.1.0 y 2.1.1 generaban direcciones incorrectas para un determinado fragmento Miniscript (Security Bulletin 019); el error fue corregido en versiones posteriores.
| Riesgo | Single-sig | Policy Miniscript con ruta de recuperación |
|---|---|---|
| Pérdida de la clave principal | Pérdida total | La ruta de recuperación se activa tras el plazo |
| Alcance del backup | La seed es suficiente | Seed(s) + descriptor obligatorio |
| Mantenimiento continuo | Ninguno | Refresh del UTXO antes del vencimiento |
| Configuración incorrecta | Apenas posible | Riesgo real (plazos incorrectos, claves incorrectas) |
| Privacidad al gastar | Alta | P2WSH: policy visible; Taproot: solo la ruta utilizada |
Valoración
Miniscript y los descriptors no eliminan el riesgo; lo hacen configurable. El avance es real: lo que antes requería scripts escritos a mano e inverificables está ahora documentado en BIPs (379, 380–386, 388), integrado en Bitcoin Core y firmable en hardware de amplia disponibilidad; la clase de error «script roto» ha quedado prácticamente eliminada. Las clases de error «mantenimiento olvidado» y «descriptor perdido» son nuevas incorporaciones. Si el balance es positivo depende menos de la criptografía que de la disciplina y la calidad de las herramientas: para los usuarios cuyo mayor riesgo es la propia pérdida de claves o una herencia no resuelta, una policy bien mantenida desplaza el riesgo estructuralmente en la dirección correcta, aunque todavía no existen datos de pérdidas sólidos que lo cuantifiquen. Para todos los demás sigue vigente la vieja regla de ingeniería: la complejidad más segura es la que no se necesita.
Para profundizar
Uma das maiores causas de perda em Bitcoin autocustodiado não é um ataque ao protocolo, mas a perda banal da única chave de que tudo depende. Uma carteira padrão conhece exatamente uma regra de gasto: quem fornece a assinatura para a chave pode gastar – para sempre, sem plano B. No entanto, a linguagem de script do Bitcoin é capaz de muito mais do que quase qualquer carteira utiliza: múltiplas assinaturas e condições aninhadas desde o início, timelocks ao nível do script desde os soft forks de 2015/2016 (OP_CLTV, OP_CSV). Durante anos, quase nada disso foi utilizado, porque scripts escritos à mão eram propensos a erros e praticamente impossíveis de analisar por software de carteira. Dois elementos mudaram isso: output descriptors e Miniscript.
Um descriptor é uma linha de texto padronizada que descreve completamente como uma carteira constrói os seus endereços – tipo de script, chaves, caminhos de derivação. Miniscript é um subconjunto estruturado do Bitcoin Script dentro desses descriptors, que o software pode verificar automaticamente quanto à correção, possibilidade de gasto e requisitos de taxa.
Do Script ao Descriptor: Carteiras Tornam-se Descritíveis
Antes dos descriptors, a questão "quais endereços pertencem a esta seed?" era surpreendentemente mal definida: cada aplicação de carteira usava as suas próprias convenções para caminhos de derivação e tipos de script – um problema de recuperação bem conhecido, abordado em detalhe no nosso artigo sobre HD wallets e caminhos de derivação. Pieter Wuille introduziu os descriptors em 2018 com o Bitcoin Core 0.17; a família de BIPs 380 a 386, proposta em 2021, padronizou formalmente a linguagem mais tarde. Um descriptor como wpkh(xpub.../84h/0h/0h/0/*) responde à questão de forma inequívoca e legível por máquina. Desde o Bitcoin Core 23.0 (abril de 2022), as descriptor wallets são o padrão para carteiras recém-criadas.
O ponto decisivo: um descriptor é um backup completo e portátil do plano de construção de uma carteira – não apenas das suas chaves. É precisamente esta propriedade que torna as regras de gasto mais complexas gerenciáveis.
Miniscript: Bitcoin Script, mas Analisável
O Miniscript foi apresentado em 2019 por Pieter Wuille, Andrew Poelstra e Sanket Kanjalkar; a sua especificação de referência viveu inicialmente num site de projeto dedicado e está documentada como BIP 379 no repositório oficial de BIPs desde o final de junho de 2024 (estado: rascunho). A ideia: em vez de permitir Bitcoin Script arbitrário, o Miniscript define um conjunto de ferramentas estruturado com fragmentos – verificações de chave, limiares, hash locks, timelocks – que se combinam segundo regras fixas. A partir de uma policy legível como or(pk(A),and(pk(B),older(52560))) ("chave A a qualquer momento, ou chave B após cerca de um ano de espera"), um compilador produz deterministicamente o script correspondente.
Como a estrutura é formalmente definida, o software pode provar automaticamente três coisas que antes exigiam análise especializada de scripts escritos à mão: que o script é válido por consenso e efetivamente gastável, que terceiros não podem mutilar a transação (malleability), e o tamanho máximo que os dados witness podem atingir no pior caso – ou seja, o custo do gasto. O Bitcoin Core integrou o Miniscript de forma gradual: carteiras watch-only na versão 24.0 (final de 2022), assinatura na 25.0 (maio de 2023), taproot descriptors na 26.0 (dezembro de 2023).
Os output descriptors aparecem no Bitcoin Core 0.17 – as carteiras tornam-se completamente descritíveis pela primeira vez.
Wuille, Poelstra e Kanjalkar apresentam o Miniscript; primeira implementação de referência e compilador.
O Bitcoin Core 24.0 compreende descriptors Miniscript (watch-only); as descriptor wallets são o padrão desde a versão 23.0.
O Bitcoin Core 25.0 assina Miniscript. A Ledger lança suporte a Miniscript na Bitcoin app 2.1.0 (fevereiro), a BitBox02 segue com o firmware 9.15.0 (agosto); a Liana 1.0 é lançada em maio como a primeira carteira Miniscript em produção.
O Miniscript é adicionado ao repositório oficial de BIPs como BIP 379 (junho); a Blockstream Jade acompanha no lado do hardware com o firmware 1.0.30, a BitBox02 adiciona Taproot Miniscript (firmware 9.21.0).
O Que as Policies Podem Fazer na Prática: Recuperação em Vez de Tudo ou Nada
A fabricante de carteiras Wizardsardine estabeleceu o padrão de uso mais conhecido com a Liana: um caminho de gasto primário mais caminhos de recuperação com atraso temporal. O período de espera corre de forma relativa ao momento em que as moedas foram movidas pela última vez (via older(), ou seja, timelocks relativos): enquanto o proprietário estiver ativo e mover as suas moedas regularmente, os caminhos alternativos permanecem inativos – um dead man's switch programado, conforme descrito concetualmente no nosso artigo sobre herança via timelock.
Multisig Decrescente
3 de 3 hoje, 2 de 3 após seis meses de inatividade, uma única chave é suficiente após um ano. A perda de chaves individuais já não significa perda total – a policy "decai" de forma controlada em direção à recuperabilidade.
Policy de Herança
Os herdeiros recebem uma chave que só se torna utilizável após prolongada inatividade. Sem advogado, sem custodiante, sem cópia da chave em vida – a própria blockchain impõe o prazo.
Tesouraria Corporativa
Permissões escalonadas: valores pequenos com uma assinatura, valores grandes apenas com quórum mais período de espera. A Blockstream cita isto como cenário central para o Miniscript no Jade signer.
Configuração Anti-Backdoor
A Ledger justifica o seu suporte a Miniscript ao notar que os utilizadores podem combinar vários dispositivos de diferentes fabricantes – um único fornecedor comprometido não consegue então roubar as moedas.
O Ecossistema, a Partir de Julho de 2026
O Miniscript superou o seu nicho, mas não é um fenómeno de massas. No lado do hardware, a Specter-DIY (pioneira desde abril de 2021), a Ledger (desde fevereiro de 2023), a BitBox02 (desde agosto de 2023), a Coldcard e a Blockstream Jade (desde 2024) suportam policies Miniscript – incluindo em parte taproot (Ledger desde março de 2024, BitBox02 desde o firmware 9.21.0, setembro de 2024). O BIP 388 ("Wallet Policies", de Salvatore Ingala, estado "Complete") padroniza como os dispositivos de assinatura registam essas policies e as apresentam de forma compreensível ao utilizador; a Coldcard usa agora o formato como formato de armazenamento nativo. A Liana continua a ser o software de referência e está em desenvolvimento ativo; para empresas e clientes privados de elevado património, a Wizardsardine oferece uma variante empresarial (a partir de julho de 2026: 0,016% dos ativos sob gestão por mês).
O Lado Negativo: O Risco de Configuração Não Substitui o Risco de Chave – Acumula-se a Ele
A questão central deste artigo não pode ser ignorada. As policies baseadas em timelock criam uma obrigação de manutenção: os timelocks relativos correm por UTXO. Quem não mover as suas moedas antes do prazo ("refresh") ativa o caminho de recuperação – e com ele, potencialmente, o acesso de herdeiros, prestadores de serviços ou ladrões de uma chave de recuperação, enquanto o proprietário ainda está vivo e capaz de agir. A própria Wizardsardine documenta esta obrigação de refresh como parte integrante do modelo.
Com carteiras Miniscript, a seed por si só já não é um backup completo. Sem o descriptor (incluindo todos os xpubs participantes), os endereços não podem ser reconstruídos – as moedas são praticamente impossíveis de encontrar apesar de a seed estar intacta. O descriptor deve ser guardado separadamente e de forma redundante; não revela chaves, mas revela a policy.
Acresce a questão da privacidade: com policies baseadas em P2WSH, o script completo fica registado on-chain ao gastar – os observadores veem o número de chaves, limiares e prazos. O Taproot atenua isso consideravelmente, pois apenas o caminho efetivamente utilizado é revelado; o caminho de chave permanece indistinguível de um pagamento normal. E, por fim, a maturidade: comparadas com single-sig e multisig clássica, as policies exóticas são menos amplamente implementadas, menos frequentemente auditadas e recuperáveis em menos software. Que isto não é uma preocupação teórica foi demonstrado pela Bitcoin app da Ledger: as versões 2.1.0 e 2.1.1 produziam endereços errados para um determinado fragmento Miniscript (Security Bulletin 019); o erro foi corrigido em versões posteriores.
| Risco | Single-sig | Policy Miniscript com caminho de recuperação |
|---|---|---|
| Perda da chave principal | Perda total | Caminho de recuperação ativa-se após o prazo |
| Âmbito do backup | Seed é suficiente | Seed(s) + descriptor obrigatório |
| Manutenção contínua | Nenhuma | Refresh do UTXO antes do prazo |
| Configuração incorreta | Dificilmente possível | Risco real (prazos errados, chaves erradas) |
| Privacidade ao gastar | Alta | P2WSH: policy visível; Taproot: apenas o caminho utilizado |
Avaliação
O Miniscript e os descriptors não eliminam o risco; tornam-no configurável. O progresso é real: o que antes exigia scripts escritos à mão e não verificáveis está agora documentado em BIPs (379, 380–386, 388), integrado no Bitcoin Core e assinável em hardware amplamente disponível – a classe de falhas "script quebrado" foi amplamente eliminada. As classes de falhas "manutenção esquecida" e "descriptor perdido" são novas adições. Se o balanço é positivo depende menos da criptografia do que da disciplina e da qualidade das ferramentas: para utilizadores cujo maior risco é a perda das próprias chaves ou uma herança por resolver, uma policy bem mantida desloca o risco estruturalmente na direção certa – embora estatísticas de perdas robustas que quantifiquem isso ainda não existam. Para todos os outros, aplica-se a velha regra de engenharia: a complexidade mais segura é aquela de que não se precisa.
Leitura Adicional
自己管理するBitcoinにおける最大の損失原因は、プロトコルへのハッキングではなく、すべてが依存する一つの鍵を失うという平凡な事態です。標準的なウォレットが知る支出ルールはただ一つ：鍵に対応する署名を提供した者が永久に支出できる、というものであり、プランBは存在しません。しかしBitcoinのスクリプト言語は、ほとんどのウォレットが活用している以上の機能を持っています。多重署名やネストされた条件は当初から、スクリプトベースのタイムロックは2015/2016年のソフトフォーク（OP_CLTV、OP_CSV）以来サポートされています。それでも長年ほとんど使われませんでした。手書きのスクリプトはエラーが生じやすく、ウォレットソフトウェアによる解析が事実上不可能だったためです。この状況を変えた二つの要素が Output Descriptor と Miniscript です。
Descriptor とは、ウォレットがアドレスを生成する方法——スクリプトの種類、鍵、導出パス——を完全に記述した標準化されたテキスト行です。Miniscript は、そのようなDescriptor内のBitcoin Scriptの構造化されたサブセットであり、ソフトウェアが正確さ、支出可能性、手数料の要件を自動的に検証できます。
スクリプトからDescriptorへ：ウォレットが記述可能になる
Descriptorが登場する以前、「このシードに対応するアドレスはどれか？」という問いは驚くほど曖昧でした。各ウォレットソフトウェアが導出パスやスクリプトの種類に独自の慣習を採用していたため、復元時に問題が生じることで知られていました。この点については、HDウォレットと導出パスに関する記事で詳しく解説しています。Pieter WuilleはBitcoin Core 0.17とともに2018年にDescriptorを導入しました。2021年に提案されたBIP 380〜386のファミリーが、後にこの仕様を正式に標準化しました。wpkh(xpub.../84h/0h/0h/0/*) のようなDescriptorは、この問いに対して明確かつ機械可読な形で答えます。Bitcoin Core 23.0（2022年4月）以降、Descriptor型ウォレットは新規作成されるウォレットの標準となっています。
重要な点は、Descriptorがウォレットの構成手順の完全かつポータブルなバックアップであり、鍵だけを保存するものではないということです。まさにこの性質によって、より複雑な支出ルールを初めて管理可能なものにしています。
Miniscript：解析可能なBitcoin Script
Miniscriptは2019年にPieter Wuille、Andrew Poelstra、Sanket Kanjalkarによって発表されました。リファレンス仕様は当初、独自のプロジェクトページで公開されており、2024年6月末以降は公式BIPリポジトリにBIP 379として収録されています（ステータス：Draft）。基本的なアイデアは、任意のBitcoin Scriptを許可する代わりに、Miniscriptが鍵チェック、閾値、ハッシュロック、タイムロックといったフラグメントからなる構造化されたビルディングブロックを定義し、それらを固定ルールに従って組み合わせられるようにするというものです。or(pk(A),and(pk(B),older(52560)))（「鍵Aはいつでも、または鍵Bは約1年の待機後に」）のような読みやすいポリシーから、コンパイラが対応するスクリプトを決定論的に生成します。
構造が形式的に定義されているため、ソフトウェアは手書きスクリプトでは専門家の作業を要した三つのことを自動的に証明できます。スクリプトがコンセンサス上有効かつ実際に支出可能であること、第三者がトランザクションを改ざんできないこと（マリアビリティ）、そして最悪のケースでwitnessデータがどれほど大きくなるか——つまり支出にかかるコストです。Bitcoin CoreはMiniscriptを段階的に統合しました：バージョン24.0（2022年末）で監視専用ウォレット、25.0（2023年5月）で署名、26.0（2023年12月）でTaproot Descriptorに対応しました。
Output DescriptorがBitcoin Core 0.17に登場——ウォレットが初めて完全に記述可能になる。
Wuille、Poelstra、KanjalkarがMiniscriptを発表。最初のリファレンス実装とコンパイラが公開される。
Bitcoin Core 24.0がMiniscript Descriptor（watch-only）に対応。Descriptor型ウォレットは23.0以降の標準となる。
Bitcoin Core 25.0がMiniscriptの署名に対応。LedgerはBitcoin App 2.1.0でMiniscriptサポートを提供（2月）、BitBox02はFirmware 9.15.0で続く（8月）。LianaはMiniscriptを採用した最初の実用ウォレットとして5月にバージョン1.0をリリース。
Miniscriptが公式BIPリポジトリにBIP 379として収録される（6月）。Blockstream JadeはFirmware 1.0.30でハードウェア対応に追随。BitBox02はTaproot Miniscriptを追加（Firmware 9.21.0）。
ポリシーの実用的な可能性：全か無かに代わるリカバリー
ウォレットメーカーのWizardsardineは Liana によって最もよく知られたユースケースを確立しました。プライマリの支出パスに加えて、時間遅延付きのリカバリーパスを持つ構成です。待機期間はコインの最終支出時点から相対的に計測されます（older()、つまり相対タイムロックを使用）。所有者がアクティブで定期的にコインを動かしている限り、バックアップパスは機能しません——これはデッドマンズスイッチをプログラム化したものであり、タイムロックによる相続に関する記事でコンセプトとして解説しています。
減衰するマルチシグ
最初は3-of-3、6ヶ月の非活動後は2-of-3、1年後は1つの鍵で足りる。個々の鍵を失っても全損にはならない——ポリシーは制御されながら「減衰」し、リカバリー可能性が高まっていく。
相続ポリシー
相続人は鍵を受け取るが、長期間の非活動後にのみ支出可能となる。弁護士も、保管サービスも、生前の鍵コピーも不要——ブロックチェーン自体が期限を執行する。
企業トレジャリー
段階的な権限設定：少額は単一署名で、大額はクォーラムと待機時間が必要。Blockstreamはこれをフォン Jade SignerにおけるMiniscriptの主要ユースケースとして挙げている。
バックドア対策セットアップ
Ledgerが自社のMiniscriptサポートの根拠として挙げるのは、ユーザーが異なるメーカーの複数デバイスを組み合わせられるという点。単一のメーカーが侵害されても、コインを盗まれない。
エコシステムの現状（2026年7月時点）
Miniscriptはニッチな存在を脱しましたが、まだ大衆的な現象とは言えません。ハードウェア側では、Specter-DIY（2021年4月からのパイオニア）、Ledger（2023年2月以降）、BitBox02（2023年8月以降）、Coldcard、Blockstream Jade（2024年以降）がMiniscriptポリシーをサポートしています——一部はTaprootにも対応しています（Ledgerは2024年3月以降、BitBox02はFirmware 9.21.0以降、2024年9月）。BIP 388（Salvatore Ingalaによる「Wallet Policies」、ステータス「Complete」）は、署名デバイスがそのようなポリシーを登録しユーザーに分かりやすく表示する方法を標準化しています。Coldcardはすでにこのフォーマットをネイティブの保存形式として使用しています。Lianaはリファレンスソフトウェアとして活発に開発が続けられており、Wizardsardineは法人や富裕層の個人顧客向けにビジネス版も提供しています（2026年7月時点：運用資産の月0.016%）。
デメリット：設定リスクは鍵リスクを置き換えるのではなく、追加される
この記事の核心的な問いは無視できません。タイムロックベースのポリシーはメンテナンスの義務を生み出します。相対タイムロックはUTXOごとに進行します。期限前にコインを動かさない（「更新」しない）と、リカバリーパスがアクティブになります——つまり、所有者がまだ存命で行動能力があるにもかかわらず、相続人、サービスプロバイダー、またはリカバリー鍵を盗んだ者がアクセスできる可能性があります。Wizardsardineはこの更新義務をモデルの不可欠な構成要素として自ら文書化しています。
Miniscriptウォレットでは、シードだけでは完全なバックアップとはなりません。Descriptor（関連するすべてのxpubを含む）がなければ、アドレスを再構築することができません——シードが無事でもコインは事実上見つけられません。Descriptorは別途かつ冗長に保存する必要があります。Descriptorは鍵を開示しませんが、ポリシーは開示します。
プライバシーの問題もあります。P2WSHベースのポリシーでは、支出時に完全なスクリプトがオンチェーンに記録されます——観察者は鍵の数、閾値、期限を確認できます。Taprootはこれを大幅に改善します。実際に使用されたパスのみが開示され、鍵パスは通常の支払いと区別がつきません。そして成熟度の問題もあります。Single-Sigや従来のマルチシグと比べて、エキゾチックなポリシーは使用例が少なく、監査も少なく、復元できるソフトウェアも限られています。これが単なる理論上の懸念ではないことは、LedgerのBitcoin Appが示しています。バージョン2.1.0と2.1.1は、特定のMiniscriptフラグメントで誤ったアドレスを生成していました（Security Bulletin 019）。このバグは後のバージョンで修正されています。
| リスク | Single-Sig | リカバリーパス付きMiniscriptポリシー |
|---|---|---|
| 主鍵の紛失 | 全損 | 期限後にリカバリーパスが機能 |
| バックアップの範囲 | シードで十分 | シード(複数可) + Descriptor必須 |
| 継続的なメンテナンス | 不要 | 期限前のUTXO更新が必要 |
| 設定ミス | ほぼ不可能 | 現実のリスク（誤った期限、誤った鍵） |
| 支出時のプライバシー | 高い | P2WSH：ポリシーが公開；Taproot：使用パスのみ |
評価
MiniscriptとDescriptorはリスクを排除するのではなく、形成可能にします。進歩は現実のものです。以前は手書きの検証不可能なスクリプトが必要だったものが、今日ではBIPに文書化され（379、380〜386、388）、Bitcoin Coreに統合され、普及したハードウェアで署名可能です——「壊れたスクリプト」というエラークラスはほぼ排除されました。一方で「忘れられたメンテナンス」と「紛失したDescriptor」という新たなエラークラスが加わりました。この収支がプラスかどうかは、暗号技術よりも規律とツールの品質に依存します。最大のリスクが自分自身の鍵紛失や未解決の相続問題であるユーザーにとって、適切にメンテナンスされたポリシーはリスクを構造的に正しい方向にシフトさせます——ただし、それを数値化できる確かな損失データはまだ存在しません。それ以外のすべての人には、古いエンジニアリングの格言が当てはまります：最も安全な複雑さとは、必要としない複雑さです。
関連記事
自托管 Bitcoin 最大的损失原因之一，并非协议遭到攻击，而是平淡无奇地丢失了那把牵一发而动全身的私钥。标准钱包只认一条支出规则：谁能提供对应密钥的签名，谁就可以永久支出——没有任何备用方案。然而，Bitcoin 的脚本语言所能实现的远不止于此，几乎所有钱包都未加以利用：多重签名与嵌套条件从一开始便已具备，脚本层面的时间锁也自 2015/2016 年软分叉（OP_CLTV、OP_CSV）起便已存在。多年来几乎无人使用，原因在于手写脚本容易出错，且钱包软件几乎无法对其进行分析。两个基础组件改变了这一局面：Output Descriptors 与 Miniscript。
Descriptor 是一行标准化文本，完整描述钱包如何构建其地址——包括脚本类型、密钥及派生路径。Miniscript 是此类 descriptor 内部 Bitcoin Script 的一个结构化子集，软件可自动对其进行正确性、可花费性及手续费需求的验证。
从脚本到 Descriptor：钱包变得可描述
在 descriptor 出现之前，"哪些地址属于这个 seed？"这一问题出乎意料地难以明确回答：每款钱包软件都有各自的派生路径与脚本类型约定——这是一个广为人知的恢复难题，我们在关于 HD 钱包与派生路径的文章中有详细介绍。Pieter Wuille 于 2018 年在 Bitcoin Core 0.17 中引入了 descriptor；2021 年提出的 BIP 380 至 386 系列后来对这一语言进行了正式标准化。形如 wpkh(xpub.../84h/0h/0h/0/*) 的 descriptor 能够以机器可读的方式明确回答上述问题。自 Bitcoin Core 23.0（2022 年 4 月）起，descriptor 钱包已成为新建钱包的默认类型。
关键所在：descriptor 是钱包构建蓝图的完整可移植备份——而不仅仅是密钥本身。正是这一特性，使得管理更复杂的支出规则成为可能。
Miniscript：可分析的 Bitcoin Script
Miniscript 由 Pieter Wuille、Andrew Poelstra 和 Sanket Kanjalkar 于 2019 年发布；其参考规范最初发布在一个独立的项目页面上，自 2024 年 6 月下旬起已作为 BIP 379 收录于官方 BIP 仓库（状态：草案）。其核心思路是：与其允许任意的 Bitcoin Script，不如由 Miniscript 定义一套由片段组成的结构化工具箱——密钥检查、阈值、哈希锁、时间锁——各片段可依照固定规则组合。由编译器从形如 or(pk(A),and(pk(B),older(52560)))（"密钥 A 随时可用，或密钥 B 在等待约一年后可用"）这样的可读 policy 出发，确定性地生成对应脚本。
由于结构经过正式定义，软件可自动证明三件过去需要专家人工审核手写脚本才能确认的事情：脚本是否符合共识规则且实际可花费、第三方是否无法篡改交易（可塑性），以及最坏情况下见证数据的大小——即支出所需的费用。Bitcoin Core 分阶段集成了 Miniscript：24.0 版本（2022 年底）支持只读钱包，25.0（2023 年 5 月）支持签名，26.0（2023 年 12 月）支持 Taproot descriptor。
Output descriptor 出现于 Bitcoin Core 0.17——钱包首次实现完整可描述性。
Wuille、Poelstra 与 Kanjalkar 发布 Miniscript；第一个参考实现与编译器问世。
Bitcoin Core 24.0 支持 Miniscript descriptor（只读模式）；自 23.0 起 descriptor 钱包已成默认。
Bitcoin Core 25.0 支持 Miniscript 签名。Ledger 于 Bitcoin App 2.1.0（2 月）中推出 Miniscript 支持，BitBox02 随后以固件 9.15.0（8 月）跟进；Liana 1.0 于 5 月发布，成为首款投入生产的 Miniscript 钱包。
Miniscript 以 BIP 379 正式收录官方 BIP 仓库（6 月）；Blockstream Jade 以固件 1.0.30 在硬件侧跟进，BitBox02 新增 Taproot Miniscript 支持（固件 9.21.0）。
Policy 的实际用途：恢复机制取代非此即彼
钱包厂商 Wizardsardine 以 Liana 确立了最广为人知的应用模式：一条主要支出路径，加上延时恢复路径。等待期相对于币最后一次移动的时间起算（通过 older()，即相对时间锁）：只要持有人保持活跃并定期移动其币，备用路径便始终处于休眠状态——这是一种程序化的"死人开关"，我们在关于通过时间锁实现继承的文章中从概念层面进行了阐述。
衰减式多签
今日为 3 of 3，六个月无活动后降为 2 of 3，一年后单个密钥即可支出。单个密钥的丢失不再导致全部损失——policy 以受控方式向可恢复性"衰减"。
继承 Policy
继承人持有一把密钥，该密钥仅在长期无活动后方可使用。无需律师、无需托管人、持有人在世期间无需任何密钥副本——区块链本身执行等待期。
企业金库
分级权限：小额支出只需一个签名，大额支出则需法定人数加等待期。Blockstream 将此列为 Jade 签名器上 Miniscript 的核心应用场景。
防后门配置
Ledger 将自身支持 Miniscript 的理由归结为：用户可组合多家厂商的设备——单个被攻陷的厂商便无法盗取任何币。
生态系统现状（截至 2026 年 7 月）
Miniscript 已走出小众圈子，但尚未成为大众现象。硬件方面，Specter-DIY（自 2021 年 4 月起率先支持）、Ledger（自 2023 年 2 月起）、BitBox02（自 2023 年 8 月起）、Coldcard 以及 Blockstream Jade（自 2024 年起）均支持 Miniscript policy——部分还包括 Taproot（Ledger 自 2024 年 3 月起，BitBox02 自固件 9.21.0 即 2024 年 9 月起）。BIP 388（"Wallet Policies"，由 Salvatore Ingala 撰写，状态"Complete"）规范了签名设备如何注册此类 policy 并以用户易于理解的方式展示；Coldcard 现已将该格式作为原生存储格式。Liana 仍是参考软件并持续活跃开发；针对企业和高净值个人客户，Wizardsardine 提供商业版本（截至 2026 年 7 月：每月收取管理资产的 0.016%）。
另一面：配置风险不会取代密钥风险——而是叠加其上
本文的核心问题无法被回避。基于时间锁的 policy 产生了一种维护义务：相对时间锁以每个 UTXO 为单位计算。若持有人未能在期限到来前移动其币（"刷新"），便会激活恢复路径——进而可能在持有人尚在世且具有完全行为能力时，向继承人、服务商或恢复密钥的盗窃者开放访问权限。Wizardsardine 自身也将这一刷新义务记录为其模型的组成部分。
对于 Miniscript 钱包而言，仅凭 seed 不再构成完整备份。若缺少 descriptor（包括所有参与方的 xpub），地址将无法重建——即便 seed 完好无损，币也实际上无从找回。descriptor 必须单独且冗余地进行备份；它不泄露密钥，但会揭示 policy 内容。
此外还涉及隐私问题：使用基于 P2WSH 的 policy 时，完整脚本会在支出时上链——观察者可以看到密钥数量、阈值和期限。Taproot 在很大程度上缓解了这一问题，因为仅有实际使用的路径会被公开；密钥路径与普通支付无法区分。最后是成熟度问题：与单签和经典多签相比，复杂 policy 的部署范围更窄，接受审计的频次更低，且可恢复的软件更少。Ledger 的 Bitcoin App 已证明这绝非理论上的担忧：2.1.0 和 2.1.1 版本在特定 Miniscript 片段下会生成错误地址（安全公告 019）；该问题已在后续版本中修复。
| 风险 | 单签 | 带恢复路径的 Miniscript Policy |
|---|---|---|
| 主密钥丢失 | 全部损失 | 到期后恢复路径生效 |
| 备份范围 | Seed 即可 | Seed + Descriptor 缺一不可 |
| 持续维护 | 无需 | 期限前需刷新 UTXO |
| 错误配置 | 几乎不可能 | 实际风险（期限错误、密钥错误） |
| 支出时的隐私 | 高 | P2WSH：policy 可见；Taproot：仅公开已用路径 |
总结
Miniscript 与 descriptor 并不消除风险，而是使风险可设计。进步是真实存在的：过去需要手写、无法验证的脚本，如今已在 BIP（379、380–386、388）中有所记录，集成于 Bitcoin Core，并可在主流硬件上签名——"脚本损坏"这一错误类型已基本消除。与此同时，"忘记维护"和"丢失 descriptor"这两类新的错误也随之出现。最终的得失是否正面，与其说取决于密码学，不如说取决于纪律和工具质量：对于那些最大风险在于自身密钥丢失或继承问题悬而未决的用户而言，一个维护得当的 policy 能够在结构上将风险引向正确的方向——尽管目前尚无可量化这一效果的可靠损失数据。对于其他所有人，那条古老的工程法则依然适用：最安全的复杂性，是你根本不需要的那种复杂性。
延伸阅读
من أبرز أسباب خسارة Bitcoin في حالة الحضانة الذاتية ليس اختراق البروتوكول، بل الضياع البسيط للمفتاح الوحيد الذي يتوقف عليه كل شيء. تعرف المحفظة الاعتيادية قاعدة إنفاق واحدة فحسب: من يقدّم التوقيع المقابل للمفتاح يحق له الإنفاق — إلى الأبد، دون خطة بديلة. غير أن لغة السكريبت في Bitcoin تتقن أكثر مما تستغله معظم المحافظ: التوقيعات المتعددة والشروط المتداخلة منذ البداية، والأقفال الزمنية المستندة إلى السكريبت منذ الـ Soft Forks عامَي 2015/2016 (OP_CLTV، OP_CSV). ظلّت هذه الإمكانات مهجورة لسنوات؛ إذ كانت السكريبتات المكتوبة يدوياً عرضة للأخطاء ويكاد يستحيل تحليلها ببرامج المحافظ. وقد غيّر ذلك مكوّنان اثنان: Output Descriptors وMiniscript.
Descriptor هو سطر نصي موحَّد يصف بشكل كامل كيفية اشتقاق المحفظة لعناوينها — نوع السكريبت والمفاتيح ومسارات الاشتقاق. أما Miniscript فهو مجموعة فرعية منظَّمة من Bitcoin Script ضمن هذه الـ Descriptors، تتيح للبرامج التحقق تلقائياً من الصحة وقابلية الإنفاق ومتطلبات الرسوم.
من السكريبت إلى الـ Descriptor: المحافظ تصبح قابلة للوصف
قبل الـ Descriptors، كان سؤال "أي عناوين تنتمي إلى هذا الـ Seed؟" يفتقر بشكل مثير للدهشة إلى إجابة محددة: إذ اتبعت كل برامج المحافظ اصطلاحاتها الخاصة لمسارات الاشتقاق وأنواع السكريبت — وهو إشكال استرداد معروف نتناوله بالتفصيل في مقال HD Wallets ومسارات الاشتقاق. أدخل Pieter Wuille الـ Descriptors عام 2018 مع Bitcoin Core 0.17، ثم جاءت عائلة BIPs من 380 إلى 386 المقترَحة عام 2021 لتوحيد اللغة رسمياً. فالـ Descriptor من قبيل wpkh(xpub.../84h/0h/0h/0/*) يجيب على السؤال بصورة لا لبس فيها وبشكل قابل للقراءة آلياً. ومنذ Bitcoin Core 23.0 (أبريل 2022) باتت Descriptor Wallets هي المعيار للمحافظ المنشأة حديثاً.
النقطة الجوهرية: الـ Descriptor هو نسخة احتياطية كاملة ومحمولة لـدليل بناء المحفظة — لا للمفاتيح وحدها. وهذه الخاصية بالذات هي ما يجعل قواعد الإنفاق الأكثر تعقيداً قابلة للإدارة أصلاً.
Miniscript: Bitcoin Script، لكن قابل للتحليل
قدّم Pieter Wuille وAndrew Poelstra وSanket Kanjalkar الـ Miniscript عام 2019؛ عاشت المواصفة المرجعية في البداية على صفحة مشروع مستقلة، وتوثّقت منذ أواخر يونيو 2024 في فهرس BIP الرسمي بوصفها BIP 379 (الحالة: مسوّدة). الفكرة: بدلاً من السماح بـBitcoin Script العشوائي، يعرّف Miniscript مجموعة بناء منظَّمة من الأجزاء — التحقق من المفاتيح والحدود الدنيا وأقفال الهاش والأقفال الزمنية — يمكن تركيبها وفق قواعد ثابتة. من policy مقروءة كـor(pk(A),and(pk(B),older(52560))) ("المفتاح A في أي وقت، أو المفتاح B بعد انتظار نحو عام") يولّد المترجم البرمجي السكريبت المقابل بصورة حتمية.
لأن البنية محددة رسمياً، يمكن للبرامج إثبات ثلاثة أشياء تلقائياً كانت تستلزم خبرة متخصصة في السكريبتات المكتوبة يدوياً: صحة السكريبت بالإجماع وإمكانية إنفاقه فعلاً، وعدم قابلية تشويه المعاملة (Malleability)، وحجم بيانات الـ Witness في أسوأ الأحوال — أي تكلفة الإنفاق. دمج Bitcoin Core الـ Miniscript تدريجياً: المحافظ المراقبة في الإصدار 24.0 (أواخر 2022)، والتوقيع في 25.0 (مايو 2023)، وـ Taproot Descriptors في 26.0 (ديسمبر 2023).
تظهر Output Descriptors في Bitcoin Core 0.17 — تصبح المحافظ قابلة للوصف الكامل للمرة الأولى.
يقدّم Wuille وPoelstra وKanjalkar الـ Miniscript؛ أول تطبيق مرجعي ومترجم برمجي.
يفهم Bitcoin Core 24.0 الـ Miniscript Descriptors (watch-only)؛ Descriptor Wallets أصبحت المعيار منذ 23.0.
يوقّع Bitcoin Core 25.0 باستخدام Miniscript. يطرح Ledger دعم Miniscript في Bitcoin App 2.1.0 (فبراير)، ويلحق BitBox02 بالفيرموير 9.15.0 (أغسطس)؛ يصدر Liana 1.0 في مايو بوصفه أول محفظة Miniscript إنتاجية.
يُدرَج Miniscript في فهرس BIP الرسمي بوصفه BIP 379 (يونيو)؛ يلحق Blockstream Jade بالجانب المادي مع الفيرموير 1.0.30، ويضيف BitBox02 دعم Taproot Miniscript (الفيرموير 9.21.0).
ما تستطيع الـ Policies عملياً: الاسترداد بديلاً عن الكل أو لا شيء
أرسى مصنّع المحافظ Wizardsardine بمنتجه Liana النمط التطبيقي الأبرز: مسار إنفاق أساسي إضافة إلى مسارات استرداد مؤجّلة زمنياً. تسري مهلة الانتظار نسبياً إلى آخر وقت إنفاق للعملات (عبر older()، أي الأقفال الزمنية النسبية): ما دام المالك نشطاً ويحرّك عملاته بانتظام، تظل مسارات الاستبدال معطّلة — وهو مفتاح رجل ميت مبرمَج، كما يصفه مفهومياً مقالنا عن الإرث عبر Timelock.
Multisig المتلاشية
اليوم 3-من-3، وبعد ستة أشهر من الخمول 2-من-3، وبعد عام يكفي مفتاح واحد. لم يعد فقدان مفاتيح بعينها يفضي إلى خسارة كاملة — إذ "تتلاشى" الـ Policy بصورة منضبطة نحو قابلية الاسترداد.
Policy الإرث
يحصل الورثة على مفتاح لا يصبح قابلاً للإنفاق إلا بعد خمول طويل. لا محامٍ، لا وصيّ، ولا نسخة من المفتاح في حياة المالك — البلوكتشين نفسه يفرض المهلة.
خزينة الشركات
صلاحيات متدرّجة: مبالغ صغيرة بتوقيع واحد، وكبيرة فقط بنصاب قانوني مع وقت انتظار. تذكر Blockstream هذا سيناريو جوهرياً لـ Miniscript على Jade Signer.
إعداد مضاد للباب الخلفي
تبرّر Ledger دعمها للـ Miniscript بأنه يتيح للمستخدمين الجمع بين أجهزة من مصنّعين متعددين — فمصنّع واحد مخترَق لا يستطيع حينئذٍ سرقة العملات.
حالة النظام البيئي، يوليو 2026
تجاوز Miniscript مرحلة المنافذ المتخصصة، لكنه لم يصبح ظاهرة جماهيرية. على صعيد الأجهزة، يدعم Specter-DIY (رائداً منذ أبريل 2021) وLedger (منذ فبراير 2023) وBitBox02 (منذ أغسطس 2023) وColdcard وBlockstream Jade (منذ 2024) سياسات Miniscript — بما يشمل أحياناً Taproot (Ledger منذ مارس 2024، وBitBox02 منذ الفيرموير 9.21.0، سبتمبر 2024). يوحّد BIP 388 ("Wallet Policies" من Salvatore Ingala، الحالة: "Complete") طريقة تسجيل أجهزة التوقيع لهذه الـ Policies وعرضها بشكل مفهوم للمستخدم؛ ويستخدم Coldcard الصيغة الآن تنسيقاً للتخزين الأصلي. يظل Liana المرجع البرمجي ويُطوَّر بنشاط؛ وتقدّم Wizardsardine للشركات والأفراد ذوي الثروات نسخة تجارية (يوليو 2026: 0.016% من الأصول المُدارة شهرياً).
الجانب السلبي: مخاطر الإعداد لا تحلّ محل مخاطر المفاتيح — بل تُضاف إليها
لا يمكن تجاهل السؤال المحوري لهذا المقال. تُفرز الـ Policies القائمة على الـ Timelock التزام صيانة: تسري الأقفال الزمنية النسبية بحسب كل UTXO. من لا يحرّك عملاته قبل انتهاء المهلة ("Refresh") يُفعّل مسار الاسترداد — ومن ثَمّ يمنح الوصول المحتمَل للورثة أو مزودي الخدمات أو من يسرق مفتاح الاسترداد، في حين يكون المالك لا يزال حياً وقادراً على التصرف. توثّق Wizardsardine هذا الالتزام بالتحديث المنتظم بوصفه ركيزة لا غنى عنها في النموذج.
في محافظ Miniscript، لم يعد الـ Seed وحده نسخة احتياطية كاملة. دون الـ Descriptor (بما يشمل جميع الـ xpubs المشاركة) يتعذّر إعادة بناء العناوين — فالعملات غير قابلة للعثور عليها عملياً رغم سلامة الـ Seed. يجب حفظ الـ Descriptor بشكل منفصل وبنسخ متعددة؛ فهو لا يكشف المفاتيح، لكنه يكشف الـ Policy.
يُضاف إلى ذلك الخصوصية: في الـ Policies المستندة إلى P2WSH، يُسجَّل السكريبت الكامل على السلسلة عند الإنفاق — فيرى المراقبون عدد المفاتيح والحدود الدنيا والمهل. يُخفّف Taproot ذلك بشكل ملحوظ، إذ لا يُكشَف إلا المسار المستخدم فعلاً؛ ولا يمكن تمييز مسار المفتاح عن دفعة عادية. وأخيراً، النضج: مقارنةً بالتوقيع المفرد وـMultisig الكلاسيكي، تُوظَّف الـ Policies الغريبة بشكل أقل، وتخضع لمراجعات أقل، ويمكن استردادها على برامج أقل. وقد أثبت Ledger Bitcoin App أن هذا القلق ليس نظرياً: إذ ولّد الإصداران 2.1.0 و2.1.1 عناوين خاطئة لجزء Miniscript معين (Security Bulletin 019)، وأُصلح الخطأ في إصدارات لاحقة.
| المخاطرة | Single-Sig | Miniscript Policy مع مسار استرداد |
|---|---|---|
| فقدان المفتاح الرئيسي | خسارة كاملة | مسار الاسترداد يعمل بعد المهلة |
| نطاق النسخ الاحتياطية | الـ Seed يكفي | الـ Seed(s) + الـ Descriptor إلزامياً |
| الصيانة الدورية | لا شيء | تحديث الـ UTXO قبل انتهاء المهلة |
| سوء الإعداد | نادر الحدوث | خطر حقيقي (مهل خاطئة، مفاتيح خاطئة) |
| الخصوصية عند الإنفاق | عالية | P2WSH: الـ Policy مرئية؛ Taproot: المسار المستخدم فقط |
تقييم
لا يُزيل Miniscript والـ Descriptors المخاطر، بل يجعلانها قابلة للتشكيل. التقدم حقيقي: ما كان يستلزم سابقاً سكريبتات مكتوبة يدوياً غير قابلة للتحقق، بات اليوم موثَّقاً في BIPs (379، 380–386، 388)، ومدمجاً في Bitcoin Core وقابلاً للتوقيع على الأجهزة الشائعة — وقد أُزيلت إلى حد بعيد فئة الأخطاء "السكريبت المعطوب". وقد أُضيفت فئتا الأخطاء "الصيانة المنسية" و"الـ Descriptor المفقود". هل يكون الميزان إيجابياً يعتمد اعتماداً أقل على التشفير وأكثر على الانضباط وجودة الأدوات: بالنسبة للمستخدمين الذين يشكّل فقدان المفتاح أو قضية الإرث غير المحسومة خطرهم الأكبر، تُعيد سياسة مُصانة جيداً هيكلة المخاطر في الاتجاه الصحيح — غير أن بيانات الخسارة الموثوقة التي تُقدّر هذا لم تُجمَع بعد. وللجميع الآخرين، تسري قاعدة المهندسين القديمة: أأمن التعقيد هو ذلك الذي لا تحتاجه.
للاستزادة
⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة
Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Timelock-Policies eliminieren das Risiko nicht, sie tauschen es: An die Stelle des Schlüsselverlusts tritt eine dauerhafte Wartungspflicht. Wer den UTXO-Refresh vor Fristablauf versäumt – durch Krankheit, Haft, Vergessen –, aktiviert den Recovery-Pfad zu Lebzeiten und macht Erben oder Diebe eines Recovery-Schlüssels ausgabefähig.Timelock policies do not eliminate risk, they trade it: key loss is replaced by a permanent maintenance obligation. Anyone who misses the UTXO refresh before the deadline – through illness, detention, forgetfulness – activates the recovery path during their lifetime and makes heirs or thieves of a recovery key able to spend.Las políticas de timelock no eliminan el riesgo, sino que lo intercambian: la pérdida de claves es sustituida por una obligación de mantenimiento permanente. Quien no renueve el UTXO antes del plazo —por enfermedad, detención o descuido— activa la ruta de recuperación en vida, lo que permite gastar los fondos a los herederos o a quien robe la clave de recuperación.As políticas de timelock não eliminam o risco, apenas o trocam: a perda de chaves é substituída por uma obrigação de manutenção permanente. Quem não realizar a renovação do UTXO antes do prazo — por doença, detenção ou esquecimento — ativa o caminho de recuperação ainda em vida, tornando herdeiros ou ladrões de uma chave de recuperação capazes de gastar os fundos.Timelockポリシーはリスクをなくすのではなく、リスクを別の形に置き換えるだけだ。鍵の紛失リスクの代わりに、永続的なメンテナンス義務が生じる。病気、拘禁、忘却などの理由で期限前にUTXOのリフレッシュを怠れば、生存中にリカバリーパスが有効化され、リカバリー鍵を持つ相続人や盗人が資金を使えるようになってしまう。Timelock策略并不能消除风险，而是将风险转移：密钥丢失的风险被一项永久性的维护义务所取代。任何人若因疾病、拘禁或遗忘而错过截止日期前的UTXO刷新，就会在有生之年激活恢复路径，使恢复密钥的继承人或盗窃者获得动用资金的能力。لا تُلغي سياسات التايملوك المخاطر، بل تستبدلها: يحلّ محلّ خطر فقدان المفاتيح التزامٌ دائم بالصيانة. فمن يُفوّت تحديث UTXO قبل انتهاء المهلة — بسبب مرض أو احتجاز أو نسيان — يُفعّل مسار الاسترداد وهو لا يزال على قيد الحياة، مما يُمكّن الورثةَ أو سارقي مفتاح الاسترداد من إنفاق الأموال.
Belegt: Die Refresh-Pflicht ist kein Einwand von außen, sondern von Wizardsardine selbst als integraler Bestandteil des Modells dokumentiert (Inheritance-Planning-Blog, März 2023); Liana baut deshalb Erinnerungs- und Refresh-Mechanismen ein. Die Abwägung bleibt dennoch asymmetrisch: Ein versäumter Refresh führt nicht zwangsläufig zum Verlust (der Besitzer kann weiterhin ausgeben, der Recovery-Schlüssel muss zusätzlich kompromittiert oder böswillig sein), während Schlüsselverlust bei Single-Sig immer Totalverlust bedeutet. Das Risiko wird also real verschoben und verkleinert, aber nicht beseitigt – die Gegenthese trifft in ihrem Kern zu.Substantiated: the refresh obligation is not an outside objection but documented by Wizardsardine itself as integral to the model (inheritance planning blog, March 2023); Liana builds in reminder and refresh mechanisms for this reason. The trade-off remains asymmetric, however: a missed refresh does not automatically mean loss (the owner can still spend; the recovery key must additionally be compromised or malicious), whereas key loss under single-sig always means total loss. Risk is genuinely shifted and reduced, but not removed – the objection is correct at its core.Confirmado: la obligación de refresh no es una objeción externa, sino que está documentada por el propio Wizardsardine como parte integral del modelo (blog de planificación de herencia, marzo de 2023); por eso Liana incorpora mecanismos de recordatorio y de refresh. Sin embargo, la compensación sigue siendo asimétrica: un refresh omitido no implica automáticamente una pérdida (el propietario puede seguir gastando; la clave de recuperación debe además estar comprometida o ser maliciosa), mientras que la pérdida de clave en single-sig siempre supone una pérdida total. El riesgo se desplaza y reduce de forma real, pero no desaparece — la objeción es correcta en su núcleo.Confirmado: a obrigação de refresh não é uma objeção externa, mas documentada pela própria Wizardsardine como parte integrante do modelo (blog de planejamento de herança, março de 2023); por isso, o Liana incorpora mecanismos de lembrete e de refresh. No entanto, a compensação continua assimétrica: um refresh não realizado não implica automaticamente perda (o proprietário ainda pode gastar; a chave de recuperação precisa adicionalmente ser comprometida ou maliciosa), ao passo que a perda de chave em single-sig sempre significa perda total. O risco é genuinamente deslocado e reduzido, mas não eliminado — a objeção está correta em sua essência.実証済み：refreshの義務は外部からの異論ではなく、Wizardsardine自身がモデルの不可欠な要素として文書化している（相続計画ブログ、2023年3月）。そのためLianaはリマインダーとrefreshの仕組みを組み込んでいる。ただし、トレードオフは依然として非対称である。refreshを怠っても自動的に損失につながるわけではない（所有者は引き続き資金を使用でき、リカバリー鍵が加えて漏洩または悪用される必要がある）。一方、single-sigでの鍵紛失は常に全損を意味する。リスクは確かに移転・軽減されるが、完全には排除されない――この異論はその核心において正しい。已证实：refresh义务并非来自外部的质疑，而是由Wizardsardine自身记录为模型不可或缺的组成部分（继承规划博客，2023年3月）；因此Liana内置了提醒和refresh机制。然而，这一权衡仍然是不对称的：错过refresh并不自动意味着损失（所有者仍可正常使用资金，恢复密钥还必须被额外泄露或被恶意利用），而single-sig下的密钥丢失则始终意味着全额损失。风险确实得到了转移和降低，但并未被消除——这一质疑在其核心上是正确的。ثابت بالدليل: إن التزام التحديث (refresh) ليس اعتراضاً خارجياً، بل وثّقته Wizardsardine نفسها باعتباره جزءاً لا يتجزأ من النموذج (مدونة تخطيط الميراث، مارس 2023)؛ ولهذا يدمج Liana آليات تذكير وتحديث. غير أن المقايضة تبقى غير متكافئة: فالتحديث الفائت لا يعني بالضرورة الخسارة (يستطيع المالك الإنفاق كما هو معتاد، إذ يجب أن تُخترق مفتاح الاسترداد أيضاً أو أن يُساء استخدامه)، في حين أن فقدان المفتاح في نظام single-sig يعني دائماً خسارة كاملة. أي أن المخاطرة تُحوَّل وتُقلَّص فعلياً لكنها لا تُلغى كلياً — والاعتراض صحيح في جوهره.
Bei Miniscript-Wallets genügt der Seed nicht mehr als Backup: Ohne separat gesicherten Descriptor samt aller xpubs sind die Coins trotz intakter Schlüssel praktisch unauffindbar. Damit entsteht ein neuer, wenig verstandener Single Point of Failure, den Millionen Nutzer aus der Single-Sig-Welt gar nicht kennen.With Miniscript wallets the seed is no longer a sufficient backup: without a separately stored descriptor including all xpubs, the coins are practically unfindable despite intact keys. This creates a new, poorly understood single point of failure that millions of users from the single-sig world do not even know exists.Con las wallets Miniscript, la seed ya no es suficiente como copia de seguridad: sin el descriptor respaldado por separado junto con todos los xpubs, las monedas son prácticamente imposibles de encontrar a pesar de tener las claves intactas. Esto genera un nuevo punto único de fallo, poco comprendido, que millones de usuarios provenientes del mundo single-sig ni siquiera saben que existe.Com as wallets Miniscript, a seed já não é suficiente como backup: sem o descriptor salvo separadamente, incluindo todos os xpubs, as moedas são praticamente impossíveis de localizar mesmo com as chaves intactas. Isso cria um novo single point of failure, pouco compreendido, que milhões de usuários do mundo single-sig nem sequer sabem que existe.Miniscriptウォレットでは、シードだけではバックアップとして不十分です。すべてのxpubを含むdescriptorを別途保存していなければ、鍵が無事であっても実質的にコインを見つけることはできません。これにより、single-sigの世界しか知らない何百万ものユーザーが存在すら気づいていない、新たな単一障害点（Single Point of Failure）が生まれています。在 Miniscript 钱包中，助记词（seed）不再足以作为备份：若未单独保存包含所有 xpub 的 descriptor，即便密钥完好无损，资金也几乎无从找回。这带来了一个新的、鲜为人知的单点故障（Single Point of Failure），而来自单签（single-sig）世界的数百万用户对此甚至毫无察觉。في محافظ Miniscript، لم يعد الـ seed وحده كافيًا كنسخة احتياطية: فبدون حفظ الـ descriptor بشكل منفصل مع جميع الـ xpubs، تصبح العملات غير قابلة للاسترداد عمليًا على الرغم من سلامة المفاتيح. يُفرز هذا نقطة فشل منفردة (Single Point of Failure) جديدة وغير مفهومة جيدًا، لا يعلم بوجودها ملايين المستخدمين القادمين من عالم التوقيع الفردي (single-sig).
Belegt: Die Notwendigkeit des Descriptor-Backups ist technisch unstrittig und in der Bitcoin-Core-Dokumentation wie bei allen Miniscript-Wallets ausgewiesen; Liana erzwingt den Export beim Setup. Abmildernd wirkt, dass der Descriptor keine Geheimnisse enthält und daher redundant (Cloud, Papier, Dritte) gesichert werden darf – anders als ein Seed. Das Problem ist also lösbar, aber es ist eine reale zusätzliche Fehlerklasse, deren Unterschätzung zu Totalverlusten führen kann.Substantiated: the need for a descriptor backup is technically undisputed and stated in Bitcoin Core documentation and by every Miniscript wallet; Liana enforces the export during setup. A mitigating factor is that the descriptor contains no secrets and may therefore be stored redundantly (cloud, paper, third parties) – unlike a seed. The problem is thus solvable, but it is a real additional failure class whose underestimation can lead to total loss.Fundamentado: la necesidad de realizar una copia de seguridad del descriptor es técnicamente indiscutible y está indicada en la documentación de Bitcoin Core y por todas las carteras Miniscript; Liana obliga a exportarlo durante la configuración inicial. Un factor atenuante es que el descriptor no contiene secretos y, por tanto, puede almacenarse de forma redundante (en la nube, en papel, con terceros), a diferencia de una seed. El problema es, pues, resoluble, pero constituye una clase de fallo adicional real cuya subestimación puede provocar pérdidas totales.Fundamentado: a necessidade de um backup do descriptor é tecnicamente incontestável e está indicada na documentação do Bitcoin Core e por todas as carteiras Miniscript; o Liana exige a exportação durante a configuração. Um fator atenuante é que o descriptor não contém segredos e, portanto, pode ser armazenado de forma redundante (nuvem, papel, terceiros), ao contrário de uma seed. O problema é, portanto, solucionável, mas representa uma classe de falha adicional real, cuja subestimação pode levar à perda total dos fundos.裏付けあり：ディスクリプターのバックアップが必要であることは技術的に異論の余地がなく、Bitcoin CoreのドキュメントおよびすべてのMiniscriptウォレットにも明記されている。Lianaはセットアップ時にエクスポートを強制する。緩和要因として、ディスクリプターにはシークレットが含まれていないため、シードとは異なり、冗長な形で保管できる（クラウド、紙、第三者など）。したがってこの問題は解決可能だが、過小評価すると資産の全損につながりうる、現実に存在する追加的な障害クラスである。有据可查：描述符备份的必要性在技术上无可争议，Bitcoin Core文档及所有Miniscript钱包均有明确说明；Liana在设置过程中强制要求导出。一个缓解因素是，描述符不包含任何私密信息，因此可以冗余存储（云端、纸质、第三方），这与助记词不同。因此，该问题是可以解决的，但它是一种真实存在的额外故障类型，若对其重视不足，可能导致资产全部损失。موثَّق: الحاجة إلى نسخ احتياطي من الـ descriptor أمرٌ غير متنازَع عليه من الناحية التقنية، وهو مُوثَّق في وثائق Bitcoin Core وفي جميع محافظ Miniscript؛ كما يُلزم Liana بتصدير هذا الـ descriptor أثناء الإعداد. ومن العوامل المخففة أن الـ descriptor لا يحتوي على أي أسرار، ومن ثَمَّ يمكن تخزينه بصورة مكررة (سحابياً، ورقياً، لدى أطراف ثالثة)، خلافاً لعبارة الاسترداد (seed). وهكذا فإن المشكلة قابلة للحل، غير أنها تمثّل فئة إخفاق إضافية حقيقية، قد يؤدي الاستهانة بها إلى خسارة كاملة للأصول.
Miniscript-Policies sind zu jung und zu selten im Einsatz, um ihnen Lebensersparnisse anzuvertrauen: verglichen mit Single-Sig und klassischer Multisig gibt es weniger Implementierungen, weniger Audits, weniger Wiederherstellungs-Software – und niemand weiß, ob eine 2026 konfigurierte Erbschafts-Policy im Jahr 2046 noch von gängiger Software verstanden wird.Miniscript policies are too young and too rarely deployed to entrust life savings to them: compared with single-sig and classic multisig there are fewer implementations, fewer audits, less recovery software – and nobody knows whether an inheritance policy configured in 2026 will still be understood by mainstream software in 2046.Las políticas de Miniscript son demasiado jóvenes y demasiado poco utilizadas como para confiarles los ahorros de toda una vida: en comparación con single-sig y multisig clásico, existen menos implementaciones, menos auditorías, menos software de recuperación, y nadie sabe si una política de herencia configurada en 2026 seguirá siendo compatible con el software convencional en 2046.As políticas de Miniscript são jovens demais e raramente utilizadas para que se possa confiar nelas as economias de uma vida: em comparação com single-sig e multisig clássico, há menos implementações, menos auditorias, menos software de recuperação — e ninguém sabe se uma política de herança configurada em 2026 ainda será compreendida pelo software convencional em 2046.Miniscriptポリシーは、生涯の貯蓄を預けるには普及度も実績も不十分です。シングルシグや従来のマルチシグと比べると、実装の数が少なく、監査も少なく、リカバリーソフトウェアも乏しい上、2026年に設定した相続ポリシーが2046年に主流のソフトウェアで正しく解釈されるかどうかも誰にもわかりません。Miniscript 策略过于年轻、部署案例过于稀少，尚不足以托付毕生积蓄：与单签名和经典多签相比，其实现数量更少、审计更少、恢复软件也更匮乏——而且没有人知道，2026 年配置的继承策略到 2046 年是否仍能被主流软件所识别。سياسات Miniscript حديثة العهد ونادرة الاستخدام لدرجة لا تكفي لأن تُعهد إليها مدخرات العمر: فمقارنةً بالتوقيع الفردي (single-sig) والتوقيع المتعدد الكلاسيكي (multisig)، ثمة تطبيقات أقل، ومراجعات أمنية أقل، وبرامج استرداد أقل — ولا أحد يعلم إن كانت سياسة الميراث التي تُضبط عام 2026 ستظل مفهومةً لدى البرامج السائدة في عام 2046.
Offen: Für den Einwand sprechen ein realer Vorfall und der Normstatus: Ledgers Bitcoin-App 2.1.0/2.1.1 erzeugte bei einem bestimmten Miniscript-Fragment falsche Adressen (Ledger Security Bulletin 019) – ein Reifegrad-Problem genau der befürchteten Art –, und BIP 379 trägt auch nach Aufnahme ins BIP-Verzeichnis (Juni 2024) weiterhin den Status „Entwurf“. Dagegen sprechen die breite Standardisierung (BIPs 380–386, BIP 388 mit Status „Complete“) und die Integration in Bitcoin Core seit Version 24/25: Ein Descriptor ist gerade dafür gebaut, Wallets softwareunabhängig zu rekonstruieren, und die Konsensregeln für die zugrunde liegenden Skripte ändern sich praktisch nie. Langzeitdaten über 20-Jahres-Horizonte existieren nicht; beide Seiten haben Substanz.Open: supporting the objection are a real incident and the standards status: Ledger's Bitcoin app 2.1.0/2.1.1 produced wrong addresses for a particular Miniscript fragment (Ledger Security Bulletin 019) – a maturity problem of exactly the feared kind – and BIP 379 still carries "draft" status even after being added to the BIP repository (June 2024). Against it stand broad standardisation (BIPs 380–386, BIP 388 with status "Complete") and integration into Bitcoin Core since versions 24/25: a descriptor is built precisely to reconstruct wallets independently of any one software, and the consensus rules for the underlying scripts practically never change. No long-term data over 20-year horizons exist; both sides have substance.Abierto: a favor de la objeción hablan un incidente real y el estado normativo: la app de Bitcoin 2.1.0/2.1.1 de Ledger generó direcciones incorrectas para un determinado fragmento de Miniscript (Ledger Security Bulletin 019) —un problema de madurez exactamente del tipo temido—, y BIP 379 sigue en estado «borrador» incluso tras su incorporación al repositorio de BIPs (junio de 2024). En contra se sitúan la amplia estandarización (BIPs 380–386, BIP 388 con estado «Complete») y la integración en Bitcoin Core desde las versiones 24/25: un descriptor está construido precisamente para reconstruir carteras con independencia de cualquier software concreto, y las reglas de consenso para los scripts subyacentes prácticamente nunca cambian. No existen datos a largo plazo en horizontes de 20 años; ambas posturas tienen fundamento.Em aberto: a favor da objeção falam um incidente real e o estado normativo: o app Bitcoin 2.1.0/2.1.1 da Ledger gerou endereços incorretos para um determinado fragmento de Miniscript (Ledger Security Bulletin 019) — um problema de maturidade exatamente do tipo temido —, e o BIP 379 ainda mantém o status de «rascunho» mesmo após ser incluído no repositório de BIPs (junho de 2024). Contra ela estão a ampla padronização (BIPs 380–386, BIP 388 com status «Complete») e a integração ao Bitcoin Core desde as versões 24/25: um descriptor foi criado precisamente para reconstruir carteiras de forma independente de qualquer software específico, e as regras de consenso para os scripts subjacentes praticamente nunca mudam. Não existem dados de longo prazo em horizontes de 20 anos; ambos os lados têm substância.未解決：この異論を支持する根拠として、実際のインシデントと規格上のステータスが挙げられる。LedgerのBitcoinアプリ2.1.0/2.1.1は、特定のMiniscriptフラグメントに対して誤ったアドレスを生成した（Ledger Security Bulletin 019）——まさに懸念されていた種類の成熟度の問題である——また、BIP 379はBIPリポジトリへの追加（2024年6月）後も引き続き「ドラフト」ステータスを保持している。一方、反論として挙げられるのは、広範な標準化（BIP 380～386、ステータス「Complete」のBIP 388）と、バージョン24/25以降のBitcoin Coreへの統合である。ディスクリプターはまさに、特定のソフトウェアに依存せずウォレットを復元するために設計されており、基盤となるスクリプトのコンセンサスルールが変わることは実質的にない。20年という長期的な時間軸にわたるデータは存在しない。双方の主張にはそれぞれ根拠がある。悬而未决：支持该异议的理由包括一起真实事件和标准状态：Ledger的Bitcoin应用程序2.1.0/2.1.1在处理特定Miniscript片段时生成了错误地址（Ledger Security Bulletin 019）——这正是外界所担忧的那类成熟度问题——此外，BIP 379在被纳入BIP存储库（2024年6月）后仍维持"草案"状态。反驳理由则包括：广泛的标准化（BIP 380–386，以及状态为"Complete"的BIP 388），以及自版本24/25起与Bitcoin Core的集成——描述符的设计初衷正是为了不依赖任何单一软件来重建钱包，而底层脚本的共识规则几乎从不改变。目前尚不存在跨越20年时间维度的长期数据；双方观点均有实质依据。مفتوح: يدعم الاعتراضَ حادثةٌ فعلية وحالةُ المعايير: فقد أنتج تطبيق Bitcoin 2.1.0/2.1.1 من Ledger عناوين خاطئة لجزء معين من Miniscript (Ledger Security Bulletin 019) — وهو مشكلة نضج من النوع الذي كان يُخشى تحديدًا — فضلًا عن أن BIP 379 لا يزال يحمل وضع «مسودة» حتى بعد إدراجه في مستودع BIP (يونيو 2024). في المقابل، يقف ضد هذا الاعتراض التوحيد القياسي الواسع (BIPs 380–386، وBIP 388 بوضع «Complete»)، والتكامل مع Bitcoin Core منذ الإصدارين 24/25: إذ صُمِّم الـ descriptor تحديدًا لإعادة بناء المحافظ بصورة مستقلة عن أي برنامج بعينه، وقواعد الإجماع للسكريبتات الأساسية لا تتغير عمليًا أبدًا. لا توجد بيانات طويلة الأمد على مدى أفق 20 عامًا؛ وكلا الجانبين يملك حججًا ذات وزن.
Für die große Mehrheit der Nutzer ist die zusätzliche Komplexität netto sicherheitsmindernd: Nutzerfehler dominieren die Verlustursachen, und jede zusätzliche Konfigurationsoption (Fristen, Schlüsselrollen, Pfade) vergrößert die Angriffsfläche für Fehlbedienung. Ein sauber gesichertes Single-Sig- oder Standard-Multisig-Setup schlägt in der Praxis eine falsch konfigurierte Policy.For the large majority of users the added complexity is a net security negative: user error dominates loss causes, and every additional configuration option (delays, key roles, paths) enlarges the surface for mishandling. A properly backed-up single-sig or standard multisig setup beats a misconfigured policy in practice.Para la gran mayoría de los usuarios, la complejidad adicional supone una reducción neta de la seguridad: el error del usuario domina las causas de pérdida, y cada opción de configuración adicional (plazos, roles de clave, rutas) amplía la superficie de exposición a un mal uso. Una configuración single-sig o multisig estándar correctamente respaldada supera en la práctica a una política mal configurada.Para a grande maioria dos utilizadores, a complexidade adicional representa uma redução líquida de segurança: o erro do utilizador domina as causas de perda, e cada opção de configuração adicional (prazos, funções de chave, caminhos) amplia a superfície de risco para uso indevido. Uma configuração single-sig ou multisig padrão corretamente salvaguardada supera, na prática, uma política mal configurada.大多数のユーザーにとって、複雑さの増加はセキュリティを正味で低下させる。損失の原因はユーザーエラーが支配的であり、設定オプションが増えるたびに（タイムロック、鍵の役割、パスなど）、操作ミスによるリスクの表面積が広がる。適切にバックアップされたシングルシグまたは標準的なマルチシグの構成は、実際には誤って設定されたポリシーより優れている。对于绝大多数用户而言，额外的复杂性在安全性上得不偿失：用户错误是资产损失的主要原因，而每增加一个配置选项（时间锁、密钥角色、路径），都会扩大误操作的攻击面。一个备份得当的单签或标准多签方案，在实践中远胜于一个配置错误的策略。بالنسبة للغالبية العظمى من المستخدمين، تُشكّل التعقيدات الإضافية عبئاً صافياً على الأمان: إذ يهيمن خطأ المستخدم على أسباب الخسارة، وكل خيار إعداد إضافي (فترات الانتظار، وأدوار المفاتيح، والمسارات) يوسّع نطاق الاستخدام الخاطئ. والواقع أن إعداد single-sig أو multisig القياسي المنسوخ احتياطياً بشكل صحيح يتفوق عملياً على أي سياسة مُهيَّأة بشكل خاطئ.
Offen: Dass Nutzerfehler die dominierende Verlustursache bei Selbstverwahrung sind, ist gut dokumentiert, und die Warnung vor unnötiger Komplexität entspricht etablierter Sicherheitspraxis. Gegenläufig gilt: Genau die gefährlichste Fehlerklasse – handgeschriebene, unprüfbare Skripte – wird durch Miniscripts maschinelle Analyse (Korrektheit, Malleability, Gebühren) eliminiert, und BIP-388-Registrierung lässt Hardware-Signer die Policy verständlich anzeigen. Ob geführte Setups wie Liana die Fehlbedienungsrate unter das Niveau von Single-Sig-Backup-Fehlern drücken, ist empirisch nicht erhoben; es fehlen belastbare Verlustdaten für beide Lager.Open: that user error dominates self-custody losses is well documented, and warning against unnecessary complexity reflects established security practice. On the other hand, precisely the most dangerous failure class – hand-written, unverifiable scripts – is eliminated by Miniscript's machine analysis (correctness, malleability, fees), and BIP 388 registration lets hardware signers display the policy intelligibly. Whether guided setups such as Liana push the mishandling rate below the level of single-sig backup errors has not been measured empirically; robust loss data are missing for both camps.Abierto: que los errores de usuario dominen las pérdidas en la autocustodia está bien documentado, y advertir contra la complejidad innecesaria refleja una práctica de seguridad consolidada. Por otro lado, precisamente la clase de fallo más peligrosa —los scripts escritos a mano e inverificables— es eliminada por el análisis automático de Miniscript (corrección, maleabilidad, comisiones), y el registro BIP 388 permite que los firmantes hardware muestren la política de forma inteligible. Si configuraciones guiadas como Liana logran reducir la tasa de uso incorrecto por debajo del nivel de errores de copia de seguridad de firma única no se ha medido empíricamente; faltan datos de pérdidas sólidos para ambos bandos.Em aberto: que os erros de utilizador dominam as perdas em autocustódia está bem documentado, e alertar contra a complexidade desnecessária reflete uma prática de segurança consolidada. Por outro lado, precisamente a classe de falha mais perigosa — scripts escritos à mão e não verificáveis — é eliminada pela análise automática do Miniscript (correção, maleabilidade, taxas), e o registo BIP 388 permite que os assinantes de hardware exibam a política de forma inteligível. Se configurações guiadas como a Liana conseguem reduzir a taxa de uso incorreto abaixo do nível de erros de cópia de segurança de assinatura única não foi medido empiricamente; faltam dados de perdas robustos para ambos os campos.未解決の問題：ユーザーエラーがセルフカストディにおける損失の主要因であることはよく知られており、不必要な複雑さに対する警告は確立されたセキュリティ慣行に沿ったものである。一方で、まさに最も危険な障害クラス——手書きで検証不可能なスクリプト——は、Miniscriptの機械的解析（正確性、マリアビリティ、手数料）によって排除され、BIP 388の登録によってハードウェア署名者がポリシーを分かりやすく表示できるようになる。Lianaのようなガイド付きセットアップが誤操作率をシングルシグのバックアップエラーの水準以下に抑えられるかどうかは、実証的に測定されていない。双方について信頼性の高い損失データが不足している。尚待厘清：用户错误主导自托管损失这一点已有充分记录，警惕不必要的复杂性也符合成熟的安全实践。另一方面，恰恰是最危险的那类失误——手写且无法验证的脚本——已通过 Miniscript 的机器分析（正确性、可塑性、手续费）得以消除，而 BIP 388 注册机制则使硬件签名设备能够以可读方式显示策略。像 Liana 这样的引导式配置能否将误操作率压低至单签备份错误的水平以下，目前尚无实证数据；双方阵营均缺乏可靠的损失数据。مسألة مفتوحة: أن أخطاء المستخدم تُهيمن على خسائر الحضانة الذاتية أمرٌ موثق توثيقاً جيداً، والتحذير من التعقيد غير الضروري يعكس ممارسات أمنية راسخة. في المقابل، فإن أخطر فئة من حالات الفشل تحديداً — وهي البرمجيات النصية المكتوبة يدوياً وغير القابلة للتحقق — يتم القضاء عليها بفضل التحليل الآلي لـ Miniscript (الصحة، والقابلية للتشكيل، والرسوم)، كما يتيح تسجيل BIP 388 لأجهزة التوقيع عرض السياسة بصورة مفهومة. أما ما إذا كانت الإعدادات الموجَّهة كـ Liana قادرة على خفض معدل الاستخدام الخاطئ إلى ما دون مستوى أخطاء النسخ الاحتياطي بالتوقيع الفردي، فلم يُقاس تجريبياً بعد؛ إذ تغيب بيانات الخسائر الموثوقة في كلا المعسكرين.
QuellenSourcesFuentesFontes出典来源المصادر
- Bitcoin Optech – Topic: Miniscript (bitcoinops.org)
- Bitcoin Optech – Topic: Output Script Descriptors (bitcoinops.org)
- BIP 380 – Output Script Descriptors (General Operation) (github.com)
- BIP 388 – Wallet Policies for Descriptor Wallets (bips.dev)
- Ledger – Towards a Trustless Bitcoin Wallet with Miniscript (ledger.com)
- Blockstream – Jade Adds Support for Miniscript (blog.blockstream.com)
- Wizardsardine – The State of Bitcoin Inheritance Planning (wizardsardine.com)
- Liana Wallet – Bitcoin Self-Custody with Recovery Paths (lianawallet.com)