BIP Draft: OP_AMOUNT #2069
BIP Draft: OP_AMOUNT #2069
Conversation
Christewart
left a comment
Christewart
left a comment
There was a problem hiding this comment.
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.
|
|
||
| ## Reference Implementation | ||
|
|
||
| A reference implementation is provided [here](https://github.com/Nuhvi/sake/blob/c3243f000b7ade3b7649a3b3c67b3801b8c12215/src/exec/sake_opcodes/op_amount.rs). |
There was a problem hiding this comment.
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 :-).
There was a problem hiding this comment.
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.
| - **selector < 0**: Use input at index `abs(selector) - 1` | ||
| - **selector > 0**: Use output at index `selector - 1` | ||
| 3. Retrieve the amount value from the determined input or output | ||
| 4. Push the resulting amount onto the stack as a signed 64 bit integer |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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_AMOUNTwhich pushes the amounts associated with inputs onto the stackOP_OUT_AMOUNTwhich 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.
There was a problem hiding this comment.
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.
|
|
||
| ## Acknowledgements | ||
|
|
||
| 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. |
There was a problem hiding this comment.
I also found these two mailing list threads that mention OP_AMOUNT:
murchandamus
added
the
PR Author action required
3 participants
This BIP describes a new tapscript opcode (
OP_AMOUNT) which pushes the amount of the selected input or output to the stack.