Implement BIP 345 validation (OP_VAULT)

[jamesob]

The usual cross-port process from bitcoin#26857.

BIP: bitcoin/bips#1421

[michaelfolkson]

I'd like to (attempt to) follow the iteration of the vault design (that uses OP_VAULT and other new opcodes) and rationale for changes to that vault design. And this perhaps might not get tracked in the OP_VAULT BIP as that is specifying the new opcode(s) with less of an emphasis on the different vault designs using these opcodes.

@instagibbs stated at the Contracting Primitives meeting that the current vault implementation uses:

OP_VAULT_RECOVER (sweep to cold like func), OP_VAULT (simple OP_TLUV) and a vault would use OP_CTV for final step

Are we using OP_VAULT and OP_TLUV terminology interchangeably now? And where would be best to track the evolution of the actual vault design? Here? The BIP draft? A Bitcoin StackExchange post?

[jamesob]

All comments addressed, thanks @sanket1729 @ajtowns.

[DrahtBot]

🐙 This pull request conflicts with the target branch and needs rebase.

[ajtowns]

This violates the "each SCRIPT_VERIFY_foo flag is a soft-fork" convention (see bitcoin#10699 and bitcoin#26439): if you have a correct OP_VAULT invocation, it will be invalid with script-verify flags set to DISCOURAGE_OP_SUCCESS but valid with them set to DISCOURAGE_OP_SUCCESS | VAULT.

I think this should instead be:

    if (IsOpSuccess(opcode)) {
        if (opcode == OP_VAULT || opcode == OP_VAULT_RECOVER) {
            if (flags & SCRIPT_VERIFY_DISCOURAGE_VAULT) {
                return set_error();
            } else if ((flags & SCRIPT_VERIFY_VAULT) == 0) {
                // retain OP_SUCCESS behaviour if soft-fork hasn't activated
                return set_success(serror);
            }
        } else {
            if (flags & SCRIPT_VERIFY_DISCOURAGE_OP_SUCCESS) {
                return set_error(serror, SCRIPT_ERR_DISCOURAGE_OP_SUCCESS);
            }
            return set_success(serror);
        }
    }

[michaelfolkson]

Why was this closed @jamesob?