Multisig and RBF after taproot

Question

Are there any benefits of above setup after taproot is activated that improve privacy in any way?

What is the setup?

1. 3of3 multisig address with 0.1 BTC unspent
2. Alice, Bob and Carol own the keys for it. Alice wants to send bitcoin to another 3of3 multisig address mentioned in red on the right.
3. Tx1 is RBF enabled transaction with 1 output of 0.1 BTC (Bob) and 1 input (Alice)
4. This is replaced by Tx2 with 1 output of 0.1 BTC (Carol) and 1 input (Bob)
5. Tx3 is replacement for Tx2 which has:
   • 2 outputs: Carol (0.1 BTC) and 3of3 multisig destination (0.1 BTC)
   • 2 inputs: Carol (0.1 BTC) and 3of3 multisig origin (blue)(0.1 BTC)

Why not do step 5 and skip everything else?

Difference: If someone is saving mempool logs and these transactions are present in it, Tx2 and Tx1 will be known and linked with Tx3 (all having different inputs and outputs)

How is it related to Taproot?

Using multisig in any privacy related project doesn't make sense if transactions look different from others.

Answer 1

You need to be clearer on exactly what you are seeking to keep private before you attempt to design something. There are various things you may want to keep private in an onchain or Lightning setting e.g. your total Bitcoin wealth, when you make a transaction, which address you are sending from (source), which Bitcoin address you are sending to (destination), how much you are sending, the encumbrance or script that was imposed on an output, the encumbrance or script that was satisfied to spend an output etc

If you use MuSig(2) (ignoring RBF) which is enabled by the Schnorr, Taproot soft fork you can hide the fact both when sending to and when sending from that multisignature was used because only one key and one signature goes onchain. It looks as if it was a normal single key spend and the transaction fee you need to include will be the same as for a single key spend.

RBF offers little in a privacy context (and nothing as far as I can tell in combination with a scheme like MuSig). Eventually a transaction is going onchain whether it be the original transaction or a RBF transaction. So the source and the destination are going onchain regardless and the amount sent is going onchain. The only thing that is potentially exposed or kept private is the transaction fee on a transaction that didn't make it into the blockchain. I'm not sure why you would care about keeping this information private. Perhaps including a high transaction fee leaks the level of urgency you have for a transaction being confirmed but if RBF is successful a high fee is going onchain regardless.