[BIP-119] Clean Up Spec of Opcode #1309

Builds on #1294.

This cleans up the spec to be 'higher level' psedocode that may be easier as a reference to parse than the C++ dump from the reference implementation.

Also makes abundantly clear the anti-DoS requirements for validation, hopefully.

cc @achow101 @petertodd

note: not that anyone should implement bitcoin in python...

I think you are changing this based on @achow101 review, @roconnor and some others, right?

My 2 sats: In order to clarify it for non-technical people, I would prefer to not use a "pythonic pseduocode", but "natural language" instead. Something like this:

please excuse any grammatical errors

Detailed Specification

A template hash, represented as a single SHA-256 hash, is obtained as follows:

• nVersion
• nLockTime
• Input count treated as unsigned integer with 32 bits (uint32)
• sequences_hash
• Output count treated as unsigned integer with 32 bits (uint32)
• outputs_hash
• The index of the current input index

sequences_hash and outputs_hash are defined as the single SHA256 of all the sequence numbers and all outputs serialized, respectively.

Validation of a OP_CHECKTEMPLATEVERIFY works as follows:

• Verify that there is AT LEAST ONE element on the stack.
• • FAIL otherwise
• Verify that the topmost stack element is 32-bytes long
• • Treat as OP_NOP otherwise
• Compute the DEFAULT_CTV_HASH as defined above
• Verify if the topmost element of the stack is equal to DEFAULT_CTV_HASH
• • FAIL if not equal

A pay to bare CTV is defined as a scriptPubKey that only contains a push of a 32 bytes value, followed by a OP_CHECKTEMPLATEVERIFY opcode, SHOULD be considered a standard type transaction.

OP_PUSH32 <32-bytes-hash> OP_CHECKTEMPLATEVERIFY

If PUSH length is not 32 bytes, validator SHOULD treat as OP_NOP, and MAY discourage use. Transactions whose spk is not strictly equal to the one above MAY be non-standard, and MAY have its usage discouraged.

Hmmm i see where you're going with it, the tricky part is making it correct to the point you can implement it from (which is the bar the spec should meet). The goal isn't to make it legible to non-technical people, the goal is to make it useful to technical people for implementations. The proposed changes, while more readable, are no longer sufficient to implement the BIP against and introduce some vulnerabilites.

I'll churn on this a bit! I don't think you're directionally wrong, it's just difficult to do well.

Yeah I mean, it will also help technial people.

it's just difficult to do well

agreed! But it's doable

@JeremyRubin You could take the Taproot BIPs as an example, see 340

yep, good pointers. I think 340 is a bit higher quality (edit: than 341 or 342) since it's a cryptographic spec, but the BIP can't be implemented AFAICT from the other BIPs since they lack a lot of little details that are still consensus critical.