give cluster mempool rationale

bip-ephemeralanchors.mediawiki

@@ -50,6 +50,7 @@ desired:
 * It does not solve many-party contract pinning, such as a three-party payment channel
 * It does not solve batched payments pinning if the service is unable to double-spend its own inputs. For example, an exchange may require strict separation between client funds and fee funds for security reasons.
 * In two-party smart contracts, all but two outputs must be relative-timelocked, which interferes with tooling such as [https://bitcoin.sipa.be/miniscript/ Miniscript] and smart contract composition such as making an output that is directly deposited into another smart contract or any wallet with standard address types.
+* Perhaps most importantly, it is incompatible with future improvements to the mempool, particularly [Cluster Mempools](https://github.com/bitcoin/bitcoin/issues/27677).
 
 This proposal gives a standard way to create a 0-fee "parent" transaction
 which can be fee-bumped by any wallet by introducing a special 0-value anchor output