What happens after we "run out" of script flags?

Implementation
1

Script flags are currently represented in the bitcoin core code base as 32 bit unsigned int.

If hypothetically we were to add 11 more then it’s pretty much over:

SCRIPT_VERIFY_CHECKTEMPLATEVERIFY = (1U << 21),
SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_CHECKTEMPLATEVERIFY = (1U << 22),
SCRIPT_VERIFY_DISCOURAGE_CHECKTEMPLATEVERIFY = (1U << 23),
SCRIPT_VERIFY_CHECKSIGFROMSTACK = (1U << 24),
SCRIPT_VERIFY_DISCOURAGE_CHECKSIGFROMSTACK = (1U << 25),
SCRIPT_VERIFY_INTERNALKEY = (1U << 26),
SCRIPT_VERIFY_DISCOURAGE_INTERNALKEY = (1U << 27),
SCRIPT_VERIFY_PAIRCOMMIT = (1U << 28),
SCRIPT_VERIFY_DISCOURAGE_PAIRCOMMIT = (1U << 29),
SCRIPT_VERIFY_CAT = (1U << 30),
SCRIPT_VERIFY_DISCOURAGE_CAT = (1U << 31),

So what do we do after? Increase flags to 64 bit?

2

This is a Bitcoin Core implementation detail. The script flags mechanism itself is not consensus critical. A larger integer or another mechanism altogether could be used to instruct the script interpreter what validation should be performed.

1 Like
3

Yes, I know it’s not consensus critical, in that sense. So it’s not expected to be a breaking change for other projects? If it’s fully contained to core and not a huge deal to change the type, then it’s not a big deal, I guess. Right now LNHANCE only uses 3 flag bits. But since a lot of people seem to prefer C3PO, I’m looking at options for concurrent overlapping activations.

4

As you already know i believe it’s entirely premature to talk about activation of anything, that said i don’t think anyone working on a soft fork proposal should be concerned about the “remaining number of script flags” whatsoever.

2 Likes
5

After giving it a try, I don’t think it’s a super viable path to change the type. It’s a lot of change that breaks easy code portability, it compiles without problems while certainly bugged. flags_t could be ScriptFlags, or whatever for better readability.

edit: I did experiment with using typedef std::bitset<64> flags_t; for script flags, it could be a good solution long term, but the imminent pain is even worse. Also doing so noticed that the flags as unsigned int are indeed exposed on APIs. and honestly I have no idea what to do with that.

edit: Context for picking up this thread again: LNhance + C3PO has enough script flags left, but I became increasingly convinced that C4 should also be part of the conversation, because activating CAT without CCV carries the likelihood of greater annoyance with new opcodes as opposed to the immediate desire to soft-fork in further optimizations.