BIP-0444: Taproot and Script Limits to Prevent Arbitrary Inscriptions

justinfilip commented at 4:17 am on October 15, 2025: none

Summary: soft-fork proposal + policy defaults to prevent large arbitrary inscriptions, reduce UTXO/script bloat.

Highlights:

Consensus: tapscript push-run cap (256), IF/NOTIF ban, script push cap (256, BIP16 redeem exception), control block cap (257), SPK size cap (34), undefined witness/taproot versions invalid.

Policy: per-input v1 witness cap (1024 default), tapscript IF ban + push-only IF-body (80), push-run (256), control block (257), SPK size (34), push cap (256), unknown witness off by default.

Deployment: BIP8 with one-year signaling window and delayed min activation.

Link to discussion thread: https://gnusha.org/pi/bitcoindev/CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com/T/#mb71350c5dfb119efeb92c5ee738b6c8225bf15b6

Note: open to edits per BIP editors’ feedback.

BIP: Taproot push-only limits (consensus+policy) to prevent inscription payloads 219cd97e8f

BIP-0444: Taproot Push-Only Limits to Prevent Arbitrary Inscriptions 7f85200106

Rename BIP to bip-0444; update text to match implemented policy and consensus scope fff1fda73c

vostrnad commented at 4:30 am on October 15, 2025: contributor

What’s the policy on accepting BIPs that are largely written by an LLM?

jonatack commented at 5:09 pm on October 15, 2025: member

Please study BIP 2 for the process; notably, do not self-assign a BIP number
Are you one of the participants in the linked mailing list discussion?
Is this your original work, or does it use LLMs?

jonatack marked this as a draft on Oct 15, 2025

kwsantiago commented at 5:21 pm on October 15, 2025: none

Critical blockers:

Rule 2 vs 3 contradiction: You both ban OP_IF entirely (Rule 3) and define limits for OP_IF branches (Rule 2). Pick one approach.
Rule 7 breaks Bitcoin’s upgrade path: Banning undefined witness versions removes the forward compatibility that Segwit/Taproot were designed for. This prevents future soft forks and contradicts BIP141/342 philosophy. OP_SUCCESS* ban breaks BIP342’s explicit upgrade mechanism.
Missing parameter: Pseudocode references MAX_V1_PUSHONLY_WITNESS_ELEM but it’s never defined in your parameters section.
Rule 4 is too restrictive: 257-byte control block limit caps Taproot trees at ~128 leaves (7 merkle levels). BIP341 allows 4129 bytes for a reason: large trees (1000s of spending paths) are legitimate use cases.
Pseudocode has bounds-checking bugs: Multiple off-by-one errors and missing overflow checks in PUSHDATA parsing which could cause consensus splits.

Broader concerns:

Deployment timeline is too aggressive (1-year signaling insufficient for this magnitude of change)
No ecosystem impact analysis for miners, Lightning, existing contracts etc
Test vectors incomplete (no hex examples despite specification requiring them)

This BIP needs substantial revision before considering for implementation. The forward-compatibility break alone (Rule 7) should be a non-starter.

justinfilip commented at 7:26 pm on October 15, 2025: none

@jonatack

Please study BIP 2 for the process; notably, do not self-assign a BIP number

Just finished reviewing. Understand the misstep.

Are you one of the participants in the linked mailing list discussion?

I am not, but I don’t think it should matter, so long as it has been discussed by others.

Is this your original work, or does it use LLMs?

Mostly LLM. When using LLMs in my areas of expertise, it works really well for me. It decreases development time and increases the scale of workload I can take on as an individual actor. The problem here is, the bitcoin codebase and developer community SOPs are not my area of expertise.

Therefore, my approach is to take Luke’s proposal and discussion from the mailing list and get the ball rolling - then lean on the review process to get it right. Very possible there are other efforts I’m not aware of, but generally I don’t see others taking action and I do see Luke implying he is tired of being the one to propose and develop fixes, specifically requesting other developers to step up to the plate. @kwsantiago

Critical blockers:

Rule 2 vs 3 contradiction: You both ban OP_IF entirely (Rule 3) and define limits for OP_IF branches (Rule 2). Pick one approach.

Good point. The BIP conflates temporary policy with intended consensus.

For clarification:

The narrower Rule 2; ban only push-only IF/NOTIF branch bodies exceeding 80 bytes, while allowing legitimate conditional logic with non-push opcodes.
Rule 3 (total IF ban) could be a temporary consensus measure that self-expires after 1–2 years if we want extra caution during the transition.

Rule 7 breaks Bitcoin’s upgrade path: Banning undefined witness versions removes the forward compatibility that Segwit/Taproot were designed for. This prevents future soft forks and contradicts BIP141/342 philosophy. OP_SUCCESS* ban breaks BIP342’s explicit upgrade mechanism.

