Topic: Are there any protocols defined to move the fee from the sender to the receiver? (Read 2167 times)

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:


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.

I like this idea a lot. This will solve some of the situations where sender "forgot" to add a fee or when the receiver wants a definite confirmation in the next block. I also foresee some potential problems. Wouldn't this promote a shift of the fee responsibility downstream? The small guy at the end of the chain ends up paying a hefty fee because he wants it bad enough.

Is this an area some devs/pools are actively looking into?

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

The recipient probably does not want to pay the fees on your monster transaction that clears all of the dust out of your wallet.  And why should he?

P2SH lets the recipient hide all of their internal crap in a tiny little package, causing no bloat in the payment that you are sending.  They may have fees later when they spend it, but that isn't your concern.

While a protocol like you described would be a potentially method of accomplishing your desired outcome (receiver pays the fees), there are other solutions that a merchant could implement that would not require anything new from the customer.

A few examples:

Child-pays-for-parent:
Mining pools discover that the can increase the fees they collect (and therefore increase their revenue) by implementing "child-pays-for-parent".  The customers are all just told to send the payment without a fee.  The merchant collects up all the transaction outputs received in the past few minutes and creates a single transaction that spends them all as inputs an sends the consolidated amount to an address that they control.  They pay a large enough fee on this transaction to cover the transaction costs of itself as well as all the transactions that are provided the funding.  Miners that are innovative enough to look not only at the fee they can get from a transaction, but also the fee they can get by including free transactions along with a paying child transaction confirm the transaction for the merchant and get paid.  Miners that fail to implement "child-pays-for-parent" see only that the funding transactions are "free" and miss out on the opportunity to increase their revenue.  Right now while the block subsidy is such a large percentage of the block reward, the transaction fees are negligible to the miners and pools.  As the subsidy decreases over the next decade or so, miners will become more desperate to gain as much in fees as they can.  As such, I suspect that "child-pays-for-parent" will eventually be a standard mining process for choosing transactions.

Mining contracts:
Merchants can enter contracts with large mining pools such that the merchant transmits their transactions directly to the pool and pays a negotiated fee (annually?, monthy?, daily?, per transaction?, that's an implementation detail left to the individuals forming the contract to determine for themselves) to have all their transactions confirmed.  Large pools may agree to such contracts as it gives them priority access to fee paying transactions over solo miners and smaller pools. Merchants can then pass on all the free transactions from their customers with the assurance that they will be included in the mining pools next block, since they are already paid for.

Self confirming
Really large merchants may form their own pools or large scale mining businesses for the purposes of confirming their own transactions (along with fee paying public transactions).  They may even operate these huge operations at a slight loss as a business decision to provide free transactions and to discourage competition (giving themselves a larger percentage of the hashing power, and therefore more frequent blocks).

Hello,

I'm pretty new to the bitcointalk forum, but I'm active over on the bitcoin stack exchange (http://bitcoin.stackexchange.com/users/18196/stephenm347). I'm sorry if this is not the best place for this discussion, please move my question if there is a more appropriate section of the forum.

My question is about creating a standard protocol to tweak the fee structure in bitcoin. Currently, the fees are paid by the sender, and the receiver pays no fees to accept their transaction. I love bitcoin, but I also love not having to pay fees when I use my credit card. Yes, the merchant probably just charges more to make up for the fees, but I still find it frustrating when my balance sheet doesn't add up cleanly and is littered with fees. I would bet that many consumers also feel like this. It's also what consumers are used to, and might help adoption if bitcoin worked this way for many online transactions.  

Are there any proposals in place to define a standard protocol for creating transactions where the fee is paid by the receiving party? I was thinking something like this:

1. Carl (the customer) wants to pay Mary (the Merchant).
2. Mary gives Carl a transaction with 1 input and 1 output to pay the miners' fee, to be signed at a later time. Mary also gives Carl another address to send the funds to.
3. Carl appends to Mary's transaction, spending previous outputs and creating 1-2 more outputs. 1 that sends to the address Mary gave her in step 2, and a second for the change (if any). These inputs and outputs would be inserted at random indices for privacy.
4. Carl signs all of his inputs.
5. Carl sends the updated transaction back to Mary, who then signs her input to complete the transaction, and broadcasts it.

This is basically a simple CoinJoin between the sender and the receiver. In fact, maybe a better way of doing this whole thing would be to implement a CoinJoin protocol (such as Luke-Jr's: https://gist.github.com/luke-jr/5409899), and transferring the fee from the sender to the receiver would just be 1 use case.

It seems like something that could have been packaged with BIP70 (https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki), but would probably require a new BIP now.

One problem is that Mary doesn't know how much of a fee to pay ahead of time but has to set the output amount before sending the initial transaction. I haven't found a way around that yet. Let me know if you have any suggestions on this, or on other aspects of this proposal.