Make MIN_TX_FEE match MIN_RELAY_TX

gmaxwell commented at 0:49 am on March 23, 2013: contributor

Current relay behavior is widely deployed. Supplying a higher minfee than mining and relaying just irritates users without anti-spam gain.

Make MIN_TX_FEE match MIN_RELAY_TX_FEE.

Current relay behavior is widely deployed. Supplying a higher minfee than
mining and relaying just irritates users without anti-spam gain.

e3800824d6

gmaxwell commented at 0:51 am on March 23, 2013: contributor

I’d thought about doing recently— but concluded that since there was a lot of transaction pressure that lowering a fee wouldn’t help users. But I checked and at the moment the mean and median blocksizes are around 130k and there are a lot of free transactions.

gavinandresen commented at 1:09 am on March 23, 2013: contributor

ACK.

At current price of $70/BTC, that’s $0.007 per kilobyte, which is reasonable. If the price crashes before next release, we should re-visit this.

I really want to get rid of hard-coded fees soon, though. The memory pool should be size-limited to a small multiple of the recent median block size, the include-in-mempool rules should be the same rules as the include-in-a-block rules, and the relay rule should be “only relay it if it makes it into the memory pool.”

petertodd commented at 5:54 am on March 23, 2013: contributor

ACK

This will make my timestamper a lot cheaper to run.

qubez commented at 0:27 am on March 24, 2013: none

A better patch if you aren’t going to call the pull request “Change minimum fees to 0.0001 BTC”: +static const int64 MIN_RELAY_TX_FEE = 50000;

Disclosure of S.DICE interests by a certain MH and other bloat lobbyists would allow detection of individual profit motive before any further implementation of a tragedy of the commons. @gavinandresen Spam rules should not be “6MB of spam an hour allowed at any price.

A user interface recommending an elevated fee based on network activity (and setting the minimum fee to apply to all transactions) would be prudent before further mucking with fees, relay rules, block sizes.

gmaxwell commented at 1:03 am on March 24, 2013: contributor

@qubez While I share your concerns, you may note that the current most conspicuous bloat sources are paying more than 0.0005 BTC in any case. What you’re asking for would just upset people who do not understand these concerns and would not differentiate traffic.

I also agree with the UI recommendation path, but it appears that at this time changing the behavior here should be harmless— e.g. doesn’t make anything worse. It’s a one byte change.

qubez commented at 1:19 am on March 24, 2013: none

“It’s a one byte change.”

It’s just an 80% fee discount on a company that uses 80% of the blockchain. Don’t expect that people won’t change to the minimum when MIN_TX_FEE is what Bitcoin includes by default.

To clarify, if everyone else is paying 0.0001, then why bother paying more; 0.0001/KB fees will get your transactions in. This patch IS effectively reducing the minimum fee, with no justification of why this is a good idea.

I was going to support these assertions by demonstrating how fast fees dropped after 0.3.24 and block ~140000, but hardly any transactions were paying fees anyway due to priority > 57M being commonplace - people weren’t sending new inputs to a gambling site dozens of times an hour.

gmaxwell commented at 1:29 am on March 24, 2013: contributor

@qubez What the network imposes is min relay fee, which is unchanged here. The users you are concerned about do not run bitcoind, and do not care what MIN_TX_FEE is because it’s not imposed on the network. (and, as I mentioned, they are already paying more than MIN_TX_FEE in any case, because their software is stupid and can’t cope with fee/kb and forces them to pay a static fee large enough for the largest txn they would create)

BitcoinPullTester commented at 4:28 am on March 25, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/e3800824d6bf7b157a6211cb7eb01ab19a8f5ac0 for binaries and test log.

petertodd commented at 4:05 pm on March 25, 2013: contributor

@gmaxwell @qubez re: S,DICE while it’s true that they are using software that can’t calculate per-kb fees properly, remember that they were initially paying a 0.5mBTC fee on every transaction and later upped it to 1mBTC. To me that says they’re paying the fees they do to have a competitive bid for limited block space more than anything else, and are just being a bit lazy on the per-kb aspect of it.

