/
sipaPosted by sipa
Aug 20, 2026/19:19 UTC
The discussion revolves around the implementation details and advantages of using a per-input commitment versus a per-transaction (per-tx) commitment for managing cryptographic witnesses in blockchain technology. A per-input commitment is considered cleaner by some due to its straightforward approach; however, it's acknowledged that there are minimal arguments against adopting a per-transaction model. Notably, there is no significant bandwidth difference between the two methods as the commitment is omitted during serialization. Moreover, the impact on the verification process of hashing structures is minimal, potentially negligible if the hashing of per-transaction witness sets uses an aggregated hash method.
One concern with the per-input model is that it establishes a minimum weight unit requirement for all future witness types, which could be restrictive unless these witnesses rely on hash-based data. This might not be ideal for other constructions like P2MR ECC that aim for a fee profile similar to CISA, which justifies costs through batch processing efficiencies. Conversely, a per-transaction model seems more compatible with CISA-style operations, enhancing the context available during both signing and verification phases, thus integrating naturally with transaction-wide parameters.
Additionally, the conversation introduces the concept of a possible new "pq-altstack" in the interpreter, specifically for a new version of the check signature operation that would only apply to this stack. This setup suggests that the stack cannot be accessed or modified by any means other than the designated operation, streamlining security and operational clarity. This approach also helps avoid redundancy, such as duplicating public keys in both the witness/annex and the script itself, pointing towards a more efficient system architecture.
Thread Summary (11 replies)
Jul 10 - Aug 20, 2026
12 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback