Miniscript: Spending Policies You Can Reason About In Bitcoin, spending policies are defined and enforced by means of a stack-based programming language known as Bitcoin Script. While this language appears to be designed with tractable analysis in mind (e.g. there are no looping or jumping constructions), in practice this is extremely difficult. As a result, typical wallet software supports only a small set of script templates, cannot interoperate with other similar software, and each wallet contains independently written ad-hoc manually verified code to handle these templates. Users who require more complex spending policies, or who want to combine signing infrastructure which was not explicitly designed to work together, are simply out of luck. In the first half of this talk we introduce Miniscript, a subset of Bitcoin Script which eliminates the difficult-to-analyze parts of Script while retaining sufficient expressivity to describe digital signatures, hash preimages and timelock requirements in arbitrary combination. Using Miniscript, many previously complex tasks become simple: determining the set of signatures needed to satisfy a policy; encoding the satisfaction of any branch of the policy; estimating the cost of satisfaction; determining the optimal satisfaction when many are available. It is also possible to efficiently answer more complex questions, such as ensuring a countersigner that his signature is required in every branch of a complex policy, or ensuring a participant in a swap protocol that his counterparty cannot back out of the protocol until a timelock has expired. In the second half of the talk, we reinterpret Miniscript not as a subset of Script, but as a different language with an entirely different programming paradigm. While Script (and other languages such as Ethereum's EVM) use an ``execution-centric'' paradigm in which instructions are listed and evaluated in order, Miniscript uses a ``verification-centric'' paradigm in which coin- spending conditions are directly described. Because Script does not have unbounded loops, these apparently contradictory views are equivalent in a theoretical sense. However, as we have seen, the verification-centric model makes policies simpler to describe, use and reason about. We briefly discuss how this model is also used in circuit-based zero-knowledge proof schemes such as SNARKs and Bulletproofs, as well as in next-generation contracting languages such as Simplicity.