That said, there is a short-term problem with changing MIN_TX_FEE, which is that it’s used in GetMinFee(), called by CreateNewBlock(), to determine eligibility for tx inclusion in a new block. How much hashing power will accept these new fees right now?

gavinandresen commented at 4:42 pm on March 25, 2013: contributor

The relevant CreateNewBlock code is:

0// Fee-per-kilobyte amount considered the same as "free"
1// Be careful setting this: if you set it to zero then
2// a transaction spammer can cheaply fill blocks using
3// 1-satoshi-fee transactions. It should be set above the real
4// cost to you of processing a transaction.
5int64 nMinTxFee = MIN_TX_FEE;
6if (mapArgs.count("-mintxfee"))
7    ParseMoney(mapArgs["-mintxfee"], nMinTxFee);

… so asking some of the big pools if they will run with -mintxfee=0.0001 before pulling this is a good idea.

gmaxwell commented at 5:02 pm on March 25, 2013: contributor

::sigh:: For some reason I thought changing mining criteria to be MIN_TX_FEE instead of min_relay_fee got NAKed.

I suspect that there is a some amount of mining happening with the lower setting, since there are many transactions meeting that criteria, but it’s hard to tell. If so, that makes this pull much less of an obvious win.

qubez commented at 5:06 pm on March 25, 2013: none

I just sent out 0.0005 -> 0.0004 + 0.0001 fee at 17:00 UTC to five nodes, we’ll see how many blocks this doesn’t make it into as anecdotal evidence of the default user experience expected from this pull: f996fc4ec5bc8ae92d15ce18530f827095b370bd3bbc4a4ff1a885f52fbad64c - transmitted with 1216 and 1MB of other unconfirmed transactions pending.

The answer: 15 blocks - 227995 by BTCGuild

petertodd commented at 5:16 pm on March 25, 2013: contributor

If anything it basically says the pull itself isn’t what’s required, it’s talking to the pools. I’ve already told bithits and similar people if they want they’re low-value transactions mined, the network will relay them, so ask a pool to change their defaults and accept their transactions.

Look at it this way: if a miner fills a block to the 1MB limit with 0.1mBTC/KB transactions, that nets them just 0.1BTC of fees. Why risk orphaning your $1875 subsidy for the sake of $7.5? For that matter, why waste a bunch of expensive skilled labor doing the analysis to determine if that’s a good trade-off?

rebroad commented at 1:15 am on April 2, 2013: contributor

Where does the $1875 come from?

sipa commented at 2:41 am on April 6, 2013: member

@rebroad 25 BTC subsidy * exchange rate

sipa commented at 6:32 pm on April 7, 2013: member

ACK

jgarzik commented at 5:07 am on April 8, 2013: contributor

ACK

sipa referenced this in commit 1828133c62 on Apr 8, 2013

sipa merged this on Apr 8, 2013

sipa closed this on Apr 8, 2013

qubez commented at 10:51 am on April 9, 2013: none

This has been ack ack’d and merged, but I think it needs one more thing - the default voluntary fee, if no command line, config, or options dialog has been set, should be set to 0.0005. This restores today’s operation as default, while allowing reduction for those who will understand the effect of sending with a lower fee. This will also fix a problem that has been posted on the forum, allowfree transactions are now taking hours due to limited free transaction space and block competition; a fee is no longer dust spam discouragement, it’s a near-requirement for block inclusion.

main.cpp: // Settings -int64 nTransactionFee = 0; +int64 nTransactionFee = 50000;

However, the send dialog does not indicate the voluntary fee, it should before mucking with things. It looks like the easiest would be another argument in sendcoinsdialog.cpp to show transaction fee too (but I’m no coder to be able to find where to get the Per KB transaction fee; it looks like it’s not calculated yet at this point):

transfeesimple

gmaxwell commented at 2:22 pm on April 9, 2013: contributor

the default voluntary fee, if no command line, config, or options dialog has been set, should be set to 0.0005. This restores today’s operation as default,

That is most definitely not the behavior prior to this patch.

laudney referenced this in commit 87ca3cc405 on Mar 19, 2014

DrahtBot locked this on Sep 8, 2021

Make MIN_TX_FEE match MIN_RELAY_TX_FEE. #2403