0

rbf-multisig

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.

4
  • I don't really see what taproot has to do with this. Jul 25 at 23:04
  • I was assuming transactions involving multisig will look similar to other transactions after taproot. Is that incorrect?
    – Prayank
    Jul 25 at 23:09
  • Possibly, yes, if MuSig is used by the wallets in question. But that still doesn't have anything to do with RBF. Jul 25 at 23:09
  • Yes its not related to RBF. I am trying to mix two things to see if this can together work to improve privacy.
    – Prayank
    Jul 25 at 23:11
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.

1
  • I have edited the question and added more information.
    – Prayank
    Jul 26 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.