If they pick 0%, *all* of the fees drop the 0%. If a fee is more than p, the miner only gets p of every transaction.
I chose for it to be relative to the transaction because including transactions should be negligible, and the amount of benefit a user gets in proportional to the value of their transactions.
Topic: Is this a viable solution to the Tragedy of the Commons problem? (Read 609 times)
p is a number from 0% to 100% choosen each block by the miner. It is the percentage of each transaction that are sent as fees. This way, within a single block, everyone pays the same rate.
The problem with low fees is that miners are willing to include transactions with low fees because rejecting them is throwing away free money -- the marginal cost of including a transaction is very low. Plus, even if one miner excludes low fee transactions, other miners will include them. As a result, users are not motivated to pay more unless they need the transaction in the next block.
So, now that we understand the problem...
If miners can choose 0% (or even 1%), then how does a percentage fix the problem of accepting low fees? Miners already pick transactions based on fee (along with other criteria). I don't see how you proposal changes anything.
Finally, transaction value has no effect on the cost of including a transaction, so it doesn't sense for miners to base the minimum fee on the value of the transaction. However, users do care about the fee relative to the amount of the transaction. A user sending $0.01 won't want pay a $0.05 fee. The result of this conflict in priorities will be the inevitable formation of two or more systems differentiated by transaction value. High value transactions will use Bitcoin and low value transactions will use something more appropriate for micropayments.
p is a number from 0% to 100% choosen each block by the miner. It is the percentage of each transaction that are sent as fees. This way, within a single block, everyone pays the same rate.
How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.
If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.
If a transaction comes with a fee that is less than p, that transaction can't be included in that block.
If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.
If a transaction comes with a fee that is less than p, that transaction can't be included in that block.
How is p determined and what is it a percentage of?
Well sure it will be in the future, but bitcoin is supposed to be futuristic technology. Planning ahead is a good thing.
This problem should occur only in the distant future.
Currently, miners get most of their money through the block reward. Fees account for a negligible portion.
Even with the reward halving, (expected) appreciation of bitcoin would result in this remaining the same.
Currently, miners get most of their money through the block reward. Fees account for a negligible portion.
Even with the reward halving, (expected) appreciation of bitcoin would result in this remaining the same.
Quote
It seems to me that this problem can only occur if there is little or no competition for getting included into blocks.
That is correct. The problem is, limited block space is bad. It limits the throughput of bitcoin.
It seems to me that this problem can only occur if there is little or no competition for getting included into blocks.
So long as block space is limited and there is significant competition to be included, then transaction fees should be sufficient to support mining at a sustainable level.
So long as block space is limited and there is significant competition to be included, then transaction fees should be sufficient to support mining at a sustainable level.
Tragedy of the Commons (https://en.bitcoin.it/wiki/Tragedy_of_the_Commons) is a problem that bitcoin will face as miner fees decline. Since including a transaction in a block is negligible, miners will accept all transactions with positive fees (no matter how low). Then, users will set their fees to the minimum possible. This in turn leads to less bitcoins going to fees, and less network security (since the cost of 51% attack = cost of mining = revenue of mining = fees at this point).
Many solutions have been proposed, but I don't like any of them (since most of them involve hard coding constants). I have a solution that requires no hard coding of constants!
How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.
If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.
If a transaction comes with a fee that is less than p, that transaction can't be included in that block.
This means that if a miner selects too low of a p, they will get less money (since all transactions are lowered to that amount), but if they they choose to high of a p, they will get less money (because there will be some transactions they can't include). They have to choose the correct p, which won't approach 0! Users in turn have to include enough fees to get accepted into blocks. In actuality, if there are a bunch of low fee transactions, someone will eventually include them with a low p, since there are so many. So your fee determines basically how soon your transaction gets confirmed.
What do you think?
Many solutions have been proposed, but I don't like any of them (since most of them involve hard coding constants). I have a solution that requires no hard coding of constants!
How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.
If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.
If a transaction comes with a fee that is less than p, that transaction can't be included in that block.
This means that if a miner selects too low of a p, they will get less money (since all transactions are lowered to that amount), but if they they choose to high of a p, they will get less money (because there will be some transactions they can't include). They have to choose the correct p, which won't approach 0! Users in turn have to include enough fees to get accepted into blocks. In actuality, if there are a bunch of low fee transactions, someone will eventually include them with a low p, since there are so many. So your fee determines basically how soon your transaction gets confirmed.
What do you think?
Jump to: