Cost and Confirmation time of Bitcoin Transactions

[ashray]

This seems to be inconsistent behavior though. I've paid a 0.0001BTC fee (roughly 6 cents) and had transactions go through in less than 10 minutes.

[1714668464]

1714668464

[1714668464]

1714668464

[1714668464]

1714668464

[1714668464]

1714668464

[1714668464]

1714668464

[DeathAndTaxes]

Here's a live list of Mt. Gox Bitcoin transactions stuck waiting for confirmation for more than 2 hours:
http://skanner.net/MtGox/mtgox_tx.php

There's a huge backlog of "no fee" transactions.   It looks like 0.001 BTC isn't enough to consistently get a transaction through, but 0.002 BTC is. So it now costs about $1 to do a Bitcoin transaction.

Bitcoin has now been priced out of the micropayments business. It's too expensive for, say, an iTunes track or a video rental.

min fee for low priority tx is 0.1 mBTC per kB not 1 mBTC.  So your estimate is off by a factor of at least 10x.

[HoboTheClown]

I'm not sure if these complaints were recent.  For me, I bought something on Monday,my first purchase with Bitcoins, and to my astonishment it was quick in terms of confirmation of bitcoin transaction.  I created another account and transferring a small amount from my main account to the new account, confirmation was pretty much instantaneous.  Once I purchased my items with the small funded account, that transaction of bitcoins was very quick.  I received confirmation on my phone literally 1 sec later.  The one thing that made me concerned was that retail's website took a while to send me any confirmation email letting me know the purchase was complete.  As for transaction fee, it was a small one .0005 BTC I believe, or whatever the decimal place is suppose to be but it was not very high at all.  That's my recent experience.

[oblongmeteor]

I'm not sure if these complaints were recent.  For me, I bought something on Monday,my first purchase with Bitcoins, and to my astonishment it was quick in terms of confirmation of bitcoin transaction.  I created another account and transferring a small amount from my main account to the new account, confirmation was pretty much instantaneous.  Once I purchased my items with the small funded account, that transaction of bitcoins was very quick.  I received confirmation on my phone literally 1 sec later.  The one thing that made me concerned was that retail's website took a while to send me any confirmation email letting me know the purchase was complete.  As for transaction fee, it was a small one .0005 BTC I believe, or whatever the decimal place is suppose to be but it was not very high at all.  That's my recent experience.

If you include a fee and especially if you include a generous fee which 0.0005 BTC is, you shouldn't encounter any problems with rapid confirmations. You're basically being fast-tracked to the front of the queue.

[DeathAndTaxes]

although at least if miners included closer to the 1MB of txs per block we'd have far less backlog

Adding transactions to a block takes time, in which the miner/pool is idle.

Why does the miner/pool have to be idle while adding transactions? Can't the calculations be done on a CPU while the ASICs are hashing away at the block without the transactions? This should be especially true if instead of adding transactions one at a time you add them hundreds at a time.

The transaction fee has to make up for that idle time. It doesn't need to be much, but certainly more than zero. I am sure the blocks will be filled if there are TX with fees available.

Well, no, they aren't.

Your correct the inclusion of tx in a block is pretty trivial.  Sure it is a non zero time but a CPU can validate about 15,000 tps.  If the UXTO is kept in memory (UXTO = unspent portion of blockchain and much smaller) there is no reason that including even thosands of tx in a block should take more than a fraction of a second.  Pools also use various tricks to speed up work generation when a block change occurs (send work to faster workers first, build a 0 tx block to get all miners working rapidly and then go back and build the larger block).  So for all intents and purposes we can consider this to be zero cost.

The prior poster misstates the "cost".  The real cost that miners (pools) are worried about is increased orphan losses.  For a given pool if they do something different which increases their orphan rate by 1% they lose ~0.25 BTC, if that changes produces less than 0.25 BTC in additional revenue they are net-net losing revenue.  The larger the block is, the longer it takes to propagate through the network for a given amount of bandwidth.  Those peers then need to validate it, and relay it to their peers, who validate it and relay it to their peers.  Eventually all nodes (and more importantly miners) have the new block and work to build off it.

The time between when a miners finds a block and all miners are building off that block can be considered the "critical window".  If another miners finds a competing block (same height) in that critical window one of those blocks will be orphaned.   The larger the block the longer the propagation delay, and the greater the losses due to orphans.  You can consider the chance of an orphan relative to the value of the block the "cost" (in lost revenue) for a miner adding another tx to the block.   Smaller block = less gross revenue but less chance of orphaned block, larger block = higher gross revenue (except for free tx which is why I believe they will die off) but higher chance of losing the whole block.

