Topic: [RFD] Future fee policy for relaying and mining (Read 1065 times)

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.
Absolutely.
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).
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).

Yep, and yes to age of txins.

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:

• A: fee per byte
• B: bonus bytes per tx's value (in BTC squared or logged, etc)
• C: penalty bytes per txout
• D: bonus bytes per average number of blocks since txins were confirmed

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:

• If a transaction has an output less than 0.01 BTC, a fee of 0.0005 is required.
• If too many free transactions have already been relayed in the near past, a fee of 0.0005 is required.
• If a transaction is at least 26000 bytes, it needs a fee of 0.0005 per started 1000 bytes.
• If a transaction is at least 249000 bytes, it needs a progressively larger fee, as the size approaches 499000 bytes.

For mining:

• If a transaction is not placed in the first 27000 bytes of a block, or not in the first 4000 bytes and is considered low-priority, a 0.0005 fee is required per started 1000 bytes.
• If a transaction is not placed in the first 250000 bytes, it needs a progressively larger fee as the block's size approaches 500000 bytes.

To summarize, these rules try to:

• Prevent bitcoin dust (very small txouts).
• Prevent spammy transactions from ending up in the block chain, or even from being relayed.
• Make block storage space increasingly more expensive, so that increased demand should lead to increased fees.

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:

• There is no special free-tx zone, all transactions are handled in the same way.
• All transactions get a priority based on certain "badness" criteria (see further), compensated by fee and time waiting in queue.
• The memory pool is limited in size (configurable), and when it fills up, the lowest-priority ones are kicked out.
• 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:

• Size in bytes
• Degree of "coin splitting" (see this post, sum of logarithms of input amounts, minus sum of logarithms of output amounts). I prefer this over a "<0.01 is BAD" rule.
• Number of txouts (or number of signature verifications in them).
• Other things, like something based on age of coins?

This would lead to eg. a priority formula of: A*(size + B*coinsplitting + C*numtxouts - D*timeinqueue) - fee, with:

• A: fee per byte
• B: penalty bytes per degree of coin splitting
• C: penalty bytes per txout
• D: bonus bytes per second in queue

So: any opinions, other general schemes, additional badness criteria, comments, remarks, analysis, flaws, bitcoins, ...?