However, implementation complexity has led to channel failures in lightning, and RBF/CPFP anti-DoS rules have made option (b) difficult. A counterparty can prevent confirmation of/significantly increase the fee cost of confirming a simplified lightning design with pre-signed commitment transaction A by chaining a large-but-only-moderate-feerate transaction off of this anyone-can-spend output. Lightning's security model assumes the ability to get such commitment transactions confirmed in a timely manner, but the current CPFP security model does not address third parties delaying its confirmation. To partially-address the CPFP security model considerations, a next step might involve tweaking Lightning's commitment transaction to have two small-value outputs which are immediately spendable, one by each channel participant, allowing them to chain children off without allowing unrelated third-parties to chain children. As an alternative proposal, transactors could mark their transactions as "likely-to-be-RBF'ed", which could enable a relay policy where children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". Note that this clearly relies on some form of package relay, which comes with its own challenges.