Proposal: merchant specified transaction fee in Bitcoin URI

[caveden]

What do you think about adding an attribute in bitcoin URIs that would allow the recipient to specify how much s/he wants to pay as transaction fee to miners?

If you observe most successful means of payment (credit cards, paypal etc), transaction fees are always embedded in the price of stuff we buy. They are never visible to the costumer. That's much more appealing than letting the costumer know that s/he's paying a fee - even worse if it's up to the costumer to decide how much to leave as fee. They simply don't want to care about it, they care about the final price. Plus, in the case of bitcoin particularly, it's normally the receiver who's more interested in having the transaction confirmed faster.

I know that merchants may always add a second transaction whose inputs will be linked to the output of the feeless transaction, but that generates more data to be included in the chain - and consequently the merchant might have to spend slightly more in fees.

It would be nice if merchants could simply add a parameter in the bitcoin URI specifying the amount they want to send as fee. Then, the costumer's client would recognize it, construct a transaction that would contain the correct outputs and the fee requested, but, when asking confirmation to the user, would show the total amount (merchant output + fee). The costumer would just see how much s/he's spending, without having to care how much goes to the merchant and how much go to miners. Actually, they wouldn't even need to know what the heck is a "bitcoin miner" and why should they be sending money to these miners.

What do you think?

[1714194556]

1714194556

[1714194556]

1714194556

[1714194556]

1714194556

[davout]

That's really interesting, the solution might or might not be the best one, but the problem is interesting.

On an unrelated note, it's not the first time I see you mentioning costumers, makes me smile each time

Makes me think of this :


As opposed to this :

[Meni Rosenfeld]

If you observe most successful means of payment (credit cards, paypal etc), transaction fees are always embedded in the price of stuff we buy. They are never visible to the costumer. That's much more appealing than letting the costumer know that s/he's paying a fee

I'm vehemently opposed to this, as it is economically inefficient and opaque. The merchant doesn't choose or care much about the payment method used, he just knows how much he wants to get for the product. It is the responsibility of the customer, who wants the product, to get this payment to the merchant. He can choose whichever method he wants, based on its convenience, and should be the one to pay its costs. With the current sad state of affairs, customers who efficiently use cheap methods pay higher prices because of the free-riders who use expensive methods.

It's much better for a customer to know upfront when he signs up for Amex that their fees are higher than other CC, and be willing to pay it, than to have the cost hidden and then wonder why merchants don't want to accept his card. If customers could choose a CC based on its fee that they will pay, CC fees would be more competitive and lower, resulting in a lower total price of goods.

- even worse if it's up to the costumer to decide how much to leave as fee. They simply don't want to care about it, they care about the final price.

If the fee is low enough he doesn't need to consciously care about it. The client software can handle the day-to-day operations, and at the end of the month/year the customer can look at the total fees he paid and use it when deciding if to continue as is, change the software's fee policy, use a payment processor, etc.

Plus, in the case of bitcoin particularly, it's normally the receiver who's more interested in having the transaction confirmed faster.

The merchant sends the product when he is sufficiently satisfied with having received the payment. It is the customer who wants the product to be sent faster, and hence, that the payment will go through faster.

Looking at this another way: If the merchant trusts the customer not to double spend, there is no need for a fee or confirmation at all. If he doesn't, he'll want the transaction to be confirmed, regardless of its fee. So there is no meaningful sense in which the merchant wants a given fee, he wants a confirmation and it is the customer's client software's job to make sure they get one.

[caveden]

On an unrelated note, it's not the first time I see you mentioning costumers, makes me smile each time

Oups! Thanks for the remark.

I'm vehemently opposed to this, as it is economically inefficient and opaque.

If it's really economically inefficient, the use of such feature will be spontaneously ruled out by market forces. In the end, nobody would use it.
But while the feature doesn't exist, you can't really claim that it's use would be inefficient. Reading the rest of your post I believe you're making your judgement by looking at what happens on the current scenario of state intervention in the fiat word.

The merchant doesn't choose or care much about the payment method used

They definitely care, and if they could set different prices for different means of payment, they likely would. The problem here is that laws typically forbid it. The nice thing with Bitcoins is that it's not only a means of payment, but a currency too, so the price will necessarily be nominally different. Merchants can then embed the discount with no problems. In the worst case, it can be disguised in the conversion rate.

It is the responsibility of the customer, who wants the product, to get this payment to the merchant. He can choose whichever method he wants, based on its convenience

Exactly, and IMHO asking for an amount + fee and then explaining that this fee will go to the p2p node who manages to process the customer's transaction and blablablabla is not convenient at all to the average Joe. People will not use bitcoin if they have to understand how it works "inside" before using it. Asking them whether they want to add a fee or not, and of how much, will automatically trigger questions of "Why? What's the purpose of this fee? Miners what? Geez, this is too complicated, get me my credit card please".

