nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc
For op_cat, its purely byte weighted for limits? Like a const somewhere?
It doesnot use the modeling stuff discussed toward the end by Andrew?
nostr:npub1emdtsxly9m68m00x206t574jttp65vk0c2m89ms038q047yz7ylqcac9aw nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8
PS poelstra nostr? 🤔
So hash a thing. Cat to next thing. Repeat hash. Repeat.
I follow how we can determine inclusion in a Merkle tree.
Still curious how this differs from Taproot? Might hear it again but pondering aloud.
In the current proposal for CAT (BIP-420), its Just Another Opcode. The check is that it fails if you try to create a stack element longer than 520 bytes.
In the proposal from nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s , there is a variable operations budget (varops) and if you exceed the budget, your script is invalid. In this model, the “cost” for an operation is based on what kind of operation it is (add is cheaper than mul) as a function of its input length(s).
Where did 520 come from? Its not evenly divisible by 64 or 32?
