Miners will have to set their fees somehow, and spenders will have to have some expectation of what a reasonable fee is for quick processing. In both cases an automatic method would be preferable because people don't have time to stay up to date with the details of the network and set reasonable policies.
This would provide a reasonable default (from which you can opt-out of course). I'm not sure how that's any different than the current policy, except it's less arbitrary.
Topic: Network-adjusted transaction fees? (Read 811 times)
The current system is based on reducing DOS attacks on the system by making them expensive. The envisioned future system will be market based, with miners competing for transactions by setting their own policies, and spenders competing for miners by setting their own fees.
Setting a target fee level based on recent activity isn't needed for either system, nor for an intermediate step in the evolution from here to there.
Setting a target fee level based on recent activity isn't needed for either system, nor for an intermediate step in the evolution from here to there.
Why wouldn't there be a need?
Once generation of new coins tapers out, there will have to be sizable transaction fees assessed each block, to ensure there isn't a reduction in security of the network. Once bitcoin goes mainstream, there will be orders of magnitude more transactions being processed per-block, and a commensurate increase in the size of the blockchain.
I've played around with some economic models of what per-block transaction fees would be needed to maintain the security of a mature, stable monetary base currency and avoid a tragedy of the commons. Working backwards from those goals and the network parameters, one can arrive at an estimate of the minimum necessary per-tx/per-kB transaction fees. The network parameters are continuously changing, however, so occasional re-adjustments would be necessary, just as is the case with the difficulty parameter.
The bitcoin developers are continuing to tweak the transaction fee parameters and rules with each release. Automating this process would not only make the network safer, it'd take a lot of the heat off the backs of the core developers making these unpopular choices.
Once generation of new coins tapers out, there will have to be sizable transaction fees assessed each block, to ensure there isn't a reduction in security of the network. Once bitcoin goes mainstream, there will be orders of magnitude more transactions being processed per-block, and a commensurate increase in the size of the blockchain.
I've played around with some economic models of what per-block transaction fees would be needed to maintain the security of a mature, stable monetary base currency and avoid a tragedy of the commons. Working backwards from those goals and the network parameters, one can arrive at an estimate of the minimum necessary per-tx/per-kB transaction fees. The network parameters are continuously changing, however, so occasional re-adjustments would be necessary, just as is the case with the difficulty parameter.
The bitcoin developers are continuing to tweak the transaction fee parameters and rules with each release. Automating this process would not only make the network safer, it'd take a lot of the heat off the backs of the core developers making these unpopular choices.
I don't think anyone has ever coded such a thing. There is no reason to.
Has anyone experimented with having the expected/automatic transaction fees adjust at regular intervals, based on the recent transaction history? It wouldn't be too difficult to include in the difficulty retargeting code an adjustment of the tx fees constants based on whether the number and/or average size of transactions have increased/decreased over the last 2016 blocks.
I'm considering doing something similar for my demurrage-based altchain, but was surprised to find no hits on google for retargeting transaction fees...
I'm considering doing something similar for my demurrage-based altchain, but was surprised to find no hits on google for retargeting transaction fees...
Jump to: