This attack can be performed only about 86 times per block given the time it takes for this to propagate to 50% of the network. The cost for this attack is 68576 satoshi, assuming a 50% chance the 100k transaction gets mined. However, the 50% chance assumption is almost wrong, making the cost for the transactions much lower at 18576, i.e., 463x lower than just sending 1sat/vbyte txs under optimal conditions.To address the DoS potential directly, Rusty Russell suggests implementing a solution that delays processing of transactions by 30-60 seconds if a replacement doesn't meet certain criteria but increases the feerate by at least minrelayfee. This would eventually result in replacing-by-fee (RBF) of a larger transaction but it would take longer. It should be easy to implement as similar timers will be required for dandelion. Christian provided more detailed propagation statistics showing that larger transactions propagate slower, but only by a factor of 2.5 or so.There have been discussions on the Bitcoin development mailing list regarding the enforcement of Replace-By-Fee (RBF) on spending transactions using OP_CSV with a relative locktime of zero. Marco Falke points out that if the parent is RBF, the child inherits it. However, Matt Corallo points out that you can block RBF with a large-but-lowball tx. Peter Todd explains that the rule preventing bandwidth usage DoS attacks on the mempool is why the rule exists, and dropping it would allow attackers to repeatedly broadcast and replace transactions to use up tx relay bandwidth for significantly lower cost than otherwise.Luke Dashjr suggests having a consensus rule that a bit must be set for an expected behavior and the bit may only be set when the last output is exactly 00000000000000000181. Rusty Russell believes the best mitigation against UTXO bloat is to make the fees as low as possible, put a CSV delay on the to-remote output, and attach more value to the OP_TRUE output. However, it turns out they probably don't want an OP_TRUE output nor P2SH, because then the spending tx would be malleable. So P2WSH is preferred. Russell suggests that the network benefits from using OP_TRUE outweighs the risk, but it would be nice if OP_TRUE P2WSH spends were always considered RBF.Luke and ZmnSCPxj discuss the possibility of having multiple dummy outputs in a transaction. They question if there is any legitimate reason for having multiple such outputs. However, they consider the use of SIGHASH_SINGLE flag, which may require adjustment of transaction inputs if a dummy output is added as the first output. Despite this, it is noted that the discussion is focused on transaction serialization, and it is unclear whether SIGHASH_SINGLE is affected by the presence of dummy outputs.ZmnSCPxj clarifies that the template-script idea for Lightning does not make it mandatory to spend in the same block, but rather the UTXO would cease to be valid after that block. Luke and the rest of the list thanked ZmnSCPxj for the clarification and stated that their previous rumination about having two options for Lightning was incorrect. For Lightning, they simply need to add a 0-value OP_TRUE output always to transactions that require both side signatures. This 0-value output will serve as a "hook" for adding more fees if needed.Rusty Russell proposes including a 546 satoshi OP_TRUE output in commitment transactions for the Lightning network to solve the problem of predicting future fees. This would allow for minimal fees and the use of CPFP.In a recent discussion on the Bitcoin-dev mailing list, Olaoluwa Osuntokun asked about the downsides of using p2wsh. The immediate implementation of this method seems to be more practical as compared to policy changes which can be quite fuzzy and would require a uniform rollout for the propagation of commitment transactions. Rusty expressed his expectation that the policy changes will eventually be implemented despite the challenges. He also mentioned his annoyance with people who work around issues without bringing them to his attention.Johnson Lau proposed creating a standard for "0 fee tx with exactly one OP_TRUE output" to ensure that CPFP would always be needed and the output wouldn't pollute the UTXO set. However, it was noted that this approach wouldn't propagate.Lau suggested using ANYONECANPAY to sign the transaction instead, allowing for more inputs to be added for fees without requiring any protocol changes. However, this was rejected due to the fact that it