, and should be the one to pay its costs. With the current sad state of affairs, customers who efficiently use cheap methods pay higher prices because of the free-riders who use expensive methods.

But customers will be paying the costs.

Understand that a merchant may use this feature in order to make his customer's lives easier while still setting different prices, depending on the means of payment used.

It's much better for a customer to know upfront when he signs up for Amex that their fees are higher than other CC, and be willing to pay it, than to have the cost hidden and then wonder why merchants don't want to accept his card. If customers could choose a CC based on its fee that they will pay, CC fees would be more competitive and lower, resulting in a lower total price of goods.

This has nothing to do with the proposal. This is only another bad consequence of state regulations, specifically, those which forbid different prices for different means of payment.

The merchant sends the product when he is sufficiently satisfied with having received the payment. It is the customer who wants the product to be sent faster, and hence, that the payment will go through faster.

Looking at this another way: If the merchant trusts the customer not to double spend, there is no need for a fee or confirmation at all. If he doesn't, he'll want the transaction to be confirmed, regardless of its fee. So there is no meaningful sense in which the merchant wants a given fee, he wants a confirmation and it is the customer's client software's job to make sure they get one.

What's the problem in the merchant adding a fee? Currently, the only way they can do it is by creating an extra transaction, generating unnecessary load to the blockchain. With this proposal, they'd be "adding" the fee without creating any extra transaction. I really don't see what's bad in it, since it's optional after all. Why only the sender "has" to pay for the transaction costs, why can't the receiver take such charge to himself?

[jim618]

The 'right' fee will depend on the number of inputs used to create the paying transaction, the age of the coins used and the urgency with which the customer wants the transaction included in a block.

Only the person paying has this information.

[Meni Rosenfeld]

I'm vehemently opposed to this, as it is economically inefficient and opaque.

If it's really economically inefficient, the use of such feature will be spontaneously ruled out by market forces. In the end, nobody would use it.
But while the feature doesn't exist, you can't really claim that it's use would be inefficient. Reading the rest of your post I believe you're making your judgement by looking at what happens on the current scenario of state intervention in the fiat word.

The word "this" and the rest of these two paragraphs referred to what I quoted. I'm vehemently opposed to CC fees being always embedded in the price of stuff we buy. I'm not vehemently opposed to your suggestion (though I find it pointless). In this light I think most of your response to me is moot.

