I'm pretty sure you'll get a completely different result if you would run the same test several times spread over a couple of weeks.
As said before, i think it depends on how many transactions are in the mempool, how big they are, which fees they have, which pool mined the blocks, how big the blocks were,.... From time to time, you also see allmost full blocks for 3-4 consecutive blocks. I'm pretty sure that your very low fee transactions wouldn't have been included in this case.
Topic: Bitcoin Fee Experiment May 9 2016 (Read 1069 times)
should also include "no fee" test.
I did some no-fee transaction awhile back and one went through fairly quickly (within 4 hours) and the other took a while longer, maybe 2 days.
Update: Just for fun, I tried again sending a small amount to Polo using a 0 fee transaction. I will report back on how long it takes. Transmitted out just before block 411108.
Transaction ID: 6d10574175e76c7801d7dd0b41f7bfe6c81ff10796ae6968356e52c671375460 if you want to follow along, 0.03834 BTC consisting of several (recent) small inputs from signature payments.
wow Im surprised I didnt think to do this or someone earlier lol
amazing how the most simple ideas sometimes get missed.
good study
amazing how the most simple ideas sometimes get missed.
good study
thanks RD You're the one etc..... :-D
And were you sending a fraction of a large input, or a combination of lots of small inputs. Both transaction 3 and transaction 4 look like you were sending a combination of lots of small inputs, combined with a large fee. It got confirmed quickly because of the large fee.
What you really need to do is standardize the fee - make them all 0.0001, and vary the amounts (outputs made up of one big input or lots of small inputs). That way you will be able to see whether the miners make you wait or not.
Also, the protocol says you can send an aged input for zero fee if the kilobytes are low. According to the wiki, "a transaction was safe to send without fees if these conditions were met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough"
Test it out and see if it works. Bitcoiners have spent the last seven years telling everyone that you can send "free" or for a minimal fee - so that is what most bitcoiners do. The question is, is that still true.
I sent a combination of a lot of small inputs in each case. Correct 3 and 4 were larger than the others, with more data of similar size inputs. The others were less inputs, with fees that were comparably smaller than the difference in size/number of inputs.
Great suggestion, there are a few ways I could change it up to get more accurate data. Next time I do this (if I can ever find the time to do it right) I'll incorporate that and some other ideas to make the test more scientific and thorough.
Those are great things to keep in mind and I'll refer back to this next time I run a test to remind me the kind of things I should keep in mind.
You also have to factor in how full the mempool is. Although the Core estimator looks into the mempool**, it may not be accurate. There may be close to no pending transactions in the mempool, therefore putting a low fee tx in the next block.
** Not sure if it does or not
** Not sure if it does or not
How old were your inputs? That would have affected the priority. High priority stuff gets confirmed pretty fast.
Inputs were all within the last year...
And were you sending a fraction of a large input, or a combination of lots of small inputs. Both transaction 3 and transaction 4 look like you were sending a combination of lots of small inputs, combined with a large fee. It got confirmed quickly because of the large fee.
What you really need to do is standardize the fee - make them all 0.0001, and vary the amounts (outputs made up of one big input or lots of small inputs). That way you will be able to see whether the miners make you wait or not.
Also, the protocol says you can send an aged input for zero fee if the kilobytes are low. According to the wiki, "a transaction was safe to send without fees if these conditions were met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough"
Test it out and see if it works. Bitcoiners have spent the last seven years telling everyone that you can send "free" or for a minimal fee - so that is what most bitcoiners do. The question is, is that still true.
wow Im surprised I didnt think to do this or someone earlier lol
amazing how the most simple ideas sometimes get missed.
good study
amazing how the most simple ideas sometimes get missed.
good study
How old were your inputs? That would have affected the priority. High priority stuff gets confirmed pretty fast.
Inputs were all within the last year...
How old were your inputs? That would have affected the priority. High priority stuff gets confirmed pretty fast.
Thats true, the good thing is you dont need to send the same amount of transaction for every case. To keep the same significance, you dont need as much high fee transactions as the low fee transactions because the expected variability in confirmation times for low fee transactions is expected to be much higher.
Good point, you just saved me some btc I suspect
Absolutely a bigger sample size would be good, and sample sizes spread out over a long period of time.
Thats true, the good thing is you dont need to send the same amount of transaction for every case. To keep the same significance, you dont need as much high fee transactions as the low fee transactions because the expected variability in confirmation times for low fee transactions is expected to be much higher.
It is really interesting experiment. It confuses me since i always believed that there was a simple connection between transaction speed and the fee that is paid. Please keep us posted about no fee transfer as well. Thanks.
I'm getting the feeling that it's the politics of the mining pools that affects confirmation times more than anything. I'll update when I run my next test for sure. It will be an interesting metric to keep a pulse on over time.
I think that you're off to a good start, but there needs to be a bigger sample size and I think it might be worth factoring in the previous block full-ness and see if different used space in each block has an effect on the transaction fee for the transaction. Also maybe check hashing power and see if increase or decreased hashing rates are also a variable when it comes to transaction fees. No guarantees those factors actually have any affect on the value, but it might be interesting to look into.
Absolutely a bigger sample size would be good, and sample sizes spread out over a long period of time.
Hash power changes shouldn't be big enough to change block generation by much. That stuff is graphed pretty well on blockchain.info and other places, but generally the randomness of block generation regardless of the hashpower or difficulty level accounts for bigger fluctuations than hash power fluctuations. That is until right after a halving I suspect.
It is really interesting experiment. It confuses me since i always believed that there was a simple connection between transaction speed and the fee that is paid. Please keep us posted about no fee transfer as well. Thanks.
should also include "no fee" test.
Good suggestion. Next time I do this I'll include a no fee test as well.
should also include "no fee" test.
So it means that whatever transaction fee you will put, it will always get accepted ? I always put little tx fees, and after this results I won't change it. Thank you for this study 
!
!I've seen mixed results in the past with tx fees and confirm times. I've had some transactions take a really long time, even with what I thought was a good fee. I never made the time to record or study the results though until now.
I'll definitely be doing this more in the future. I figured it'd be a good historical reference as well. Glad to contribute to the forum and to bitcoin
I think that you're off to a good start, but there needs to be a bigger sample size and I think it might be worth factoring in the previous block full-ness and see if different used space in each block has an effect on the transaction fee for the transaction. Also maybe check hashing power and see if increase or decreased hashing rates are also a variable when it comes to transaction fees. No guarantees those factors actually have any affect on the value, but it might be interesting to look into.
So it means that whatever transaction fee you will put, it will always get accepted ? I always put little tx fees, and after this results I won't change it. Thank you for this study !
!
Very interesting experiment, The results are mixed but this should be investigated further.
Jump to: