BIP Draft: OP

Nuhvi commented at 4:50 pm on January 1, 2026: none

This BIP describes a new tapscript opcode (OP_AMOUNT) which pushes the amount of the selected input or output to the stack.

add bip-op-amount 4d40a47bc8

in bip-op-amount.md:52 in 4d40a47bc8

47+
48+If the selected input or output are out of bound, the script should fail.
49+
50+## Reference Implementation
51+
52+A reference implementation is provided [here](https://github.com/Nuhvi/sake/blob/c3243f000b7ade3b7649a3b3c67b3801b8c12215/src/exec/sake_opcodes/op_amount.rs).

Christewart commented at 6:42 pm on January 1, 2026:

It would be very cool to see an implementation of this op code in conjunction with OP_VAULT, OP_CCV, and OP_CTV to verify this op code proposals satisfies the requirements of these other opcodes proposals that require amount locks.

I received a lot of useful feedback for my proposals and I think you will receive the same with yours :-).

Nuhvi commented at 7:39 pm on January 1, 2026:

Hi @Christewart thanks for taking the time to review this and thanks for your work on OP_INOUT_AMOUNT.

This is a fair thing to ask for, I mostly bet on the “Script Army Knife”’s assertion that simple amount introspection with exact values comparisons is enough, and I don’t have specifics in mind yet, especially because I am more focused on L2s than vaults.

However my hope is that my work on SAKE might encourage developers to either prove or disprove the “Script Army Knife”’s thesis in practice and evidently with observable on-chain emulated scripts.

Of course, if you have a good argument that this proposal is not sufficient for some important application, I am happy to read these.

Still, it is only fair that I do some of the work demonstrating how would this work with at least CCV and TH, I will try.

in bip-op-amount.md:39 in 4d40a47bc8

34+2. Determine the target input or output based on the selector value:
35+   - **selector = 0**: Use the current input being validated
36+   - **selector < 0**: Use input at index `abs(selector) - 1`
37+   - **selector > 0**: Use output at index `selector - 1`
38+3. Retrieve the amount value from the determined input or output
39+4. Push the resulting amount onto the stack as a signed 64 bit integer

Christewart commented at 6:57 pm on January 1, 2026:

Its probably worth noting somewhere in this BIP that a limitation of this proposals is that this result cannot be used with any existing numeric opcodes such as OP_ADD, OP_SUB, OP_LESSTHAN, OP_GREATERTHAN, etc.

Its worth noting that since this op code is using OP_SUCCESS semantics, it gives us the opportunity to expand precision of these opcodes.

Nuhvi commented at 7:48 pm on January 1, 2026:

Both are fair points, and I am happy to include a section for that, feel free to suggest the copy if you want.

I would have used OP_INOUT_AMOUNT instead of introducing a new proposal, even though it requires two stack elements and even though it doesn’t have equivalent to the CURRENT_INPUT_SELECTOR, but I figured, having a proposal without the requirement of an extra tapleaf version is a variant worth having.

I would support GSR or even Simplicity soft fork if I can have it, but scrutiny for soft forks being as it is, I wanted SAKE to demonstrate what can be done with the least changes possible (except for CAT only), so it can also have a good chance of happening before it is too late (I am concerned about low fees, fiat stablecoins, and treasury companies trends).

To that goal, if trustless L2s with fraud proofs can happen without OP_AMOUNT at all, I can live with a version of “Script Army Knife” that doesn’t have the amounts introspection capability at all.

Writing all of that just to explain that I am not opposed to OP_INOUT_AMOUNT or its push for 64 bit arithmetics at all.

Christewart commented at 7:59 pm on January 5, 2026:

OP_INOUT_AMOUNT instead of introducing a new proposal, even though it requires two stack elements and even though it doesn’t have equivalent to the CURRENT_INPUT_SELECTOR

FWIW, one of my learnings from doing the PoC’s with various op code types is that OP_INOUT_AMOUNT should be broken into 2 opcodes

OP_IN_AMOUNT which pushes the amounts associated with inputs onto the stack
OP_OUT_AMOUNT which pushes amounts associated with outputs onto the stack.

Here were the results from breaking OP_INOUT_AMOUNT into 2 opcodes. That is why I recommend prototyping against other opcodes - from hard earned experienced myself :-).

Writing all of that just to explain that I am not opposed to OP_INOUT_AMOUNT or its push for 64 bit arithmetics at all.

I feel the same way about OP_AMOUNT, and think the prototyping work could be useful to make sure we aren’t missing any obvious features or failing to see any problematic design patterns.

Christewart commented at 6:58 pm on January 1, 2026: contributor

Hi @Nuhvi :-). Excited to see more proposals about implementing amount locks in Script. I’m short on time at the moment so hopefully this bit of review is useful. I’ll take a look in detail later.

in bip-op-amount.md:113 in 4d40a47bc8

108+
109+The activation mechanism, and the set of other BIPs to be concurrently deployed, are to be determined.
110+
111+## Acknowledgements
112+
113+The concept for `OP_AMOUNT` and its selector comes from Salvatore Ingala, especially within his proposal for Script Army Knife bundle of tapscript capabilities upgrade.

murchandamus commented at 7:45 pm on January 2, 2026:

I also found these two mailing list threads that mention OP_AMOUNT:

[bitcoin-dev] OP_AMOUNT Discussion

Re: [bitcoin-dev] A Calculus of Covenants

murchandamus commented at 7:46 pm on January 2, 2026: contributor

I don’t see a recent mailing list thread about this idea. Please be sure to send an email to discuss your BIP idea and then another with a first draft of your BIP to the mailing list before opening a PR here.

Since those seem to be outstanding, I’m converting this PR to Draft status, while the discussions are being kicked off. Please set this PR back to “Ready for Review”, when your idea has been discussed on the mailing list.

murchandamus renamed this:
~~BIP OP_AMOUNT~~
BIP Draft: OP_AMOUNT
on Jan 2, 2026

murchandamus added the label New BIP on Jan 2, 2026

murchandamus marked this as a draft on Jan 2, 2026

murchandamus added the label PR Author action required on Jan 2, 2026

BIP Draft: OP_AMOUNT #2069