bip-0325: clarify the OP_TRUE challenge special case

[kallewoof]

While OP_TRUE challenges have been implicitly accepted until now, it was never defined exactly how these should be solved. This adds an exception for the case where the challenge is OP_TRUE, that the solution must be absent. I.e. not even an empty signet commitment may be present, or the block should be considered invalid.

Pros: this means a signet node with challenge OP_TRUE works exactly the same as testnet/mainnet, in terms of block generation (i.e. generate* RPC functions in Bitcoin Core can be used out of the box).

[kallewoof]

@luke-jr At your convenience, please merge.

[harding]

@kallewoof sorry I didn't review this when it was open, but the text in the patch doesn't match the OP in your PR description. The PR description states "where the challenge is OP_TRUE, that the solution must be absent" (my emphasis). The patch says, "if a block's challenge is e.g. OP_TRUE (0x51) [...] the block is also considered valid if the signet commitment is absent."

In short, I read the first as "MUST be absent" and the second as "MAY be absent".

I don't think the difference matters if the only goal is for things like the generate RPC to be usable---but if the goal is also for existing tools to be able to validate OP_TRUE signets, then perhaps "MUST be absent" is required.

[maflcko]

existing tools will ignore the commitment anyway, so if it is absent or present shouldn't matter, no?

[harding]

@MarcoFalke I think you are correct and I see now that there was a resolved discussion on this PR between you and @kallewoof about this, which explains the reason for the discrepancy between the PR description and the actual change. Thanks!