I've looked a bit closer into Luke's Bitcoin Knots changes.
The probably most relevant change
this pull request which changes the
-datacarriersize policy. If a node limits the maximum amount of data (like it's the case by default), it puts the "Ordinal-style" transactions which "obfuscate" data behind OP_FALSE and OP_IF on the same terms than OP_RETURN transactions. If I interpret right this would limit these "arbitrary data" items to 80 bytes, just like OP_RETURN data items, for the transaction to be relayed by default.
In general, this is a policy I could approve because it's "technologically neutral", much in contrast to earlier attempts to "patch" Bitcoin to "solve" the problem which "filtered" only Ordinals-type inscriptions by hard-coding them into the client.
However, it wouldn't help much against the BRC-20 issue. It seems in these the size of the "content", which is probably identic with "arbitrary data" (although I'm not sure if the MIME type and other metadata has to be added, but that are also only a few bytes), is only between 50 and 60 bytes*, see
this BRC-20 transaction for an example. It would help against big NFTs but these aren't the reason for the current congestion. However, even in this case, they could switch to the method used in Doginals for the bigger NFTs.
I also think that Peter Todd is right in the comments that this could lead to smaller miners' competitiveness getting reduced, although one could say the same thing if the problem was with big OP_RETURN data items.
There are two more
changes relevant for Ordinals/Inscriptions:
An additional -datacarriercost option has also been added to avoid giving the "segwit
discount" to aribitrary data (and can be increased to require datacarrier transactions
to pay higher fees).
As far as I understand this only would be used by miners.
The question here is: would miners use it or not? Would miners that use it have disadvantages regarding those not using it? Would they lose money replacing Ordinals-style transactions with "normal" transactions which pay less fees? I guess the answer is yes and thus not much miners would use this - if not, I'd be grateful for an explanation
The spam filters limiting smart contract code sizes for pre-Segwit and Segwit
"v0" scripts have been expanded to also cover Taproot. Since the sizes were
inconsistent, the lower size of 1650 which actually had a rationale has been
used as the default for this release. The size limit can be adjusted with the
new -maxscriptsize option. If you know of any legitimate scripts that are
larger than the default, please report a bug.
I think here the same thing applies to the
-datacarriersize change. It's not something I would oppose but it wouldn't help to fight the BRC-20 spam as the sizes of these are much smaller.
*This doesn't mean that BRC-20 isn't terribly inefficient. A protobuf-based format could store the same values in less than 20 bytes, I guess. And the problem with the "2 transactions per transfer", which results in >110 bytes of overhead, remains.