Hi Chris, quite an interesting proposal, but much like Martin I wonder if we shouldn't go beyond. For comparison Rusty's GSR comprises arbitrary sized integers and their associated operations, with fine-grained accounting of operations based on the operands size, so scripts stay performant and manageable.
That proposal is much further along in both design and analysis, so maybe you could join that effort for your use-cases too? Cheers, Christian On Tue, May 13, 2025 at 11:06 AM Chris Stewart <[email protected]> wrote: > > Hi Martin > > Thanks for your interest in the topic. > > >It mentions upgrading existing opcodes, which is a hardfork, not soft fork, > >at least without using a different leaf version. But it also mentions > >OP_SUCCESSX which are different opcodes > > I view 64-bit arithmetic as a feature of a wider set of consensus changes. > Here is what I think the most likely deployment story is > > >This proposal could be deployed in conjunction with any of the new opcode > >proposals in the Motivation section using Tapscript's OP_SUCCESSx > >semantics.[18] > > The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT, > OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV > > As an example, this proposal could (hypothetically) be deployed in > conjunction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx > semantics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc) > semantics. > > There’s been some discussion around deploying OP_CTV via a NOP opcode instead > of OP_SUCCESSx. I think that would be a poor choice, as it wouldn’t allow new > Script features to be shipped in parallel with the new opcode. > > I found this StackExchange post helpful in thinking through various > deployment strategies for new Tapscript-based consensus upgrades. > > >I'd also love to see analysis why stop at 64 bits and not go all the way to > >256 which could be useful for cryptography. > > In my view, there’s still a lot of uncertainty about cryptographic features > being added to Script. There's increasing discussion around quantum > computing, which raises the question of how much numerical precision we may > eventually need. I'm not opposed to extending precision further—but if we go > beyond 64 bits, why stop at 256? With OP_SUCCESSx, arbitrary precision > becomes a real option. > > I chose 64 bits because it covers what’s needed for amount locks. If someone > strongly believes that 64 bits isn't enough, I’d welcome a competing BIP and > would be happy to review and discuss it with the author. > > >Anyway, pushing amounts on the stack would be great. Though I'm surprised > >you're only proposing the sum, not individual outputs. Why? > > Good question—and slightly out of scope for this BIP. Script doesn’t support > looping, so it’s not straightforward to iterate over and sum all elements > unless the transaction structure (i.e., number of inputs or outputs) is known > in advance. > You can measure the number of stack elements with OP_DEPTH, but there’s no > way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] to sum > them all. I’m definitely open to hearing other approaches, though. > > -Chris > > > > On Mon, May 12, 2025 at 2:32 PM Martin Habovštiak > <[email protected]> wrote: >> >> Hi, >> >> the proposal seems to be quite confused about how it's going to do that. It >> mentions upgrading existing opcodes, which is a hardfork, not soft fork, at >> least without using a different leaf version. But it also mentions >> OP_SUCCESSX which are different opcodes. I think it needs some analysis. >> (leaf version seems better intuitively) >> >> I'd also love to see analysis why stop at 64 bits and not go all the way to >> 256 which could be useful for cryptography. >> >> Anyway, pushing amounts on the stack would be great. Though I'm surprised >> you're only proposing the sum, not individual outputs. Why? >> >> Good luck! >> >> Martin >> >> Dňa po 12. 5. 2025, 14:21 Chris Stewart <[email protected]> >> napísal(a): >>> >>> This soft fork proposal extends the range of numeric operands in Script >>> from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the result >>> range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to 2^127- 1. >>> >>> All existing opcodes[1] that interpret stack elements as numbers are >>> upgraded to support 64-bit parameters. >>> >>> The existing number encoding format[2] and arithmetic semantics[3] from the >>> original Bitcoin implementation are preserved, while enhancing the >>> supported precision. >>> >>> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki >>> >>> The purpose for this BIP is to lay the groundwork for introducing amounts >>> into Script. This document takes no opinion on how this is done. >>> >>> I've prototyped a few different proposals now introducing amount locks into >>> Script[0][1] and feel like this proposal is stable enough for serious >>> review. >>> >>> -Chris >>> >>> [0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5 >>> >>> [1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5 >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALxbBHW8YD-F2N9PYcAii5wXfEAPratQ6i6ke-i59pdoFczSoA%40mail.gmail.com.
