Checking post-quantum signatures in Bitcoin Script

A small experiment. It ran on a private test network with an experimental fork. It is not production software and it does not make any coins quantum-safe.

Transactions per second

If every transaction on the network used one scheme, how many transactions would fit? This follows a chart by Jonas Nick and its script: 4,000,000 weight units per block, one block every 600 seconds, an average transaction with 2.27 inputs and 2.64 outputs. The P2TR row reproduces his number. The other rows use the witness sizes we measured, which include the checker program because there is no native opcode.

Show as table

Scheme	Tx per second	Tx per block	Inputs spent per block	vbytes per tx
P2TR key spend, today	6.55	3,929	8,918	254
Native opcode, hypothetical	2.81	1,684	3,822	594
Script, stateful, shared	0.53	315	715	3,173
Script, stateless, shared	0.14	87	197	11,534
Script, stateful, inline	0.03	18	41	54,745
Script, stateless, inline	0.02	13	29	79,272

The native-opcode row is not measured. It assumes a consensus change that checks the same 660-byte signature with nothing else in the witness. His SHRINCS point sits higher, at 4.13, because it uses a 324-byte signature from a different parameter set. Our signature comes from the pinned specification and is 660 bytes for this key.

The checker program, not the signature, sets the throughput. Moving it into the node would raise the stateful figure about five times. "Inline" means the same checker written out without shared functions. Shared functions raise the stateful figure about seventeen times over that.

How big is a SHRINCS transaction?

One input, two outputs, one SHRINCS signature, using the compact checker with shared functions. These are the real transactions the test network mined.

The program is the biggest part, not the signature. Fees are paid per vbyte, and witness bytes count for a quarter, so the stateful spend costs about ten times an ordinary payment of around 150 vbytes. Without shared functions the same spends are 24,135 and 34,940 vbytes.

Shared functions make it small

The fork lets a program define a function once and call it many times. Without that, every repeated step must be written out in full.

What "with shared functions" means. The fork has two opcodes, OP_DEFINE and OP_INVOKE, that let a program store a piece of code once and run it many times. The checker repeats a few steps thousands of times: one hash-chain step, one Merkle-tree step, one WOTS check. "With shared functions" defines each of those once and calls it. "Without" writes every repetition out in full. Both programs do the same work and accept exactly the same signatures.

Two things differ between the bars, not one. The "with" version also uses OP_BYTEREV, a byte-reversal opcode the fork adds; the "without" version builds byte reversal from slices. Measured on the standalone stateful checker: 95,209 bytes with neither, 52,038 bytes with byte reversal alone, 4,335 bytes with byte reversal and shared functions. So reversal accounts for a bit under half of the baseline size, and functions for nearly all of the rest. The bars above add the 141-byte spending policy to those figures.

The "without" checker itself uses only the restoration opcodes from BIP 440 and BIP 441. The spending policy around it, in both versions, also needs the fork's OP_TX opcode to read the transaction being signed. Every spend on this page therefore depends on OP_TX; only the verifier inside the "without" policy is restoration-only.

For scale: an ordinary Bitcoin payment today is about 150 vbytes. The stateful spend is about ten times that. The signature itself is 660 bytes; the rest is the checker program and the transaction.

The stateful spend uses about 36% of the execution budget the fork allows for a transaction of its size. The stateless spend uses about 60%. Both fit without any tricks.

Where the cost goes

The fork charges every instruction a fixed price: 1,250 units for most, 3,000 for comparisons and arithmetic, 4,000 for a function call. On top of that it charges for data-dependent work, such as 50 units per byte hashed. We expected hashing to dominate. It does not.

Almost all of the cost is bookkeeping: moving bytes around and branching. The cryptography is a small slice. Two things follow:

• Byte reversal and shared functions together shrink the stateful program by 95% (95,350 to 4,476 bytes) but reduce the charged work by only 15% (24,150,510 to 20,577,528 units). They compress code, not execution.
• Programs with lots of skipped code run slower per charged unit than the cost table predicts. Parsing skipped code is not charged. This is a real input to recalibrating the fork's prices, and we built a tool to measure it.

The numbers behind the charts

One row per program. "Shared" uses shared functions, "inline" writes everything out, and "unified" is one program that accepts both signature types. Executed opcodes and calls are for one spend. The fixed charge is the sum of each executed opcode's fixed price. Charged units are what the fork actually deducted, which includes the data-dependent part.

"Budget used" is charged units divided by the allowance of 10,000 units per weight unit of the transaction. A smaller program gets a smaller allowance, which is why the compact programs use a larger share even though they do less work.

Every opcode executed by the stateful spend, with and without shared functions, sorted by how often it runs. The last two columns multiply the count by the opcode's fixed price.

The three most common opcodes, PICK, CAT, and DROP, move data around. Together with the small constant pushes and the IF, ELSE, and ENDIF triple they account for most of the executed instructions. SHA256 runs 253 times in both versions. Shared functions cut the executed instruction count by about a sixth, mostly by removing skipped branches. They do not change the number of hashes.

OP_MULTI was not needed

The fork has an instruction called OP_MULTI that applies one operation to a variable number of values. The SHRINCS checker never used it. The one real use we found in the fork's own tests, summing all the output amounts of a transaction, can be done with an existing simpler instruction.

The cost difference is small in practice. The real argument is simpler: OP_MULTI is about 230 lines of interpreter code with several different behaviours hidden behind one instruction, and nothing we found needs it. We recommend deferring it.

What we did not do

• No comparison with Simplicity. Simplicity is a rival approach, and a recent post put its SHRINCS checker at about 50 kilobytes. The existing Simplicity implementation uses different SHRINCS parameters, so its size cannot be compared with ours yet. Someone has to build both to the same spec first.
• The coins are not quantum-safe. Our outputs use ordinary Taproot, which keeps an old-style key path. Removing that path is a separate consensus change.
• No wallet, no signer, no security proof. This is a checker, running in a lab.

Check it yourself

Everything is in the repository. It is private for now, so the links need access. Start with the README's reading guide. The code, the test inputs, the transactions, and the measurements are all there, and a clean build on GitHub reproduces the programs and test results byte for byte.

Figures on this page come from the measured results at tag baseline-2026-09-18 and the later evidence refresh. Execution cost is measured in the fork's own charged units, not seconds.