I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs.

By using a percentage of the input amount the transaction fee will always make sense no matter what the "price" of bitcoins may be in fiat; by dividing the fee by the number of confirmations we discourage hasty spends and reward savings (ie. old inputs); by multiplying the fee by the number of inputs we discourage "payment fragmenting."

Let me further explain payment fragmenting by way of an example: Let's say I get paid $2,500 in bitcoins per month from my job. If I then take that $2,500 and pay for a coffee (right away, 1 confirmation) I'll be charged a fee of $2.50 because I'm charged according to the input amount, not the actual transaction size. Because of this it would behove my employer to pay me the $2,500 as one transaction with, perhaps, 100 output addresses at $25 apiece so that when I pay for my coffee I use one of the $25 unspent outputs. By multiplying the transaction fee be the number of inputs this provides a disincentive for payment fragmenting as multiple inputs will be required to pay for larger purchases.

Furthermore this provides an incentive for wallet software to use the oldest input(s) which most closely match the transaction amount. For the example above: In real life a user's wallet would have a number of inputs to choose from and wouldn't use the newest "paycheck" input for the coffee purchase. Furthermore, even if the $2,500 input was the only input available, by waiting for 100 confirmations (less than a day) the transaction fee would be 2.5 cents.

Transaction fees would then be calculated by the following formula:

((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS

The INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by the creator of the transaction and should be optimized for the transaction amount -- the BASE_PERCENT would be hard-coded in the bitcoind software. The special case of zero CONFIRMATIONS will be treated as 1 confirmation in order to avoid a divide by zero error.

For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost:

• $1 to send $1,000,000 that has 100 confirmations;
• $0.10 (10 cents) to send $1,000,000 that has 1,000 confirmations (approx. 1 week);
• $0.10 (10 cents) to send $100 which has 1 confirmation;
• $0.01 (1 cent) to send $100 which has 10 confirmations;
• $0.001 (1/10 cent) to send $100 which has 100 confirmations (less than a day);

I've put together a spreadsheet which shows the various fees by amount and confirmations -- the spreadsheet assumes one input for a transaction:

https://docs.google.com/spreadsheets/d/1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=sharing