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

**URL:** <https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382>\
**Category:** Implementation\
**Tags:** softfork\
**Created:** [January 12, 2025, 7:29pm UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382 "2025-01-12T19:29:48Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\
**Post date:** [January 12, 2025, 7:29pm UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382/1 "2025-01-12T19:29:48Z")

</div>

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:

```c++
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?

---

<div class="post-metadata">

**Author:** ![AntoineP](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/antoinep/32/483_2.png) [@AntoineP](https://delvingbitcoin.org/u/AntoineP)\
**Post date:** [January 12, 2025, 11:08pm UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382/2 "2025-01-12T23:08:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\
**Post date:** [January 12, 2025, 11:32pm UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382/3 "2025-01-12T23:32:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![AntoineP](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/antoinep/32/483_2.png) [@AntoineP](https://delvingbitcoin.org/u/AntoineP)\
**Post date:** [January 13, 2025, 12:00am UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382/4 "2025-01-13T00:00:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![moonsettler](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/moonsettler/32/38_2.png) [@moonsettler](https://delvingbitcoin.org/u/moonsettler)\
**Post date:** [January 25, 2025, 10:39pm UTC](https://delvingbitcoin.org/t/what-happens-after-we-run-out-of-script-flags/1382/5 "2025-01-25T22:39:55Z")

</div>

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.

> **[Comparing lnhance-26.x-deploy...lnhance-26.x-deploy64 · lnhance/bitcoin](https://github.com/lnhance/bitcoin/compare/lnhance-26.x-deploy...lnhance:bitcoin:lnhance-26.x-deploy64)**
>
> Bitcoin Core integration/staging tree. Contribute to lnhance/bitcoin development by creating an account on GitHub.