Quote from: true-asset on March 09, 2015, 10:52:53 AM

All you have to do is pay the receiver (amount - fee). Problem solved.

This is my favorite idea of the bunch. It's so simple. But I think we need a way to encode how much of a fee the merchant is willing to pay into qr codes. Something like:

Code:

bitcoin:?r=...&mpf_kb=0.00005&mpf_max=3

mpf for merchant pays fee. mpf_kb gives the amount the merchant will pay per kilobyte of transaction data, and mpf_max is the max number of mpf_kb's that the merchant is willing to pay. Without these parameters, it is assumed that the sender takes responsibility for the fees. Also, I did not use the 'req-' prefix here specifically because the merchant probably still wants to get paid even if they don't have to eat the fees.

This could probably be improved further by having a designated set of fee protocols and giving an integer to differentiate which protocol is to be used.

One bad part about it is that it puts the responsibility of formatting the transaction exactly as the merchant wants it onto the sender. The advantages of most of the other protocols listed is that the merchant can decide what they want to pay for a fee after they see the transaction, such as child pays for parent. I don't think that means we should rule this method out, just pointing out some of the trade-offs.