Yes, I think it would be a good idea to shut the door. I could be wrong there, but Luke seems sure of the viability and I am mostly leaning on his perspective. Generally, I think it would be great if we reduce bitcoin’s usage to just money and leave it alone from that point forward. (Edit: other than bug fixes like the time bug, client UI/UX enhancements, etc)

Missing parameter: Pseudocode references MAX_V1_PUSHONLY_WITNESS_ELEM but it’s never defined in your parameters section.

I can verify and fix that depending on what direction we’re going.

Rule 4 is too restrictive: 257-byte control block limit caps Taproot trees at ~128 leaves (7 merkle levels). BIP341 allows 4129 bytes for a reason: large trees (1000s of spending paths) are legitimate use cases.

Again leaning on Luke’s perspective there. I personally would like to know what those legitimate use cases are, if there are some.

Pseudocode has bounds-checking bugs: Multiple off-by-one errors and missing overflow checks in PUSHDATA parsing which could cause consensus splits.

I can verify and fix that depending on what direction we’re going.

Broader concerns:

Deployment timeline is too aggressive (1-year signaling insufficient for this magnitude of change)

No disagreements with changing that depending on what direction we’re going, just a placeholder.

No ecosystem impact analysis for miners, Lightning, existing contracts etc

That is true.

Test vectors incomplete (no hex examples despite specification requiring them)

Can iterate and improve.

This BIP needs substantial revision before considering for implementation. The forward-compatibility break alone (Rule 7) should be a non-starter.

I think that rule was made to be broken so long as it doesn’t cause a hard fork and retains bitcoin’s purpose as money (without arbitrary data inclusion).

My overarching question is: are there other developers out there who are willing to go on this path with me? Or are we going to make Luke do it? And then what from that point?

Appreciate all the feedback.

jonatack commented at 8:06 pm on October 15, 2025: member

What’s the policy on accepting BIPs that are largely written by an LLM?

Good point. We are discussing an update to BIP 3 to cover these situations. For now, it seems at a minimum reasonable to state that:

Use of LLMs violates community norms and please don’t waste our time (credit to @kanzure)
Authors must proactively disclose any use of LLMs

jonatack commented at 8:16 pm on October 15, 2025: member

@justinfilip Thank you for your replies. I think it’s best to close this: A number was self-assigned, this content didn’t involve cooperation or collaboration with the contributors to the required ML discussion, and indeed it is mostly LLM-generated, which is a non-starter with respect to community norms and not wasting the valuable time of people working on these critical topics. We’ll work to clarify these further for future submissions. Regards.

jonatack closed this on Oct 15, 2025

bitcoin deleted a comment on Oct 15, 2025

kanzure commented at 8:27 pm on October 15, 2025: contributor

Use of LLMs violates community norms and please don’t waste our time (credit to @kanzure)

Wasting the community’s time violates our community norms. LLM slop is therefore also a norm violation. However, it doesn’t matter if it’s LLM generated slop or non-LLM slop, slop is still slop.

Therefore, my approach is to take Luke’s proposal and discussion from the mailing list and get the ball rolling - then lean on the review process to get it right.

this is not incentive compatible behavior. Also it’s not how the BIP process works. Finally, I think it’s contrary to your interests because it creates even more work (plus a bias towards defection) for the next person to sort through in order to achieve your goals,.

luke-jr commented at 10:10 pm on October 15, 2025: member

Rule 7 breaks Bitcoin’s upgrade path: Banning undefined witness versions removes the forward compatibility that Segwit/Taproot were designed for. This prevents future soft forks and contradicts BIP141/342 philosophy. OP_SUCCESS* ban breaks BIP342’s explicit upgrade mechanism.

Rule 4 is too restrictive: 257-byte control block limit caps Taproot trees at ~128 leaves (7 merkle levels). BIP341 allows 4129 bytes for a reason: large trees (1000s of spending paths) are legitimate use cases.

Note these are NOT critical blockers.

gmaxwell commented at 1:18 am on October 16, 2025: contributor

Note these are NOT critical blockers.

hundreds to thousands of spending paths were a specifically advertised and discussed part of the proposal, it’s what gives you some forms of efficient sparse multisig. Also just blocking it confiscates coins.

justinfilip commented at 7:48 pm on October 16, 2025: none

However it got here, with the benefit of hindsight, it’s time to do the right thing. It’s going to happen whether I’m involved or not, so you should wake up and get to work on Core. The games being played everywhere are pathetic.

BIP-0444: Taproot and Script Limits to Prevent Arbitrary Inscriptions #2005