Sending medium size transactions from localbitcoins to a bitpay invoice are timing out on bitpay's 15 minute invoice expiration. I assume localbitcoins is propagating the transactions widely and with a non-zero transaction fee.
After some hour or hours the transaction shows up in the public ledger, then either bitpay or the merchant has to take FX exchange risk since so much time has elapsed. Most merchants don't want to hold BTC, they want to receive the number of dollars they expect to receive, because their expenses are paid in dollars, not BTC. With small enough periods between the quote of FX price and the actual FX transactions, the variance will probably average out over enough transactions. Yet larger delay periods increase variance and risk.
Also there is immense and unbearable delay and confusion for the customer.
Both the merchant and customer lose far more in lost time (emails back and forth, delays, etc) than any credit card transaction fee and chargeback rate.This is a fail. It is going no where like this. Never can this be widely adopted. And as merchants are gaining experience with this, they will become discouraged about accepting Bitcoin payments. As a merchants' tolerance reaches the breaking point, they will finally dump Bitcoin and never come back (nor to any altcoin).
Ditto customers! No circumstance under which I would waste a couple of hours of my day on a transaction that would take less than a minute with a credit card, except maybe if I needed to be anonymous and was expert enough to jump through the VPN and Tor proxy hoops (thus not a mainstream transaction).
Businessmen don't have time to waste; that their most precious resource!
I don't know why Bitpay is not accepting 0-confirmation transactions in this case, at least to the point of telling the customer that the transaction was seen but not yet in the public ledger. So perhaps Bitpay could do FX immediately, while the merchant would withhold final delivery of goods or services until at least 1-confirmation. This may be poor integration between Bitpay and the merchant and this wouldn't surprise given how braindead the Bitpay invoice web page is, e.g. there is a button to pay and it links to a "bitcoin:" protocol which the browser doesn't understand. So the customer is left completely clueless after clicking that and thinks Bitpay is broken.
What is causing this technical problem with localbitcoin spends being delayed into the public ledger?
I suspect it is a contagion of issues:
1. Slow 10 minute block period.
2.
Variable transaction fees with finite block size means during intense speculation, the higher bidders would go first. I did not verify whether blocks are overflowing with transactions.
3. Denial-of-service (even double-spend) attacks on miners perhaps means they reject many of the transactions with low transaction fees.
4. Miners with low processing power (all dedicated to winning a block solution) and bandwidth perhaps means they reject many of the transactions with low transaction fees or many transactions with any transaction fee.
5.
