Receiver Chooses Fee

Because grin is unique in that the receiver of a transaction must participate in the creation of the tx, why not let the receive choose the fee? It could make sense for the customer to not worry about fees and just send X amount. The merchant can concern themselves with the fee amount and pay the fee. This means the tx is built such that it is X - F amount where X is sender’s amount and F is fee. Another way of saying this is that the F is inclusive of the sender amount rather than exclusive (which is typical for other utxo blockchains).

2 Likes

I’ll copy my answer from keybase

I do think that what is confusing is that we are talking about the “manual confirm”. This is just one way to introduce interactive step2. The “manual confirm” enables the control of incoming outputs (which is imo a big deal). But we could come up with a different reason for interaction at step2 for instance we could let the receiver pick their own fee. The common thing they have is that they require step2 to be interactive. Step2 being interactive is what makes the SRS/RSR flows coherent and much more flexible. The “manual confirm” is just one example as to why you might want interaction at step2, but there are plenty of reasons why it would make sense to have that step interactive e.g. payjoin input selection, manual confirmation, incoming output control, custom fee selection, memo payment proofs etc.)

TLDR: it all depends whether step2 in the transaction flow is user-interactive or not. New options open up when we make it interactive, including each party picking their own fees.

Or how about letting each party pay the fee for their part of the tx? Sender pays for the inputs they spend, receiver pays for the outputs they receive (and input they spend in case of payjoin), while they split the cost of the kernel that they both contribute to.

5 Likes

This also helps to obfuscate the direction of the transaction right? If that is the case, I am really strongly in favor, it would be a great privacy gain.

The transaction looks exactly the same - the kernel has the same fee value. The only difference is from which outputs you subtract the fee and when both pay their share of fees, it is subtracted from both outputs. It doesn’t help the obfuscation in any way unfortunately.

1 Like

I thought the receiver would include an output of his own for the fee, in which case it would make it unclear who is sending to who, so in this case the transaction fee is subtracted from the output created for the receiver?

Yes, just like we subtract it from the sender today. Anyone could create more outputs, it doesn’t really help that much with obfuscation - unless you do the fan-out idea I described in some post, but that has bloating issues.

1 Like

I believe he meant that the receiver would include his own input from which the fee would be paid (instead of subtracting it from his receiving value) - so doing a payjoin. This does make it a 50-50 who the sender is but I don’t see any advantage in doing it this way so i would prefer if payjoins were optional even in the “pay your own fees” scenario

This seems logical and fair.