checksequenceverify – What prevents an arbitrarily excessive nSequence worth when spending an OP_CSV output?

I’ve gone by means of the numerous associated questions right here on stack alternate and clearly learn BIP68 and BIP112, however I nonetheless can not appear to come back to a transparent reply for the next query: what’s stopping a transaction that spends an output encumbered by OP_CSV from setting an arbitrarily excessive nSequence worth?

Lets say the next situation:

• txA has a single output encumbered by 10 OP_CSV, which means this output can solely be included in a transaction that’s mined 10 blocks after txA is confirmed
• txB spends a single enter, which is the one output created from txA

The operate that performs the verify is

template 
bool GenericTransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
{
    // Relative lock occasions are supported by evaluating the handed
    // in operand to the sequence variety of the enter.
    const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;

    ...
    omitted logic
    ...

    // Now that we all know we're evaluating apples-to-apples, the
    // comparability is a straightforward numeric one.
    if (nSequenceMasked > txToSequenceMasked)
        return false;

    return true;
}

Why ought to the spending transaction not have the ability to set nSequence for the enter in such a manner that txToSequenceMasked is at all times greater than nSequenceMasked? What precisely is stopping this? I really feel like I am lacking one thing apparent right here.

Hopefully my query is sensible, thanks!

I’ve gone by means of the numerous associated questions right here on stack alternate and clearly learn BIP68 and BIP112, however I nonetheless can not appear to come back to a transparent reply for the next query: what’s stopping a transaction that spends an output encumbered by OP_CSV from setting an arbitrarily excessive nSequence worth?

Lets say the next situation:

• txA has a single output encumbered by 10 OP_CSV, which means this output can solely be included in a transaction that’s mined 10 blocks after txA is confirmed
• txB spends a single enter, which is the one output created from txA

The operate that performs the verify is

template 
bool GenericTransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
{
    // Relative lock occasions are supported by evaluating the handed
    // in operand to the sequence variety of the enter.
    const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;

    ...
    omitted logic
    ...

    // Now that we all know we're evaluating apples-to-apples, the
    // comparability is a straightforward numeric one.
    if (nSequenceMasked > txToSequenceMasked)
        return false;

    return true;
}

Why ought to the spending transaction not have the ability to set nSequence for the enter in such a manner that txToSequenceMasked is at all times greater than nSequenceMasked? What precisely is stopping this? I really feel like I am lacking one thing apparent right here.

Hopefully my query is sensible, thanks!