> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts?
That's an interesting idea, but an attacker can create a local conflict in your mempool
and then send the preimage tx to make hit recentRejects until next tip so
when the rejection code with conflict is received transaction isn't going to be fetched.
Of course you can make an exception for this, but seems a DoS vector...
And also if you have a private full-node and connect only to 8 outbounds, an attacker
can do a bit of tx-relay topology discovery and blind your tx-relay peers too...
I think p2p/mempool hardening measures will only make attack harder but not erase it, we
should avoid tie too much the security model of Lightning on a given p2p topology. If you don't
do manual peering (whitelist,addnode), this one may change without visibility (like stale tip).