[RFC] Responsibility of transaction fees

[davout]

Automatic transaction fees were put in place so that the network isn't DDoS'd, I argue that they should be removed from the client and the responsibility of charging for transactions should be passed to the miners.

If someone really wants to DDoS the network they simply modify a couple of lines in the client.

So I don't think it's an effective protection against anything if the miners themselves don't enforce the presence of a fee depending on the transaction they are processing.

[Pieter Wuille]

I agree miners should eventually become those who set the policy for fees. The thing is that the spam-prevention is not only enforced by miners, but by the whole network, by not relaying transactions which are too "spammy", and fees are a pretty good way to classify transactions as less spammy.

Nonetheless, this does need discussion. The current rules are not flexible and cannot adapt easily enough to the network (both when the value goes up, or the typical pattern of transactions changes). In 0.3.23, the default fees will be decreased, and there are plans to be able to add the ability to override the minimal fee rules afterwards, at your own risk of not having the transaction relayed at all by the network.

[xf2_org]

Automatic transaction fees were put in place so that the network isn't DDoS'd, I argue that they should be removed from the client and the responsibility of charging for transactions should be passed to the miners.

If someone really wants to DDoS the network they simply modify a couple of lines in the client.

Clients will not relay spammy tx's, so I think you misunderstand how the system works.

[Garrett Burgwardt]

It should be suggested by the client to include a tx fee, but not forced.

[xf2_org]

It should be suggested by the client to include a tx fee, but not forced.

You are welcome to comment on and contribute to "Better Fee UI" pull request:

    https://github.com/bitcoin/bitcoin/pull/289

[davout]

Clients will not relay spammy tx's, so I think you misunderstand how the system works.

I suspected it, but thought that only non standard txs weren't relayed, I guess that if a small transaction without a fee is considered non standard.

However I don't think that the amount of a transaction is a sufficiently accurate heuristic to classify it as spam.

It's obviously pretty hard to find good ones to tackle this problem,

a couple of ideas :
 - go back to the grand-father of bitcoin and implement a hashcash like system with a hash target that decreases with the amount the transaction
 - statistical comparison of transaction amounts with the averages/medians of the last X hours/days etc.
 - simply limiting the amount of small transactions that can transit through a node in a given timespan

[gigitrix]

Nothing to add to the discussion, but just to say that fee transparency is my most important bitcoin "request", followed by fee control. I hope you guys resolve this in an effective way.

[theymos]

My view of a perfect fee system:

Senders can choose any fee they want. The default fee is calculated by analyzing past blocks. Sends must be cancelable, which will allow people to test fees and make mistakes without losses.

Mining fees start at a reasonable default, but they can be changed in the GUI.

For relaying, non-free transactions (determined based on configurable rules with reasonable defaults) are always relayed. Free transactions are dropped randomly with a probability according to their priority. So you can always get free/cheap transactions broadcast if you keep resending long enough.

[ByteCoin]

I agree that transactions should be able to be superseded. I imagine that calculating fees by analyzing blocks will be a hard problem.

Free transactions are dropped randomly with a probability according to their priority. So you can always get free/cheap transactions broadcast if you keep resending long enough.

That seems unfortunate as when you make the decision to drop a transaction, you're wasting all the preceeding relayer's efforts who made the decision not to drop it. The originator is going to keep resending it as it costs them nothing and next time you may resend it and the next node might drop it which wastes your work.

The basic problem is that nodes are not rewarded for relaying and can't be punished when they fail to do so.

ByteCoin

[Sukrim]

I'd rather have a standardized "Fee sheet" that can be handed out by pools/miners, stating which kinds of transactions they will include and which main nodes they operate (to directly send transactions to).

Import this document to your client and you can be sure that at least this mining entity will accept the transactions you make. Import several (all?) and your client will determine the cheapest fee for your transaction (or the fastest one, which fits most "fee sheets").

Clients could even "announce" their fee schema to other clients, so after some time each client knows the fee schemas of the whole network. I'm not sure how this can be done in a distributed non-spammable way though and I think for "fee sheets" a central repository might be better, which again goes against the distributed nature of BTC. This would however be a client feature, not a protocol feature.