Gavin corrected me (in another thread) that the best estimate for the "orphan cost" is ~3.3 mBTC per kB, which is pretty huge.  This is why miners are reluctant to build larger blocks.  If you look at it from game theory perspective, they get 25 BTC for "free" (baseline orphan risk), The average paying tx is ~0.1 to 0.3 mBTC per kB but it costs them about 3.3 mBTC in orphan losses to include that tx.   There is "good news" though.  The current method of relaying blocks is relatively inefficient.  It likely with some small soft (no hard fork necessary) changes reduce the orphan cost by 80% (a more controversial change could cut that to 99% or more).  Also as bandwidth becomes cheaper and more available the orphan cost also falls, so Moore's law is on ourside.  Miners can also reduce the orphan cost by making sure other miners are direct peers.  The faster other miners learn of "your block" the faster the critical window closes.  It doesn't really matter how long it takes the whole network to know about a new block just how long it take for all (well most) miners to know about a new block.  Non-mining nodes learning about a block a few seconds later is fine for their needs.

Remember Bitcoin is an experiment, it is in beta.  For those who want a perfectly polished protocol with no rough edges check back in a decade.

[davidtehbest]

The fees can be lowered if the price rises too high. They have already been lowered several times for exactly this reason, and there's no reason to think it won't happen again.

Transaction fees are likely to go up (in dollar terms) for a while, until some engineering work is done to reduce the "orphan cost" for miners to include more transactions in their blocks OR mining pools / miners collectively agree to include more transactions for the good of the whole system.

In the very short term, you can ask mining pool operators to create larger blocks. If they refuse, then switch your miners to a pool that does.

If they all create larger blocks, then we get more transactions and more orphan blocks, but the cost of those extra orphan blocks is spread across everybody mining, so everybody gets just as many bitcoins (on average) as they would with smaller blocks.

I think we should raise awarness and pettition the larger pool operators to include the max block size of I believe 1Mb. Can we as a community organize this together?

[DeathAndTaxes]

The fees can be lowered if the price rises too high. They have already been lowered several times for exactly this reason, and there's no reason to think it won't happen again.

Transaction fees are likely to go up (in dollar terms) for a while, until some engineering work is done to reduce the "orphan cost" for miners to include more transactions in their blocks OR mining pools / miners collectively agree to include more transactions for the good of the whole system.

In the very short term, you can ask mining pool operators to create larger blocks. If they refuse, then switch your miners to a pool that does.

If they all create larger blocks, then we get more transactions and more orphan blocks, but the cost of those extra orphan blocks is spread across everybody mining, so everybody gets just as many bitcoins (on average) as they would with smaller blocks.

I think we should raise awarness and pettition the larger pool operators to include the max block size of I believe 1Mb. Can we as a community organize this together?

Hell at this point I would settle for just having it out in the open. 

What ARE the parameters you use for a block?
How many free txs?
How many paid txs?
What is the threshold for paying vs fee? (by default it is 0.1 mBTC).

If you can start a thread and get 10 pool admins to provide that kind of insight the community can start making better decisions.  The nice thing is the blockchain keeps them honest.  If pool xyz claims they allocate 27KB per block for free tx and there is a backlog and they produce multiple blocks with <27KB we can prove they are not being honest.  Likewise if pool abc claims they will include up to 500KB of paying txs with theshold of 0.1 mBTC per KB and they produce multiple blocks smaller than 500 KB while paying tx are waiting it can be proven they also are being dishonest.

If we KNOW what all the major pools (and major solo miners with more than say 5% of global hashrate) have as their transactions selection parameters we an put that together and start to get a better view of how long various tx are going to take.  If you know combined all the pools on average only devote an average of 27KB (the default) of space for free transactions that is ~60 free transactions per block.  If there are 2000 waiting it is going to take 50 blocks (assumming no new tx) to confirm all of them.

[DeathAndTaxes]

The prior poster misstates the "cost".  The real cost that miners (pools) are worried about is increased orphan losses.  For a given pool if they do something different which increases their orphan rate by 1% they lose ~0.25 BTC

I assume this doesn't include the benefit of slower propagation from the fact that they are able to work on the next block sooner than everyone else? Selfish mining?

If a miner receives a second block while verifying the first, the first will win (so long as it's valid), right?

True but selfish mining actually means a net reduction in current income.  The attack is that an attacker would lose money today to generate a larger than fair share of revenue in the future.  I don't find it a particularly viable attack method as if you want to expend massive amounts of cost today to hurt the Bitcoin network you could just do a traditional 51% attack.

Simple version if a pool has 20% of the hashing power and due to longer propagation another miner wins the race to all other miners then the pool has a 20% chance of winning both blocks but an 80% chance of losing the already solved block.   In reality that type of simplified race outcome is very unlikely it is more likely that a pool broadcast a block and it reaches some % of miners first (including itself) and a competing block reaches some % of miners first and for the next block the network is split.  How split really depends on how close the race was and how different in size the blocks are.

[porcupine87]

I don't get it. I checked this a few times. I tranfered 0.0001 + 0.0001 fee, just to check. My tx was always in the next block. I always sent this btc from my mobile app.

Which tx with fees have this problems?

[porcupine87]

I don't get it. I checked this a few times. I tranfered 0.0001 + 0.0001 fee, just to check. My tx was always in the next block. I always sent this btc from my mobile app.

Which tx with fees have this problems?

Not sure if you did it recently, but 1) it looks like blocks haven't been full for the last couple hours; and 2) Eligius won 3 out of the last 7 blocks. Eligius will put just about anything in a block, and has no problem filling them up to near the max allowed by the protocol.

