I saw this coming when LND nodes went out of sync with the chain because BTCD had coded in a size limit for witness data. With that attack the cost would be fairly high, as in, a properly encoded witness is a lotta signatures piled up, those two transactions would probably have taken at least a minute to generate, filling a whole block with this garbage would probably have taken several days at least.

But if they can just skip ahead and fill it with cheap garbage data instead then you can see how this is all connected to an error in the Segwit specification that gave no limitation on how large this piece of data could be, no ratio limit nor absolute limit.

It's an open wound in the security of the Bitcoin protocol that is the main legacy of the Blocksize wars, which resulted in the introduction of Segwit and a "hypothetical" block size increase.

The whole thing was specified so poorly that a witness data can fill the entire block!

They are just exploiting this weakness now because of the sharp increase in LN capacity and the very likely impending market pivot to the next upwards trend, while they are trying to get their favourite protocol turned into the base layer for CDBCs.

I see three possible countermeasures that will become part of the solution:

1. Make prohibiting the relaying of these transactions in mempool the default. Slow to take effect but steadily impinges on the propagation time, there's easy support out there for volunteer node runners to adopt this.
2. Add a configuration option to Bitcoin nodes that enables a manual setting to refuse transactions based on size for relay and being added to a mined block.
3. Prune the non-cryptographic parts of the witness data space being used for this scheme, I mean scam, out of the block for storage, add the handling to recognise this type of data and not allow it to waste storage space.