[Frozenlock]

Please keep in mind I do throw this idea with my ôôô so limited knowledge.
I'm sure this have been proposed already, but....

Couldn't the contract be used when you're not sure the transaction will ever proceed?

Contract example: if after 50 blocks the transaction isn't confirmed, it's considered canceled and it will never send the BTC to the receiver address.

If the client knows this rule, it will simply be able to re-spend the BTC after 50 blocks, no question asked. 
If the first transaction was to ever be confirmed, but after the said 50 blocks, it simply would check the contract and not send the BTC.

[Gavin Andresen]

RE: Fee sheet:  won't work, miners will lie to get higher fees.

RE: analyzing previous blocks to determine fees:  I think it could work. Keeping track of how long transactions take to get into a block and looking at what transactions are in past blocks would, I think, work pretty well.  Until/unless the criteria for including transactions gets really complicated.  And new clients that haven't seen many transactions (and so can't tell how long prior transactions had to wait before being included in a block) might be an issue.

When we have multiple client implementations one of the ways I imagine they'll compete is to have smarter calculate-the-optimal-fee algorithms ("Use SpiffyBits(tm) and pay 2% lower transaction fees than the original bitcoin client!").

RE: hashcash for transactions:  that is exactly equivalent to fees (because you could be hashing to earn block rewards instead of hashing to get your transactions accepted).

RE: limiting number of small/free transactions that can go through a node in a given timespan:  we're already doing that.

RE: canceling transactions:  are there really people who would rather have their transaction tied up for half a day because they don't want to pay a half-a-penny fee?

RE: randomly dropping low-priority txns: interesting idea. I've been thinking that dropping the connection to a peer that is sending you "too many" low-priority transactions might be a good idea (where "too many" is maybe N standard deviations away from the number your average peer is sending you... or something....)

[Gavin Andresen]

The basic problem is that nodes are not rewarded for relaying and can't be punished when they fail to do so.

Well... they COULD get punished for failing to relay.  Just drop/ban them if they're not sending you "enough" valid transactions.

[xf2_org]

RE: canceling transactions:  are there really people who would rather have their transaction tied up for half a day because they don't want to pay a half-a-penny fee?

Well we do need some way of cancelling transactions that refuse to confirm.

* xf2_org plugs for his deterministic TX proposal

[Dude65535]

RE: canceling transactions:  are there really people who would rather have their transaction tied up for half a day because they don't want to pay a half-a-penny fee?

If I was sending coins to a bitcoin savings wallet, I would not care if it takes the transaction 3 days to confirm.

[FreeMoney]

I know it isn't implemented, but can't a fee be 'added' to an unconfirming tx by creating a transaction that depends on it that has a fee? Now the miner does both and gets the fee on the second, but can't get the fee without making the tx valid by doing the first.

[Hans0]

I think both should enforce fees by default because:

- it provides a limit to transaction load (we don't have enough experience with high load and this would be a safeguard)
- it ensures mining will always take place

We should however lower the minimal fee by factor 10 or 100. The price has risen considerable and will continue to do so.

[davout]

- it provides a limit to transaction load (we don't have enough experience with high load and this would be a safeguard)

I argue that a mandatory minimal transaction fee is not the Right Thing(c) to prevent spam, keep load under control.

- it ensures mining will always take place

This is a misconception, bitcoin is self regulating in this regard.
If the block reward is zero and no fees are collectable the miners simply won't mine until people want transactions processed and start adding fees to their transactions, this point has already been discussed thoroughly.

the Right Thing, copyright 2009-2011 Gavin Andresen

[Hans0]

davout, you are correct with regards to mining. thx for clearing this up.

I argue that a mandatory minimal transaction fee is not the Right Thing(c) to prevent spam, keep load under control.

You are correct but I advocate being conservative because the network has not been tested for its limits in all practical regards. AFAIK the network has never received a sudden 100x traffic spike - can we be sure it would be operational?