Satoshi's paper talks about miners being able to set their own fee policies in future, especially when the generation output from a block drops significantly.

This is not yet implemented, and it's not exactly straightforward to do. The current client displays a dialog window telling the user that his transaction exceeds limits and asking if she wants to add a transaction fee. We definitely want to keep this feature, but it would become quite hard if every miner had his own fee policy.

I'd like to request comments on how it could be done.

My idea is to create a kind of language that would define miner's fee policy. For instance, the current rules from the mainstream client could be written roughly like this:

if sum(output.value) < 0.01 then:
  return { relay => true, accept => true, fee_required => 0.01 }

if sum(waiting_tx.size) < 27kB then:
  return { relay => true, accept => true, fee_required => 0 }

return { relay => true, accept => true, fee_required => 0.01 * (sum(waiting_tx.size) / 250kB)

relay => true means that the node agrees on forwarding the transaction matching the given criteria (i.e. if relay => false, then node won't propagate such a transaction further down the network)

accept => true means that the miner will accept such a transaction into the block as long as fee_required is met.

The code above doesn't cater for transaction prioritizing etc; but it's an example to show my idea.

Now.

When a miner solves a block, he propagates it through the network along with the miner's fee policy. Other nodes receive and store this policy along with the block (discarding policies older than some given amount of blocks). Whenever a user sends out a transaction, the node runs all the recent (say, 100) policies against it, providing the current sizes of block and all the other required input data, to see how many miners would require a fee for the transaction and how large the fee would be. It will then be able to tell the user something like: "Yo, your transaction is soo large that approximately 50% of miners will require a fee of 0.01, approximately 30% require a fee of 0.05 and approximately 20% will accept it for free, based on the current usage of the network. Would you like to play a ga^W^W^W set a fee to get your transaction processed faster?"

I don't think there's a need to make it complicated.

Allow each client to set a "fee per kilobyte", which can be any amount including zero. Let the miners set whatever policy they like.

That's enough to get a competitive market. Anything else is too complicated for Average Joe to understand.

I agree the simpler it is the better.

But the current default tx fee policy is already way too complicated for Average Joe to understand. It's hard for me to understand, and the details of it aren't even mentioned on the wiki, one would have to go to the C++ code directly to find out what the weightings are for priorities and stuff.

I don't think we could get away with a simple hard-set "fee per kilobyte", because we DO want some transactions to be free and some others to require a fee.

The fee is not "hard-set", it's a user interface option in the client.

Yes we do want some transactions to be free. What I expect will happen is that the cheapskates will set their fee to zero, and jostle for the limited number of free transactions. Everyone else wants their transactions to clear quickly and will set their client to pay "the going rate".

And how do you propose to determine "the going rate"?

Right... but like you said, an Average Joe has no clue about the current going rate for a tx fee. And he won't be able to determine when the next block is happening, how many transactions of what sizes are currently waiting to be included, etc... Assuming Average Joe wants his transaction processed ASAP, and does not want to wait for a block just to see if it gets included, and then re-transmit his transaction with a higher fee and all that, he needs to BE TOLD what the current going rate is. And the only way to do it is in software.

But that'll make him pay unnecessarily large fees at times.

That's great then. Remember, my structured way was only meant to provide a rough overview, not a binding contract.

Some of these different ways like time of day/week, or known addresses, can be catered for in the language. Some more complex ones could just have a flag like "I use a complex fee system" so a node would known how many non-standard miners there are. Interested people could then go to a website, see what sort of "complex" fee systems this miner uses, and perhaps even incorporate that into a new version of the language, if possible. Or just leave it at that.

Half-baked thoughts:

Broadcasting policies makes me nervous-- it is too easy to lie, and there might be some advantage to lying.

Couldn't clients infer all the information they need to know about what transactions/fees are being accepted by miners by keeping track of transactions in the memory pool and looking at the last 10,000-or-so generated blocks?

First thought: if this happens, we're somehow back to the standard bank model?

Many things are unclear.
How do miners know they have exclusivity on the tx? Even if you send the fee hardcoded to the miner address inside the tx, miners are still vulnerable to double tx attacks. So, it would require some trust and would somehow conflict with anonymity here, no?


If it's buried 1 deep, it would continue to get buried deeper at the speed of the network anyway. Why to pay for that?

Thread? (I couldn't find it)

SPV being lightweight mobile-like clients? They could just fetch an aggregated and processed transaction fee policy guess from a full node with some special protocol message.

Firstly, there is already a way described by Satoshi to re-send a transaction with a higher fee. Secondly, I found a few problems with such a solution:

1. You said you pay per gigahash. Let's say you paid to MineCorp1 100 BTC which is defined by their rules to cater for 100 Thash. They start up their rig and mine for 100 Thash and find nothing. All the user's money went to waste.

2. MineCorp1 can mine for 100 Thash and find a block, but actually have some incentive not to put the user's transaction in there. Because no-one can prove who actually found a block, they can pretend they didn't find anything and include other, more valuable transactions into the block.


3. The miner can just take the fee-paying tx and drop the user's transaction.

I agree, nice idea. Perhaps even a mixture between broadcasting pre-set policies and learning from the past could be used.

Hopefully there's not much incentive in lying.

Also, mind you, trying to "guess" a policy based on looking at the past might be more difficult. With a broadcast fee policy, you have an input (state of network, number of transactions waiting, etc.) and an algorithm (the fee policy), so you can predict the fee by applying this algorithm to this input. With looking at old blocks, you have an input and an output, but you have to guess the algorithm. Perhaps neural networks are good at this, but it's kinda hard to implement.

It's not so easy, but we'll face that problem sooner or later, so there'd better be a discussion for it :->