policy: Enforce TRUC restrictions by default

[connorslab]

Change the native default of mempooltruc from accept to enforce. This makes the existing TRUC checks apply by default: version-3 transactions may have at most one unconfirmed parent and one child, must obey version inheritance rules, and are subject to the TRUC transaction and child size limits. Transactions violating those checks are rejected. corepolicy=1 already selects enforcement; its redundant override is removed.

The motivation is to enforce the restricted unconfirmed topology used by TRUC's fee-bumping model. For an Ark or Lightning transaction construction that relies on those restrictions, enforcing them locally prevents acceptance of conflicting transaction graphs outside that model. This is a policy-default proposal, not a claim that Ark or Lightning generally requires this setting, or that local enforcement guarantees network-wide fee-bumping behavior.

TRUC and ephemeral dust are separate policies. This PR does not introduce ephemeral anchors, CPFP, or the ephemeral-dust spending rules. #438 addresses a specific interaction between the existing ephemeral-dust zero-fee check and the automatic dust penalty. #446 addresses the separate mining-priority fee floor. Neither change is bundled here, and this PR does not establish that all three are prerequisites for a protocol.

There is also an existing mode-dependent fee rule in this branch: MemPoolAccept::PreChecks exempts version-3 transactions from the individual minrelaytxfee check only when TRUC is enforced (unless that rejection is explicitly ignored). Package fee checks still apply. Changing the default selects that existing behavior too; it is distinct from adding ephemeral-anchor support.

Explicit accept, reject, and enforce settings remain honored with either corepolicy setting. Mining policy and dust-penalty defaults are unchanged. The patch updates the default, source help, a hand-written release note, and tests; no generated files are changed.

Tests cover both corepolicy settings, explicit modes, version inheritance, and successful zero-fee-parent package submission under default and explicit enforcement. These tests establish the tested policy behavior, not end-to-end Ark or Lightning compatibility. Linux validation passed at 0f72365: build, policy unit and functional tests, and integration with #438. Subsequent changes only clarify prose. One squashed commit.

[luke-jr]

The motivation is to enforce the restricted unconfirmed topology used by TRUC's fee-bumping model. For an Ark or Lightning transaction construction that relies on those restrictions, enforcing them locally prevents acceptance of conflicting transaction graphs outside that model.

This is a flawed concept. Policy by definition cannot be relied on, and attempting to rely on it for any security is fundamentally broken.

[connorslab]

This is a flawed concept. Policy by definition cannot be relied on, and attempting to rely on it for any security is fundamentally broken.

You’re right that policy can’t provide a protocol security guarantee. My argument for this change is that enforcing TRUC restrictions by default can make fee replacement more predictable on participating nodes.

In testing, both modes accepted replacing a 1,000-sat child with a 2,000-sat child. Under accept, adding a descendant paying 10,000 sats blocked that replacement because it also had to cover the descendant’s fee. Under enforce, the descendant was rejected and the replacement succeeded.

I’d like to pursue this as a fee-bumping policy improvement for Bitcoin payments, with Ark as one use case. The question is whether limiting descendant-driven replacement costs justifies restricting those transaction chains by default. What additional evidence would you want to see to support that change?