Is there a way for merchants to insist on a tx fee to increase likelihood of the tx (eventually) being accepted into the blockchain?

I understand that some transactions may never get into a block, esp those with zero fee or with a fee below the current suggested minimum (which makes me wonder about tx fee inflation, but that's another Q).

Can a merchant accepting BTC for small purchases say, in effect, "I'll accept your $3 BTC payment for a coffee with zero block confirmations but I do want to see that you sent it with at least x Satoshis of fee?" Or perhaps this is already the case?

If this does, or were to happen, what mechanism(s) would the merchant use in order to get this small assurance?

darren

Posted 2014-12-10T22:10:48.763

Reputation: 107

1A merchant should avoid giving away take-out goods at zero confirmations, even those with the proposed fee, as they can easily get invalidated at that point by another tx that spends the same outputs but carries a bigger fee for the miners. – George Kimionis – 2014-12-11T00:05:09.067

Looking around at this and talking with folks it seems that most merchants accept small BTC transactions in seconds and pass on the risk to their point of sale providers. Andreas Antonopoulos has an example in his book here: https://github.com/aantonop/bitcoinbook/blob/develop/ch02.asciidoc#getting_first_bitcoin

– darren – 2014-12-12T23:25:01.537

@GeorgeKimionis: Your comment would fit as an answer seed here: How secure is zero confirmations?. Here it is somewhat off-topic, as it rather challenges the need to discuss the question than help with it.

– Murch – 2014-12-29T14:51:56.367

Answers

In short, no. You can tell the customer whatever you want on your webpage, at your point of sale, or in the memo field of a BIP70 invoice---but once the transaction has been sent to the network, there's no way for the customer to take it back. (Except for double spending, but that's discouraged.)

In the long-term, miners will likely change their transaction-selection process to allow for child-pays-for-parent fee calculation. For example, imagine merchant-created unconfirmed transaction B spends an output from customer-created unconfirmed transaction A. Currently, most miners use a naïve formula for selecting whether to include those transactions in their block attempts:

If transaction A pays a high enough fee per kilobyte, include it in the block.
If transaction A is included and transaction B pays a high enough fee per kilobyte, include transaction B as well. (Note, consensus rules don't allow including child transaction B before its parent transaction A.)

In child-pays-for-parent, the miner will do the calculations above the same but also do a third calculation:

If transaction A's fee plus transaction B's fee is high enough per kilobyte of the combined size of transaction A plus transaction B, include both transactions in the block.

This allows merchants to effectively add a fee to any low-value transactions, helping to encourage miners to confirm those transactions quickly. This method does have some overhead, so having the customer pay an appropriate fee would be ideal, but it can help prevent transactions from getting stuck.

David A. Harding

Posted 2014-12-10T22:10:48.763

Reputation: 10 154