Posted by Ethan Heilman
Oct 21, 2023/20:24 UTC
The email conversation is about the tapscript opcode and its limitations. The sender, Ethan, clarifies that the limit mentioned in the previous email is not unique to tapscript but rather a feature of the OP_CAT opcode. Tapscript enforces a 520 byte element size, which ensures that there are no concerns about OP_CAT creating very large stack elements.Ethan acknowledges Greg's input on this matter and expresses his gratitude for pointing out that the limit was added in the same commit that removed OP_CAT. He admits that he had thought the limit was a more recent addition. Upon reading through the commit, Ethan discovers that it also reduced the size limit on inputs to arithmetic operations (nMaxNumSize) from 2064-bits to 32-bits. He mentions that he had always assumed it was 32-bits from the beginning.Ethan concludes the email by expressing his amusement at the idea of having math opcodes that support 2064-bit inputs and outputs. He thanks Greg for bringing these details to his attention.(Note: The farewell part of the email has been ignored as per the instructions.)
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback