ariard
April 12, 2025, 2:51am
59
I’m +1 for taproot-only CTV as an op_success for future composability. No opinion on an OP_PUSHTEMPLATE + OP_EQUALVERIFY or OP_CHECKTEMPLATEVERIFY approach.
By the way, I believe there might be some DoS surface that has been not considered in the BIP:
master ← jamesob:2025-03-ctv
If I’m understanding the biggest transaction size that can be verified by an OP_… CTV is equal to ~`MAX_BLOCK_WEIGHT`.`
While there is a limit on the max transaction size (`MAX_STANDARD_TX_WEIGHT`), this a transaction-relay only limit and if a miner is accepting non-standard tx, and there are of course some, a ~`MAX_BLOCK_WEIGHT` size transaction can be given as spending a CTV-locked input.
Moreover, currently there are only 2 caches in bitcoin core to speed up the validation of a transaction (`SignatureCache`) and (`m_script_execution_cache`). IIRC, they both commit to the transaction hash spends with by a `uint256 entry`. So if a ~`MAX_BLOCK_WEIGHT` changes for 1-bit, I think there will be a re-computation of the hash for the whole ~`MAX_BLOCK_WEIGHT`.
What prevents a peer to repeat broadcast of such ~`MAX_BLOCK_WEIGHT` tx CTV-spend to a target node ? Peer cost is just to tweaking some random 1-bit in the whole ~`MAX_BLOCK_WEIGHT` surface. Note, I believe the max size hashing you can do (i.e `OP_HASH256`) is limited by `MAX_STACK_SIZE`. I’m not sure this is considered in the BIP.