Miniscript

Anna wants ordinary access to her coins using her own key. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. A wallet is an application or device for receiving and sending bitcoin. Anna also wants a path for Peter, who may spend them with his key after 144 blocks from the confirmation of that output. This intent is called a spending policy. Miniscript helps turn it into a precise form a wallet can handle. Peter still needs his key; waiting does not replace it. This is a simple example of alternative access paths, not an automatic transfer or a way to detect that Anna has lost her key. [1] [2] [10]

A rule expressed in words is not yet the program the network checks. A compiler can choose a concrete Miniscript for that intent and translate it into Bitcoin Script. An Output Descriptor then describes the resulting scripts together with keys and any derivation paths; it may also include a checksum to detect copying errors. Spending is verified against the actual script and supplied data, not the original sentence. Miniscript adds no new instruction and changes no consensus rule. It cannot represent every imaginable Bitcoin Script. [1] [3] [6]

A block groups transactions into a batch added to the shared history. In Peter’s example, the 144 blocks run from confirmation of the output, a specific amount with spending conditions. This is neither an exact day nor time since the wallet was created. Miniscript expresses relative waiting as older(n), using CSV and the spending input’s nSequence field, whose age-validation meaning is defined by BIP 68. By contrast, after(n) uses CLTV and absolute nLockTime, a fixed height or time threshold. The wallet must set the transaction fields correctly and meet all other conditions. Height and time locks must not be combined incompatibly; waiting alone sends nothing. [1] [7] [8] [9] [11]

Showing a description of the rules is not enough. The wallet must supply data that satisfies an allowed path: signatures, for example, or a secret matching a required hash, called its preimage. A hash is a digital fingerprint of data; here the check asks whether the supplied secret produces the required fingerprint. Fulfilling the conditions in this way is a satisfaction; the necessary input data forms part of the transaction’s witness. Combining branches can require making a particular subcondition properly false so another path can be used. That is a dissatisfaction, not an invalid payment as a whole. Software can assemble a suitable path, but cannot invent a missing private key or an unknown secret. [1] [12]

PSBT is a format for passing a prepared transaction and supporting information between a wallet and signing devices. Supporting PSBT alone is insufficient: the software and Hardware Wallet must understand the descriptor and its conditions. Bitcoin Core added watch-only Miniscript support in P2WSH in version 24, signing in version 25 and use in Taproot descriptors in version 26. Watching coins is therefore not the same as being able to spend them. During setup, verify the keys, required signatures, delays and every alternative path on a trusted display, according to the device’s actual capabilities. [3] [4] [5]

A Seed Phrase recovers keys, but for a custom condition it may not reveal how they were combined with other keys and the script. This backup is written as a sequence of words from which the wallet can derive its keys. Preserve the exact checksummed descriptor, key map, derivation paths and the distinction between receiving and change addresses. Record the network, address range and historical scan starting point separately. A public descriptor is not a private key, but can reveal payment history. Before using the arrangement, test both watch-only recovery and every intended spending path in a Regtest or Signet test environment. [5] [6]

The expressions pk(), older(), after() and sha256() represent signatures, waiting or a required secret. Expressions such as and_v(), or_d() and thresh() combine conditions. Wrappers such as v: adjust evaluation behaviour while preserving the subexpression’s meaning. Types B, V, K and W constrain how components pass items on the stack, the script’s working area; not every pair fits together. Type checking can therefore expose an incompatible composition. It cannot decide whom Anna should trust or whether she chose a sensible recovery path. [1] [2]

The structure lets software analyse script and witness size, operations, signature checks and stack items before spending. This helps estimate the cost of different paths and detect resource-limit violations. Context matters: P2WSH places conditions within SegWit, whereas Tapscript refers to scripts used in Taproot. Their limits differ in some respects. Common transaction relay rules matter alongside consensus rules. An analysis result is therefore not a universal certificate that every wallet can carry out the intended procedure. [1]

A public key is used to verify signatures and does not need to be kept secret. Malleability analysis asks whether an outsider can turn one valid satisfaction into another valid one. Its guarantees have specific assumptions: the attacker has no participating private keys, knows no more preimages than the honest user and sees only one satisfaction. The analysis also assumes no repeated public keys and common acceptance rules; a miner may have options unavailable to an ordinary relaying node. This is not protection against every malicious participant, lost backup or poor custody design. Those concerns need separate attention. [1]

A compiler may express the same rules in different ways, with different script and witness sizes. It chooses according to a cost model. A branch annotation such as 9@ in the policy input language hints at relative usage probability; it is neither a signature count nor a network permission. A different compilation can produce a different script and hence different addresses. Recovery cannot therefore rely on describing the rules again in your own words and recompiling them. The exact saved representation, checks of derived addresses and a tested signing path matter. [2] [5]