By your own admission your proposal is inspired by the current common situation (and the belief that it is the merchant's responsibility to receive payment), so denouncing it is a valid way to argue against your proposal.

Re state intervention - it only prevents having different prices for different payment methods. It would be better if this could be allowed, but it still leaves the issue relatively obscured, compared to having a specified price and the customer explicitly paying processor fees.

To recap, my two main objections are:
1. I don't believe that lacking this feature forces the user to know the details of the mining network.
2. There is no meaningful way in which a merchant expects a specific tx fee. The merchant wants to receive a certain amount himself and that the tx will be confirmed. Making sure that the tx is confirmed is the customer's client's responsibility.

[caveden]

The 'right' fee will depend on the number of inputs used to create the paying transaction, the age of the coins used and the urgency with which the customer wants the transaction included in a block.

Only the person paying has this information.

Parameters can be specified, instead of an absolute amount. Like amount per kilobyte.

1. I don't believe that lacking this feature forces the user to know the details of the mining network.

I once was talking to a colleague about bitcoins, and once I mentioned "transaction fees", his reaction was an immediate "ah, it won't work then, everything else is "free"". I tried arguing that in reality CC aren't free, the fees are embedded, to which the response was an insistent "but it's free to me, I don't pay anything. Why do I have to pay transactions fees in this money of yours?". That led to a discussion about "transaction processors not being forced to process your transaction etc". Things started getting technical, even though I was trying to avoid it.
It's hard to explain the concept of "voluntary transaction fees". Maybe if you rename it to "tip" instead of "fee", but still.

And even in this forum you can find "bad reactions" to the concept of transaction fees. Look:
https://bitcointalk.org/index.php?topic=111868.0
https://bitcointalk.org/index.php?topic=19528.0
I guess people just want to remain oblivious or not have to care about it even if they know the fact that they're paying. They just don't want to mind with it.

2. There is no meaningful way in which a merchant expects a specific tx fee. The merchant wants to receive a certain amount himself and that the tx will be confirmed. Making sure that the tx is confirmed is the customer's client's responsibility.

Why can't the merchant take this responsibility to himself, if he thinks it will make it's clients lives easier?

[CIYAM]

Why can't the merchant take this responsibility to himself, if he thinks it will make it's clients lives easier?

I think that this is indeed something necessary - in playing with Walletbit in order to purchase a VPS I was hit with a "hidden" fee that meant that the exact amount I'd sent for the payment was (upon arrival at their website) no longer enough (with no warning at all) requiring me to then muck around sending another tx just to cover their "hidden" fee.

This kind of experience will turn 99.99% of the "general public" off ever using Bitcoin at all (regardless of the "real cost").

The fees are minimal - so the seller should pay them!

[Meni Rosenfeld]

Doing things is easy, getting used to things is hard. People routinely do things much much harder than thinking about transaction fees, because they are used to do them. We've been trained to think payment is free and therefore we flinch at the thought of having the fees made explicit.

When I think about how I want the world to look like in 10 years, I don't want people to be gently shielded from the "ugly truth" that there are tx fees. I want it to be common knowledge that tx fee is a tiny but existent cost of making payments. It will be small enough that most people won't have to dedicate much conscious thought to it. It may not be easy to get to this state, but it is trivial to be in this state.

If I lose the battle and we will need to hide the tx fees, your proposal can work. It only makes sense if every merchant does that, though. A merchant factoring in a lower fee can appear more attractive / profit more per sale, but will get more angry customer letters asking why the product wasn't shipped yet.

The 'right' fee will depend on the number of inputs used to create the paying transaction, the age of the coins used and the urgency with which the customer wants the transaction included in a block.

Only the person paying has this information.

Parameters can be specified, instead of an absolute amount. Like amount per kilobyte.

But then the merchant can't display the total cost of the product, which I thought was the whole point.

[caveden]

We've been trained to think payment is free and therefore we flinch at the thought of having the fees made explicit.

Is it really that bad? I mean, do you really want to make every price component explicit? Why just the transaction costs in particular, and not every other?

The problem is not aggregating price components and only displaying the total, the problem is not being allowed to discriminate by means of payment (setting different prices).

In the particular case of bitcoin, explicit transaction fees imply the user not only has to see a tiny price component s/he not necessarily cares about, but s/he also has to choose how much to pay. Even if you manage to abstract the mining process, people will still be in doubt about how much to give. Customers tend to be lazy. IMHO it's better to leave this task to the merchant.

It only makes sense if every merchant does that, though. A merchant factoring in a lower fee can appear more attractive / profit more per sale, but will get more angry customer letters asking why the product wasn't shipped yet.

Competition will sort things out. I don't think it's "all or nothing".

The 'right' fee will depend on the number of inputs used to create the paying transaction, the age of the coins used and the urgency with which the customer wants the transaction included in a block.

Only the person paying has this information.

Parameters can be specified, instead of an absolute amount. Like amount per kilobyte.

But then the merchant can't display the total cost of the product, which I thought was the whole point.

He can display the total if the fee is calculated within the price, not outside of it. Like sale taxes in general.
True, that would mean the merchant wouldn't be able to know the exact amount he's going to receive before the transaction takes place. But as fees are supposed to be tiny this shouldn't be an issue. Parameters to specify a ceiling proportional to the transaction amount could also be available, solving this issue and at the same time forbidding an "evil customer" from arbitrarily creating a transaction in which the fee would be too large.

[Stephen Gornick]

I know that merchants may always add a second transaction whose inputs will be linked to the output of the feeless transaction, but that generates more data to be included in the chain - and consequently the merchant might have to spend slightly more in fees.

Presumably, you are referring to pull 1647:
 - https://github.com/bitcoin/bitcoin/pull/1647

That essentially eliminates the problem.  If it is important to the merchant that the payment get confirmed sooner, the merchant will issue the child transaction and pay a fee to get both included.  If it is important to the consumer to be confirmed quickly, the consumer will ensure an adequate fee.

If I as a consumer am frustrated that my transactions are not getting confirmed, then my problem is not with the merchant but with my client and I will configure it to use a higher fee (or use a client that is smarter to let me know when the fee is insufficient).

[caveden]

I know that merchants may always add a second transaction whose inputs will be linked to the output of the feeless transaction, but that generates more data to be included in the chain - and consequently the merchant might have to spend slightly more in fees.

Presumably, you are referring to pull 1647:
 - https://github.com/bitcoin/bitcoin/pull/1647

That essentially eliminates the problem.  If it is important to the merchant that the payment get confirmed sooner, the merchant will issue the child transaction and pay a fee to get both included. 

I didn't know about the pull request. It's a way of doing it, of course. But looks more like a "hack" than a clean solution to me. It generates twice as much transactions in the chain than what's necessary, and the merchant will end up spending more in fees.

[Meni Rosenfeld]

Is it really that bad? I mean, do you really want to make every price component explicit? Why just the transaction costs in particular, and not every other?

People should be aware of and responsible for the things they have an influence on. I as a customer have no influence on the raw materials used for the product and their cost. I have an influence on the payment method used and its cost.

In the particular case of bitcoin, explicit transaction fees imply the user not only has to see a tiny price component s/he not necessarily cares about, but s/he also has to choose how much to pay. Even if you manage to abstract the mining process, people will still be in doubt about how much to give. Customers tend to be lazy. IMHO it's better to leave this task to the merchant.

The customer doesn't have to choose anything, he delegates his responsibility to the client software. The software will come with default settings which work for 99.9% of cases. At the end of the year he will get a report "you spent 1.3 BTC on fees this year". The figure will probably be too small to care about, but if he wants he can compare it with friends who use different payment solutions, or tweak the fee settings.

He can display the total if the fee is calculated within the price, not outside of it. Like sale taxes in general.
True, that would mean the merchant wouldn't be able to know the exact amount he's going to receive before the transaction takes place. But as fees are supposed to be tiny this shouldn't be an issue. Parameters to specify a ceiling proportional to the transaction amount could also be available, solving this issue and at the same time forbidding an "evil customer" from arbitrarily creating a transaction in which the fee would be too large.

Yeah, this can work.

[Mike Hearn]

I wouldn't worry about the extra transactions. Post ultraprune the sensitive dataset is the UXTO set which doesn't change its size if two transactions are simultaneously broadcast, one of which spends the other with fees. It results in faster usage of disk space for archival nodes, but disk space is super cheap.

The thing to remember is that a merchant can collect multiple transactions from buyers who he trusts and just keep them around for a while. There's no need for them to confirm immediately. Then when he wants them confirmed a single fee transaction can be added that spends all of them. Miners will recursively include all the free transactions in order to claim the fee on the spending transaction.

This model means you can theoretically pass around long chains of unconfirmed transactions until you cross a trust boundary. Eg, if my employer pays me my salary by giving me a bunch of transactions, do I really need to broadcast those immediately and pay a fee? Well, not really. I know my employer isn't going to double spend my salary. I can just keep those transactions around. Then when I pay somebody, I send them the transactions they need to get back to a confirmed payment in the chain. If they don't trust me, the merchant can broadcast them all + fee tx to stop me double spending. If the merchant and I have a long-standing relationship, they may choose to accept both my transaction and the salary transaction both unconfirmed.

In this way fees are only paid by those who need the services of the block chain (allowing you to accept payments from people you don't trust).

[caveden]

I wouldn't worry about the extra transactions. Post ultraprune the sensitive dataset is the UXTO set which doesn't change its size if two transactions are simultaneously broadcast, one of which spends the other with fees. It results in faster usage of disk space for archival nodes, but disk space is super cheap.

I suppose UXTO means unspent transaction outputs (shouldn't be UTXO?).
That's a good argument.

I wonder how miners would charge for transactions then. If they charge per kilobyte, then merchants still have some interest in sending less transactions. But if it's not the size that matters to miners, they'll probably charge some other way...

[Mike Hearn]

Oops yes UTXO.

Right now we're artificially size limited. So size still matters. I'm in the camp that assumes we'll eventually lift the block size requirements (make it floating).

I think how miners will use fees is still something of an open question. It's not a given that per-tx fees will be the way things are done. That model does seem to have the game theoretic problems raised a long time ago in which there's a race to the bottom. For this reason I suspect we may end up with a world where transactions are free (or require fees so low they are basically free), and then merchants and organizations with an interest in network security use assurance contracts to incentivize each block with fee-only transactions. In such a model many users would be "free riders" but people who really rely on the low-trust aspects of Bitcoin would club together to fund them.

Double spends would occur with some regularity on such a network but it wouldn't be a problem.

[Steve]

I didn't know about the pull request. It's a way of doing it, of course. But looks more like a "hack" than a clean solution to me. It generates twice as much transactions in the chain than what's necessary, and the merchant will end up spending more in fees.

I don't think it's a hack at all.  It's simple and elegant.  It would allow a Bitcoin client to expose a simple API to "addTxFee" to an existing transaction…which would send coins to itself with the given transaction as an input and including a miner fee.  This makes it very easy on the sender of the original transaction…they don't have to worry about what fee to include (the only concern for the sender would be whether the transaction has a high enough priority to be propagated in the p2p network).  This eliminates any complicated URI interaction between the merchant and the buyer, which may or not not even work (making it an unreliable tool for the merchant).