Topic: To Fee or not to Fee - page 2. (Read 2071 times)
I think that BTC0.0005 will continue to be worth more and more... I personally don't think the fees will need to increase from that if the value keeps increasing. It's hard to say, though.
Transaction fees are a hot topic these days as we get closer to the maximum block size. If the block size is not increased fees are bound to grow, but unfortunately many bitcoin clients (including my own BitcoinSpinner) do not handle this well. Right now I am using a fixed fee of 0.0005 for every 1000 bytes, and eventually this will not cut it.
Transaction fees are complex (especially for end users), and for BitcoinSpinner I want a solution where the fee applied makes the transaction likely to get into the next few blocks.
Miners who use an unmodified bitcoind for mining still allow a chunk of gratis transactions with high priority, but I think this will go away due to maximizing profit, and eventually miners will look at fee/transaction-size-in-bytes (eventually considering chains of unconfirmed transactions and their associated fees, etc). So, generally speaking I believe that there will be a price measured in satoshis for getting a byte into the next block. (And not for every 1000 byte chunk as it is now)
So to me the question: How do I predict the cost of getting my transaction into the next few blocks?
Is really: How do I predict the cost of getting a byte into the next few blocks?
My half-baked thinking on this is to:
1. Look at the last 144 blocks (24 hours)
2. Filter away gratis transactions
3. Filter away the bottom 25% and top 25% transactions that include a fee (measured in fee-pr-byte)
4. Calculate f1 = my-transaction-size-in-bytes *
5. Calculate f2 = the fee using traditional fee mechanisms for my transaction (0.0005 pr 1000 bytes)
6. Final fee = max(f1,f2)
(Obviously step 4 and 5 will have to iterate until a fix point is reached as the size of the transaction may be affected by the fee size.)
Step 6 is there to avoid situations where f1 < f2, and miners still use the classic fee rules
On top of this the user could configure his wallet to be:
Economic: f1 = f1 * 1/2 (get confirmed when there is room)
Normal: f1 unmodified (get confirmed at a 'normal' rate)
Priority: f1 = f1 * 2 (get confirmed quickly)
This way end users have some control over their fees/confirmation-times without having an extended math degree, plus we get a fee market going.
What do you think?
Transaction fees are complex (especially for end users), and for BitcoinSpinner I want a solution where the fee applied makes the transaction likely to get into the next few blocks.
Miners who use an unmodified bitcoind for mining still allow a chunk of gratis transactions with high priority, but I think this will go away due to maximizing profit, and eventually miners will look at fee/transaction-size-in-bytes (eventually considering chains of unconfirmed transactions and their associated fees, etc). So, generally speaking I believe that there will be a price measured in satoshis for getting a byte into the next block. (And not for every 1000 byte chunk as it is now)
So to me the question: How do I predict the cost of getting my transaction into the next few blocks?
Is really: How do I predict the cost of getting a byte into the next few blocks?
My half-baked thinking on this is to:
1. Look at the last 144 blocks (24 hours)
2. Filter away gratis transactions
3. Filter away the bottom 25% and top 25% transactions that include a fee (measured in fee-pr-byte)
4. Calculate f1 = my-transaction-size-in-bytes *
5. Calculate f2 = the fee using traditional fee mechanisms for my transaction (0.0005 pr 1000 bytes)
6. Final fee = max(f1,f2)
(Obviously step 4 and 5 will have to iterate until a fix point is reached as the size of the transaction may be affected by the fee size.)
Step 6 is there to avoid situations where f1 < f2, and miners still use the classic fee rules
On top of this the user could configure his wallet to be:
Economic: f1 = f1 * 1/2 (get confirmed when there is room)
Normal: f1 unmodified (get confirmed at a 'normal' rate)
Priority: f1 = f1 * 2 (get confirmed quickly)
This way end users have some control over their fees/confirmation-times without having an extended math degree, plus we get a fee market going.
What do you think?
Jump to: