Transaction Fee Proposal #4171

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

The required fee on a transaction will ultimately be decided by miners on a per-miner basis (each miner can choose their own policy). AFAIK you can't force a fee policy on miners without soft forking. An economically rational miner will be awarding their scarce resource - block space - to the highest bidders.

I think the incentives are right at the moment. Fixed fees make larger transactions cheaper on a percentage basis, which encourages maximum transaction volume through the blockchain, meaning that cheaper transactions will be the first to be pushed off-blockchain if it becomes unaffordable. Subsidising blockspace for cheaper transactions flips this on its head and doesn't make economic sense for miners nor technical sense for scaling.

Yeah, this shouldn't be a code issue, but a proposed policy patch provided to miners...

I'm not sure why a hard fork would be necessary if bitcoind software rejects transactions without the appropriate fee. :/

Furthermore the statement "fixed fees make larger transactions cheaper on a percentage basis" conflicts with the statement "economically rational miner[s] will be awarding their scarce resource ... to the highest bidders." It would seem to me that "highest bidders" has nothing to do with "fixed fees" at all. :/

I'm also wondering about the statement "encourages maximum transaction volume through the blockchain" Is this the goal? I thought the goal was to achieve some sort of homeostasis vis a vis transaction volume and fees.

Also it would seem that providing for a fee schedule which conforms with Bitcoin's goals would be the priority here rather than having miners dictate fees. If miners are the priority then why not allow them to dictate block rewards? You seem to have the cart before the horse here -- set the fees and have the mining community adjust as they have and will to block rewards.

The proposal I've put forward achieves a somewhat stable transaction fee regardless of the transaction amount or bitcoin price. Only outliers (very large recent inputs and very small old inputs) are subject to a non-standard fee.

Sorry, I should have said soft fork not hard fork

By fixed fee, I mean paying for the transaction size regardless of the amount transacted. I guess "fixed" is not the best term.

I'm also wondering about the statement "encourages maximum transaction volume through the blockchain" Is this the goal?

It's not necessarily a goal but it's the result of bidding over the scarce resource (block space) rather than having miners effectively subsidise cheaper transactions out of their own generosity. Although I personally believe that maximising BTC volume transacted on-blockchain is the best outcome (arguably it allows the blockchain to secure the most economic activity possible), it's not very relevant to this proposal. It's up to miners to decide.

Can you explain why we're embracing the concept that fees are dictated by miners but block rewards aren't?

Can you explain why we're embracing the concept that fees are dictated by miners but block rewards aren't?

That's how bitcoin works. Block reward rules are enforced by every validating node, However, validation does not force any fee policy, so miners are free to include whatever transactions they want in their blocks. There are no rules that require the inclusion or exclusion of any valid transactions in a block.

I have no idea why you're repeatedly referencing validation of blocks. As I understand it the reference implementation will refuse to accept or relay transactions which don't meet certain criteria. This is the stage where fees should be -- and, as I understand it, currently are -- enforced.

I understand that miners don't need to include transactions in a block if they don't want to, yet a fee schedule is still currently in place pre-validation. I'm talking about future-proofing this fee schedule.

If the fees are dictated by miners then the proposition we'll be giving the users is "the fees were this much last month, this is what they are today, who knows what they'll be tomorrow -- good luck." It is a much better idea to have a predictable fee schedule, easily calculated pre-transaction. Then miners can choose to participate or not, just as they do today.

Bitcoin is a consensus protocol. That means that every two nodes must be able to independently judge whether a block is valid, and come to the exact same conclusion. If two nodes disagree about whether a block is valid or not, they ignore each other (assuming the other is trying to attack them by serving invalid data). This means that if two groups of nodes with different rules both have hash power, but the larger of the two groups produces blocks the other side considers invalid, you get a blockchain fork. Both groups start working in their own world, ignoring the rest. This is a disaster: every coin that existed before the split can be spent once on each side.

A "soft fork" is a change to the protocol rules that only makes things invalid that were previously valid. A soft fork is safe (doesn't actually cause the blockchain to fork) as long as majority of the hash power enforces the new rules.

A "hard fork" is a change to the protocol rules that does anything else (change serialization, makes thing valid that would previously be invalid, ...). A hard fork requires every full node in the world to upgrade (not just the majority, and not just miners). Those who don't will inevitably end up with their own (slowly growing) chain.

A policy is a rule that does not change the validity of blocks, and can't otherwise cause forks. These are usually about transactions, rather than blocks (as transactions are independent, and don't require the world to agree about any state). They include DoS protections, acceptance rules for entering the mempool, the scheduling miners use to put transactions into blocks, ...

Currently, the fee structure is a policy. You can change it in your client, and nothing will break. To an extent, every node in the network can change the policy to something they like, and things wouldn't break. The network wouldn't necessary keep working well, but at least nodes wouldn't start disagreeing about the state of the world.

To do what you want - enforce a fee structure - you must make them a consensus rule. Just implementing it as a transaction relay policy isn't enough: miners can just run different code, and as policy can't change the validity of a block, every node would need to accept those blocks, even if they don't like the transactions in it.

Turning the fee rules into a consensus rule is technically possible. It would be a soft work (you want nodes to reject blocks that don't follow the fee rules), and that has associated risks. The only question is whether we want this to be a consensus rule. If we'd ever want to undo it, it would need a hard fork, so we better be sure about it.

In my opinion, it's such a dramatic change about the properties of the system (especially, future properties) that it would be a violation of the implied "social contract" of the system. However, that's not a very strong argument if it solves an actual or perceived problem.

More technically: how do you deal with decreasing subsidy? Who will pay miners for network security if the subsidy doesn't, and more is required than what your fee rules define? We don't know the future of the system, or for what kind of transactions it will be used. Maybe it will be many low-value transactions, maybe it will be few high-value transactions. Yes, variable fees are an inconvenience, but I don't think forcing a fee schedule is the solution. Over time, I think we'll see a fee market develop, but people live with changing gasoline prices too, no?

In any case, this is a discussion for the mailing list as it would affect much more infrastructure than just the reference client, and you'll need very wide agreement that it is a good idea to pull off (without risking forks).

I have no idea why you're repeatedly referencing validation of blocks. As I understand it the reference implementation will refuse to accept or relay transactions which don't meet certain criteria. This is the stage where fees should be -- and, as I understand it, currently are -- enforced.

You are making the assumption that transactions must be relayed through the a reference implementation node when actually it can be sent directly to a miner and mined thus bypassing the relay rules of nodes. That is why concensus among miners matters.

sipa: why would it not require a hard fork to implement yet require one to remove?

Also, the formula would rely on the percentage, which could be changed just like the base fixed fee is now.

I think determining the proper percentage would take some research and discussion, but once implemented wouldn't need to be changed, ever. It would need to be set so that Bitcoin most "regular" bitcoin transactions have a very low fee compared to alternatives, just as they do now, yet would support the necessary mining infrastructure. Knowing what is "necessary" is up for debate.

Once the percentage was set then, again, we have a policy which is predictable which miners can choose to participate in or not.

Here is the key takeaway: right now miners are rewarded with new coins. Nobody is in the mining business to make money with transaction fees. Once they are they need certainty. Transaction fees to miners are currently uncertain because they are fixed and therefore have little relation to a bitcoin's value -- and "standard" fees need to constantly chase a bitcoin's value and be changed. By implementing a percentage-based fee structure fees now become predictable for miners and they can plan, just as they can reasonably plan now for block reward halving. This in addition to the certainty that is gained by Bitcoin "users."

Certainty is good. :)

This kind of big changes that uproot the entire system should be discussed on the mailing list, not here. The scope of this bug tracker is technical issues with the Bitcoin Core implementation.

@pgrigor Adding an extra rule that only makes previously valid things invalid only needs a soft fork (all old nodes will accept the new blocks), but removing it or changing it requires a hard fork (old nodes would reject new blocks, so they must all be upgraded before the change can happen).

The rest is indeed a discussion for the mailing list.

Why is a fork a disaster? It's part of the design of bitcoin and isn't necessarily a bad thing.

If someone was to submit a pull request that provided a command line option that allows full nodes to choose not to relay blocks created by overly greedy miners, perhaps based on the suggestions in this issue, would it be considered for inclusion by the core developers?

@rebroad I should have been more specific. I'm not talking about the occasional 1 or 2 deep fork caused by simultaneous mining, which gets resolved automatically. Nodes that disagree about the rules (intentionally, or because of an implementation bug) never resolve - they just consider each other's blocks invalid and keep ignoring them forever.

@rebroad Not relaying blocks is silly. As a node in the network you have every reason to relay blocks that you accept yourself (as you want other nodes to accept them too), and we don't relay blocks we don't consider part of the best chain ourselves. If your suggestion is to not accept blocks that seem "greedy", no, that would cause permanent forks as described above.

I'm proposing a "reluctantly accept" feature in that it accepts the block reluctantly and indicates this in the GUI but didn't assist in its propagation hoping that instead a more savory block instead takes its place. This certainly could be a way to really start giving some power to the node operators who aren't also miners, or at least, let them feel they have some say whether practically it makes a significant difference or not. It'd be a win-win IMHO and would encourage more full node operators by empowering them with more of a say in the evolution of bitcoin.