Pages:
Author

Topic: Bitcoin Fee Experiment May 9 2016 (Read 1002 times)

legendary
Activity: 3402
Merit: 5004
https://merel.mobi => buy facemasks with BTC/LTC
May 10, 2016, 01:56:48 AM
#21
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.
legendary
Activity: 1078
Merit: 1011
May 10, 2016, 01:52:48 AM
#20
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.
jr. member
Activity: 33
Merit: 1
May 10, 2016, 01:52:24 AM
#19
wow Im surprised I didnt think to do this or someone earlier lol

amazing how the most simple ideas sometimes get missed.


good study

thanks RD  You're the one etc..... :-D
jr. member
Activity: 33
Merit: 1
May 10, 2016, 01:51:04 AM
#18

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.
legendary
Activity: 1232
Merit: 1030
give me your cryptos
May 09, 2016, 11:19:32 PM
#17
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
legendary
Activity: 1652
Merit: 1088
CryptoTalk.Org - Get Paid for every Post!
May 09, 2016, 10:51:55 PM
#16
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.
legendary
Activity: 1442
Merit: 1000
May 09, 2016, 10:49:34 PM
#15
wow Im surprised I didnt think to do this or someone earlier lol

amazing how the most simple ideas sometimes get missed.


good study
jr. member
Activity: 33
Merit: 1
May 09, 2016, 09:19:41 PM
#14
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...
legendary
Activity: 1652
Merit: 1088
CryptoTalk.Org - Get Paid for every Post!
May 09, 2016, 07:33:18 PM
#13
How old were your inputs? That would have affected the priority. High priority stuff gets confirmed pretty fast.
jr. member
Activity: 33
Merit: 1
May 09, 2016, 05:06:18 PM
#12

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 Smiley
sr. member
Activity: 294
Merit: 250
May 09, 2016, 04:56:24 PM
#11
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.
jr. member
Activity: 33
Merit: 1
May 09, 2016, 04:49:52 PM
#10
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.
jr. member
Activity: 33
Merit: 1
May 09, 2016, 04:39:50 PM
#9
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.
legendary
Activity: 1568
Merit: 1268
May 09, 2016, 04:30:22 PM
#8
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.
jr. member
Activity: 33
Merit: 1
May 09, 2016, 04:24:45 PM
#7
should also include "no fee" test.

Good suggestion. Next time I do this I'll include a no fee test as well.
full member
Activity: 202
Merit: 157
May 09, 2016, 04:20:59 PM
#6
should also include "no fee" test.
jr. member
Activity: 33
Merit: 1
May 09, 2016, 04:05:44 PM
#5
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 Wink !

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 Smiley
hero member
Activity: 490
Merit: 520
May 09, 2016, 03:29:18 PM
#4
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.
sr. member
Activity: 322
Merit: 250
May 09, 2016, 03:23:18 PM
#3
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 Wink !
full member
Activity: 120
Merit: 100
May 09, 2016, 03:11:40 PM
#2
Very interesting experiment, The results are mixed but this should be investigated further.
Pages:
Jump to: