Topic: Cost and Confirmation time of Bitcoin Transactions (Read 17130 times)

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.

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

@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

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).

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?

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.

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

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?

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.

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.

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?

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.

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.

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.

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.

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.

Would you mind linking a couple of those with 2h wait time and proper fee?

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.

That sounds plausible, but how often would you expect such a reorganization to occur? I have just dug through the logs and found another example:

This transaction https://blockchain.info/tx/2b7bec664c3552c605dd687404e1c7088501e88369ceabf4da04c2bd15dc2ed4 was broadcast at 02:28 GMT on the 19-11-2013. It did not confirm for 670 minutes and the transaction had to be manually pushed through blockchain.info/pushtx to appear on the blockchain.info database. The reason it didn't appear is again, because of an unconfirmed input being used: https://blockchain.info/tx/3386d4afcd5506a7bd77637b63f0ed061b878fb1557278bc3717048ca10d4c31 - This ancestor transaction was broadcast at 01:42 GMT on the 19-11-2013 and included no fee. It took 716 minutes to confirm.

You can see the overlap in confirmation times means https://blockchain.info/tx/3386d4afcd5506a7bd77637b63f0ed061b878fb1557278bc3717048ca10d4c31 could not have possibly been confirmed when it was used as an input for https://blockchain.info/tx/2b7bec664c3552c605dd687404e1c7088501e88369ceabf4da04c2bd15dc2ed4

I took a quick (re)look at the code and sendtoaddress is pretty simple.  It does some parsing and error checking and then calls.  SendMoneyToDestination()

https://github.com/bitcoin/bitcoin/blob/d980f9b7d687a1e60eecf3691b592d9806a30f4a/src/wallet.cpp#L1467


Note the balance check calling GetBalance()

https://github.com/bitcoin/bitcoin/blob/d980f9b7d687a1e60eecf3691b592d9806a30f4a/src/wallet.cpp#L961

GetBalance gets the sum of confirmed unspent outputs.

The only thing I can think of is at the time you created the second tx the unspent output used WAS CONFIRMED.  Possibly there was a short re-org in the blockchain AFTER the second tx was broadcast which made the first tx unconfirmed.  Then because of high number of free tx and miners including a limited number you ended up with the first tx not confirming for a while and that led to the second tx not confirming for a while.


IMHO the default behavior for a lot of things probably need to change.  I doubt the core devs will see it as a high priority but I think the entire system would be simpler and less prone to unexpected (from user standpoint) behavior if we saw the following.

1) Drop min fee to 0.02 mBTC.  The last time this was done the exchange rate was ~$100 USD.  The drop would put min fees back to ~$0.01 per KB.
2) Change default behavior of client to include a fee on ALL tx (not just low priority ones) and make the default fee the min fee.  Users can override this but they should be warned "including no fee may result in substantial delays before confirmation".
3) Implement "parent pays child".
4) Implement "tx replacement".

Use blogs and other public forums to advocate that authors of other wallets/eWallets/exchanges/etc do the same.