Andrew Poelstra

Mathematical notation often begins with an ordinary concern: keeping savings safe or avoiding disclosure of every payment amount. Poelstra worked on tools that turn such needs into verifiable rules. In February 2023, Blockstream introduced him as Director of Research. Its update for the second quarter of 2026 uses that title for Jonas Nick. An older job title therefore cannot simply be presented as a current position. Specific projects and collaborations tell us more about a researcher’s contribution than a job title alone. [1] [2]

Imagine spending from your wallet with your usual key while arranging a different, predetermined path that becomes available after a delay if that key is lost. Writing those conditions down is only part of the task: you also need to check that they mean what you intended. Miniscript helps with this. Its documentation names Pieter Wuille, Andrew Poelstra and Sanket Kanjalkar as its creators and acknowledges wider discussions. It is a shared achievement; crediting one contributor does not absorb the work of the others. [3]

Bitcoin Script is the language used to define spending conditions. Miniscript gives a defined subset of it a structure that supports combining and analyzing those conditions. A compiler, a program that translates a specification into a concrete expression, can look for a cheaper construction. If the everyday path is expected to be used more often than the backup, it can account for that in expected costs. These weights do not add a probabilistic validity condition: the less common path is no less valid. What matters is meeting its rules. [3]

A backup path also needs a clear starting point for its delay. Miniscript after expresses an absolute threshold through the transaction’s nLockTime field, such as a particular chain height. By contrast, older uses the relative nSequence condition, measuring a delay from confirmation of the output being spent. These are different meanings of time, not interchangeable names. Expiry alone does not trigger payment. It may make a path available, but its signatures and other conditions must still be satisfied, and a transaction must be created and confirmed. [3]

Can we check a property of an amount while keeping the amount private? Bulletproofs are one way to do that. A verifier can learn that a hidden number lies within an allowed range without learning its value. Stanford lists Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille and Greg Maxwell as the authors. A research paper is distinct from a particular program: the page labels some implementations as work in progress and a prototype as unsuitable for production use. A link alone is not a recommendation to entrust software with money. [4]

Some proof systems need an initial preparation of parameters whose security depends on properly handling secret information. This is called a trusted setup. Bulletproofs do not require that preparation. This useful property does not remove cryptographic assumptions or the risk of programming errors. A short proof is not necessarily the fastest to verify, either; that depends on the task and the comparison. Separate three questions: what the proof establishes, what its security relies on, and how much work verification requires. [4]

With visible amounts, a verifier can add and compare them. Hidden amounts need mathematical proofs to provide the corresponding assurance. In February 2018, Poelstra explained the rangeproof: a proof that an amount stays within permitted bounds and cannot exploit numerical overflow to defeat the accounting. Bulletproofs can combine proofs for several values into a more compact whole. His article also reports performance measurements on specified equipment, not a universal network speed. Smaller proofs reduce a particular burden; they do not automatically solve every limitation of payments. [5]

In April 2017, Poelstra described Confidential Assets for Elements, a platform for building blockchain systems. Here, both the amount and the kind of asset being transferred can remain hidden. Verifiers can still check that a transfer has not improperly created an asset or converted it into another. Issuing units and issuing more later have separate rules and authorization. This brings privacy together with public verification again. An Elements feature is not evidence of adoption on Bitcoin’s base layer: distinguish the research, the implementation and the network actually using it. [6]