Thoughts on making fees for relaying transactions more flexible

[jav]

Reading the current Bitcoin source on github, I can identify theses rules for getting a transaction relayed by a node:

- if a transaction is fairly large, 0.01 BTC per kb is required
- if I want to send less than 0.01 BTC, a fee of 0.01 BTC is required
- if I want to avoid the rate-limiter, a fee of 0.01 BTC is required
- something about raising fees when a block is almost full (not sure I understand that completely)

Any other rules I have forgotten?

To be honest, I don't really like where this is going. Especially this arbitrary value of 0.01 BTC, which is hardcoded in the source. Sure, it can be changed at some point, but it just doesn't seem very flexible.

Can't we come up with something that auto-adjusts in some way? For example: A node could commit to a certain maximum number of transactions relayed per minute. If it sees that the rate is exceeded, it gradually increases the fee it requires, until the rate is within limits again. If someone starts penny-flooding again, you only have to pay a little more than the attacker, instead of having to jump to the arbitrary value of 0.01 BTC right away. (Just to clarify: I know that the node isn't getting any fees for relaying transactions. When I say it "requires a fee", I mean it in the sense that it wants to see that fee on the transaction to consider it for relaying.).

Also: In the discussion about fees, you often hear: "the miners will sort it out". I think it's important to be clear that there are two different issues:
1) What transactions to include in a block. If this gets crowded, miners can figure out whatever fee structure they think will work best. This is very flexible and nice
2) What transactions to relay. Because bandwidth is a limited resource as well. And that's not flexible at all right now, with an increasing number of fixed rules in the source code. This is where I would like to see some auto-adjusting mechanism.

[1713969004]

1713969004

[1713969004]

1713969004

[1713969004]

1713969004

[xf2_org]

You're welcome to run a miner and experiment

As long as the transactions and blocks can be validated by the clients on the network, miners are free to do what they want.  Miners can experiment with alternate TX selection methods, such as ones you've described.  Some miners (with very, very little hash power) already accept any valid TX, regardless of fee.  It's the free market at work...

[khal]

Pool managers should publicly say what rules they follow, what they accept, what they don't and what they prioritize if they don't follow the "standard" rules of bitcoind. Do they already use other rules ?

[jav]

You're welcome to run a miner and experiment

Well, let's say I run a miner that accepts transactions below 0.01 BTC for a 10% fee. So someone out there sends a transaction of 0.005 BTC with a fee of 0.0005 BTC. Problem: I'm never going to see that transaction, because all the nodes in between won't relay it, because they require a 0.01 BTC fee on everything below 0.01 BTC (the new "dust rule").

Or are you saying I need to be in direct (network) contact to everyone who potentially wants to take advantage of my fee structure? is this the expectation?

[bitlotto]

You're welcome to run a miner and experiment

Well, let's say I run a miner that accepts transactions below 0.01 BTC for a 10% fee. So someone out there sends a transaction of 0.005 BTC with a fee of 0.0005 BTC. Problem: I'm never going to see that transaction, because all the nodes in between won't relay it, because they require a 0.01 BTC fee on everything below 0.01 BTC (the new "dust rule").

Or are you saying I need to be in direct (network) contact to everyone who potentially wants to take advantage of my fee structure? is this the expectation?

The person making the transaction needs to be connected to the miner somehow either directly or through a node that will relay it. The person could connect using: -addnode=(node address) and connect to said miner.

[xf2_org]

You're welcome to run a miner and experiment

Well, let's say I run a miner that accepts transactions below 0.01 BTC for a 10% fee. So someone out there sends a transaction of 0.005 BTC with a fee of 0.0005 BTC. Problem: I'm never going to see that transaction, because all the nodes in between won't relay it, because they require a 0.01 BTC fee on everything below 0.01 BTC (the new "dust rule").

That is correct, that nodes won't relay the TX.

However, if a miner accepts a TX into a block, then all nodes will relay that block (including the TX).

Therefore, you must connect directly to miners that accept weird transactions, if you are producing weird transactions.

[Luke-Jr]

Therefore, you must connect directly to miners that accept weird transactions, if you are producing weird transactions.

Or just connect to the free transaction relay network which will relay "weird" (really taboo) transactions between connected nodes.

[BitcoinBonus]

I'm also very concerned about the 0.01 BTC hard-coded transaction fee.  I was very pleased to find that bitcoin transactions were so inexpensive when I discovered Bitcoin in December 2010, and at the time, the optional 0.01 BTC fee seemed resonable. But with the way the market is going, with bitcoin breaking $4.00 USD today, a transaction costs 4 cents USD, and this could someday creep into the realm of a fee greater than what Visa/MC or Paypal charge for some transactions.  What would it take to make the transaction fee a percentage fee of the transaction amount? Or, is there a way I could buy a "Monthy" contract with a miner to send all the transactions I've got for that single monthly fee?

I'm glad to hear the new client allows transactions smaller than 0.01, but that feature isn't very useful if the transaction fee is set to 0.01 BTC. The great promises about Bitcoin being such a Divisible form of currency disappear in this scenario and the possibility of individual micropayments is gone as far as I can tell.

[khal]

Almost all transactions can be sent without a fee.

How to avoid fees :
- do not send payment less than 0.01 BTC
If the GUI propose you a fee, there is 2 possibilities :
- GUI has chosen coins recently used : click cancel and send again, it may change the coins used. If not, you can wait or change the amount.
- GUI has chosen a lot of coins to make your payement : click cancel and send again, it may change the coins used. If not, you can wait or change the amount.

An option to use old coins in priority could avoid the last 2 problems.

[Mbtc]

I agree that the 0.01 BTC hardcoded numbers seem to be a serious problem and should be dealt with sooner rather than later. If bitcoin reaches the valuation that some people think it deserves then having transaction fees and/or minimum transaction sizes of 0.01 BTC will be completely infeasible. Just to make an illustration, imagine having transaction fees of $1... Bye bye micropayments.

[theymos]

The Eligius pool already accepts transactions with fees much lower than 0.01, though a small fee is required. So if you give a fee of 0.001, your transactions will be accepted eventually.

[Gavin Andresen]

An option to use old coins in priority could avoid the last 2 problems.

The built-in coin selection algorithm already prefers using older coins rather than newer ones.

[BitcoinBonus]

The Eligius pool already accepts transactions with fees much lower than 0.01, though a small fee is required. So if you give a fee of 0.001, your transactions will be accepted eventually.

Can you say more?  Is it possible to configure my bitcoind to use this pool for my outgoing transactions (I'm thinking not) ?  Or do I just have to get lucky and hope that this pool will find it ?   

I'm hopeful that a market economy with clear rules can be formed to regulate how transactions get accepted into blocks that allows for the minimization of the transaction fees.  I wonder what Satoshi would say.

[theymos]

Can you say more?  Is it possible to configure my bitcoind to use this pool for my outgoing transactions (I'm thinking not) ?

There is. Start Bitcoin with -addnode=173.242.112.53. Your transaction would eventually find the node even without that, though.