Example: This was a couple of minutes ago and the it went into the following block:
https://blockchain.info/tx/8e78d8c99d8c3cd62102f2b78befe3d171e15f496c725a09aadd3fe4e8fbb765

[DeathAndTaxes]

I don't get it. I checked this a few times. I tranfered 0.0001 + 0.0001 fee, just to check. My tx was always in the next block. I always sent this btc from my mobile app.

Which tx with fees have this problems?

I haven't seen many problems with "normal" paying tx however:
a) Someone user have reported issues with paying txs and the actual issue is the tx uses as an input the output of a prior tx which hasn't confirmed. Fee or not a tx isn't going to confirm until the inputs confirm.  If the input has no fee it may take a long time.  The issue isn't the paying tx it is the unpaid one that it relies on.  The QT client prevents spending unconfirmed outputs for this reason. If other clients allow this it should probably be disabled by default.  A protocol change to improve this scenario is called "child pays parent".

b) Most clients by default most clients include no fee for high priority txs. That may have been optimal at one time however today that can mean waiting a long time.  I recommend setting the default fee to 0.1 mBTC for ALL transactions if you want timely inclusion in a block.  The days of pay a fee for low priority but get into a block quickly for free if tx is high priority are coming to a close.  Free tx should be considered charity and the time to confirmation may be hours, days, or even weeks.   Clients should probably warn users to expect potentially extended confirmation times if they try.

c) Some users mistakenly think that a very low fee (say 1 satoshi) helps but by default miners consider fees below 0.1mBTC (10,000 sat) to be free so really there is no point to pay a fee below 0.1 mBTC you are just wasting money the tx isn't going to confirm any faster than a no fee one will.  Clients should probably warn users about this behavior if user tries to pay a fee below the default threshold.

In my experience baring those scenarios most paying tx due confirm very quick, at most they may be delayed a block or two.  So it isn't an issue for all tx all the time.

[Valle]

And there is another issue - in case your tx stuck, in most (in all?) clients it is not possible to increase fee. It can be done by sending same tx with different fee, but why there is no such option?

[CIYAM]

And there is another issue - in case your tx stuck, in most (in all?) clients it is not possible to increase fee. It can be done by sending same tx with different fee, but why there is no such option?

The problem is that you cannot send the same tx whilst the old one is known to the network (any attempt to do so will simply be ignored as a "double spend" attempt) so it is not something that can very easily be handled by clients (basically you have to wait until the old tx has been "forgotten" before you could send a "replacement" tx).

[porcupine87]

@DeathAndTaxes

Yeah, I read about this guy who used a fee but the output he wanted to use was not confirmed (no fee). Then it makes sense that it take a long time and is just a mistake of the user. So when i scroll down I see that many tx have less than 0.1mBTC per kb or an unconfirmed output.

But what I saw now: At the moment there are waiting 2000 tx and the total fee to collect is 50btc (now it dropped mysteriosly to 25btc). This means the average fee is 0.025btc = $12,5 ?
-> I think this is because many tx with maaany outputs are stuck. So they pay a large amount of tx but it is still less than 0.1mBTC per kb.
https://blockchain.info/de/unconfirmed-transactions

[hacknoid]

The fee is currently 0.1 mBTC (~$0.05).  While this is not free it is pretty much cheaper than any other payment system.
Credit Cards: $0.30 + 2%
PayPal: $0.30 + 3%
ACH: $0.25 to $0.50
Bank Wire:  $10 to $25
International Bank Wire: $25 to $40
Check processing (business): $0.50 ea
etc

To be fair, as much as I do love Bitcoin and what it brings to world transfers.

Debit Card:  Usually $0 for a lot of major websites.
Bank Transfer (UK - UK bank account)  $0

Bitcoins primary strength is still making small to very large fast transfers across great distances around the world with tiny fees.

For reference, in Canada:
Debit card: fees vary from $0 (rare) to $0.15 generally
Bank Transfer: $20

[tomsmi321]

The democratic solution would be that if you use bitcoins then you should also be mining bitcoins as the system gradually moves from being rewards based to transaction fee based with the increasing difficulty of bitcoins. That way electricity costs ect would be hugely spread out among users and average trasaction costs would stay low. To get a hosted wallet u should be required to devote a small part of ur computers time to mining IMO.