Consider restoring quantized fee behavior #1722

In c555400c @gavinandresen added the fee per kb computation with the following logic:

  // This is a more accurate fee-per-kilobyte than is used by the client code, because the
  // client code rounds up the size to the nearest 1K. That's good, because it gives an
  // incentive to create smaller transactions.
  double dFeePerKb =  double(nTotalIn-tx.GetValueOut()) / (double(nTxSize)/1000.0);

While the logic given in the comment is sound, there is a counter argument: It can be productive for the network to make transactions a little larger, e.g. spending additional dust inputs. With the quantized fee logic nodes could costlessly add in dust whenever they had room before the next fee increment. This makes it less costless.

I think we should either specifically incentivize txout set size reductions or restore the quantized behavior.

Thoughts?

I think we should have an economic incentive to reduce the coin set, i.e. make the priority calculation take the effect on the coin set into account.

@sipa I don't think anyone is opposed to that idea; but I could write a script that produces an infinite number of possible ones, and I don't think we know how to agree on one.

I intend to implement code that will estimate how high a priority a transaction needs to have to get into one of the next few blocks, based on watching the memory pool and the blockchain.

(aside: it will also independently estimate how high a fee it needs to have)

I imagine the main dust-sweeping code will be associated with free transactions, and will do something like: Create transaction with no extra inputs. IF: priority is significantly higher than necessary to get into the next few blocks THEN: sweep up one or more small, dusty inputs.

For the fee case, the rounding up aught to be done in the GUI, just so user see: "Recommended fee: 0.0012 BTC" instead of "Recommended fee: 0.00118565 BTC"

And if the GUI is rounding up, it's algorithm should be something like: Compute rounded-up recommended fee Add dusty inputs while full-precision fee is <= rounded-up fee

Further random thought:

My personal preference would be a "Don't bother me if the fee is less than 0.5% of the transaction value, I'm willing to pay 0.5%" setting.

That would imply a policy of "sweep up dust into large-bitcoin-value transactions, if doing so keeps the fee less than 0.5% but costs less than the value of the dust."

I'm not sure that "use rounded-up part of fee to pay for sweeping dust" is the right approach. In my opinion, sweeping dust should be encouraged (i.e. it shouldn't cause punishment of the transaction).

In my opinion the tx fees involved with eventual spending of a txout should be associated with the creation of the txout. IOW, I recommend ignoring txins when measuring the size of a transaction for fee purposes, and doubling the fee on txouts.

You level similar comments on issue #1675 and I responded to them there.