Can FSS RBF avoid requiring an extra utxo by sending the change back to the sender's address?

[Chronos]

As I understand First Seen Safe Replace By Fee (FSS RBF), both the destination and the change address must remain unchanged when replacing a transaction. This means a new input is required in order to increase the fee. Can this be avoided by sending the change back to the receiving address? (Note: loss of privacy/security due to address reuse)

Example: Sending from A to X and change address Y. To bump the fee via FSS RBF, we must send from A and B to X and change addresses Y and Z.

Idea: Sending from A to X and change address A. To bump the fee via FSS RBF, we send from A to X with less change going to A.

I think it's a bad idea because of the address reuse, but I wonder if it's theoretically possible.

 

[dgenr8]

Nodes can't tell whether this is FSS safe or not, because they don't know which address is the change address. It is indistinguishable from paying less to the recipient.

 

[Chronos]

But shouldn't nodes be able to tell, because it's a guarantee that any output that matches the public key of one of the inputs is definitely a change address?

 

[dgenr8]

You can author your tx in such a way as to pay change to your input address, as you describe. But this tells the world how much money you still have, and wallets don't do it. Privacy-wise, you want to use a fresh change address to force watchers to deal with 2x as many potential scenarios in trying to figure out where your money is.

 

[Chronos]

Yes, I understand the privacy implications. That doesn't answer the question, though. Are you saying that FSS RBF could work this way?

 

[dgenr8]

Ok I missed that A was the input too. Sure it works from the standpoint of being safe for the receiver.