Sorry to necropost here. From the original OP:
… this is important as we should be looking to support what users are attempting to make, where reasonable, to avoid out-of-band fee solutions.
This conversation is largely around fee inputs (whether exogenous or endogenous). However, there may be another type of transaction fee which we may need to consider: explicit fee outputs.
I am referring to a fee paid to a miner where the fee is represented as a separate output in the transaction. Let us call such fee outputs “explicit” fees, as opposed to usual “implicit” fees ( = sum of inputs - sum of outputs).
Of course, transactions with explicit fee outputs take up more block space, so the explicit fee must account for the miner’s opportunity cost.
But why are out-of-band explicit-fee outputs bad? I think one reason which is often not considered by non-experts is that out-of-band explicit fee outputs are not, unless carefully constructed, subject to the coinbase maturity restrictions.
The coinbase maturity is actually a crucial component of Bitcoin’s security. We should naturally want as many of the block’s fee sats as possible flowing into those coinbase (or equivalently locked – see below) outputs.
I wonder whether, in a post-subsidy bitcoin world, or a world where the chain is being re-organized more than usual, users (especially receivers) may find themselves needing to adopt explicit anyone_can_spend fee outputs which emulate the coinbase maturity semantics. Maybe a simple output script of something like 100 op_csv.
In such a world, I suppose a receiver could use CPFP to attach such an output to their inbound transactions.