Title: [RFD] Future fee policy for relaying and mining Post by: Pieter Wuille on June 06, 2011, 02:09:57 PM This thread is an attempt to establish a more flexible fee policy for relaying and block mining. Note that these are, eventually, decisions that can and should be made by each miner separately (and, to a lesser extent, all nodes), allowing a free market. However, having a reasonable default policy in the standard client - possibly with some configuration parameters - can make everyone's life a lot easier.
Before I start, this is not directly about the fees enforced by the client when creating transactions. It's definitely related though, but should be determined based on observation of how the network as a whole behaves, and not necessarily be analogous to the rules used for relaying and mining. So, let's start with the current rules (as they are in git head, and will be in 0.3.23): For relaying:
For mining:
To summarize, these rules try to:
These all look like reasonable goals to encode in the fee policy, but the numbers look somewhat arbitrary and there is no flexibility. Furthermore, nodes that unconditionally drop transactions form a problem for the network's current growth pattern, as a 0.01 BTC (and soon maybe a 0.0005 BTC transaction) may very well be reasonable and useful things on the network soon, and we can't afford to keep issuing new versions of the client just to change the policy. Therefore, I would suggest the following general scheme:
The priority itself should be based on criteria that map to eventual cost for the network. Things I can come up with:
This would lead to eg. a priority formula of: A*(size + B*coinsplitting + C*numtxouts - D*timeinqueue) - fee, with:
So: any opinions, other general schemes, additional badness criteria, comments, remarks, analysis, flaws, bitcoins, ...? Title: Re: [RFD] Future fee policy for relaying and mining Post by: Matt Corallo on June 06, 2011, 02:35:30 PM I like the ideas, but the scheme is just as complicated as the old one, if not more. IMHO the two primary goals of fee policy reworking is to simplify it and give more control of it to the users.
There is no special free-tx zone, all transactions are handled in the same way. Absolutely.All transactions get a priority based on certain "badness" criteria (see further), compensated by fee and time waiting in queue. Absolutely, however, I dont think the priority should be "compensated by" but instead the fee and age of txins (aka time waiting in queue) should be a part of the priority (as age of txins is now).The memory pool is limited in size (configurable), and when it fills up, the lowest-priority ones are kicked out. Yep, but I feel this is getting too complicated as well. I would like to see fairly simplified options for just "minimum priority" (and some explanation of what different values might mean) and maybe some options on how much weight to give to different aspects of priority, ie "when Im mining, I dont care about tx size or txin age" which I think should offer similar control over fee requirements, without the complication (and keep the formula simple as you can just adjust A, B, C, D below).Miners select the top priority transactions from the queue, but can enforce a rule like average fee per block, or per txout, or per byte, ... to decide the cut-off point. This, together with priority that takes time in queue into account, makes sure that each transaction (which is not dropped through the memory constraint), is eventually included in a block sometime. The priority itself should be based on criteria that map to eventual cost for the network. Things I can come up with: Yep, and yes to age of txins.Size in bytes Number of txouts (or number of signature verifications in them). Other things, like something based on age of coins? Degree of "coin splitting" (see this post (http://forum.bitcoin.org/index.php?topic=7942.0), sum of logarithms of input amounts, minus sum of logarithms of output amounts). I prefer this over a "<0.01 is BAD" rule. Yes, as long as it doesnt get too complicated here. I prefer simply total value of txin/out as a part of priority (maybe squared or logged to change how much a given difference affects priority) and then have a number of txouts as part of the priority to handle splitting.This would lead to eg. a priority formula of: A*(size - B*(log?)txvalue(^2?) + C*numtxouts - D*ageoftxins) - fee, with:
|