Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Make MIN_TX_FEE match MIN_RELAY_TX_FEE. #2403

Merged
merged 1 commit into from Apr 8, 2013

Conversation

Projects
None yet
8 participants
Member

gmaxwell commented Mar 23, 2013

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

@gmaxwell gmaxwell 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.
e380082
Member

gmaxwell commented Mar 23, 2013

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.

Contributor

gavinandresen commented Mar 23, 2013

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."

Member

petertodd commented Mar 23, 2013

ACK

This will make my timestamper a lot cheaper to run.

qubez commented Mar 24, 2013

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.

Member

gmaxwell commented Mar 24, 2013

@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 Mar 24, 2013

"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.

Member

gmaxwell commented Mar 24, 2013

@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)

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

Member

petertodd commented Mar 25, 2013

@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?

Contributor

gavinandresen commented Mar 25, 2013

The relevant CreateNewBlock code is:

// Fee-per-kilobyte amount considered the same as "free"
// Be careful setting this: if you set it to zero then
// a transaction spammer can cheaply fill blocks using
// 1-satoshi-fee transactions. It should be set above the real
// cost to you of processing a transaction.
int64 nMinTxFee = MIN_TX_FEE;
if (mapArgs.count("-mintxfee"))
    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.

Member

gmaxwell commented Mar 25, 2013

::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 Mar 25, 2013

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

Member

petertodd commented Mar 25, 2013

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?

Contributor

rebroad commented Apr 2, 2013

Where does the $1875 come from?

Owner

sipa commented Apr 6, 2013

@rebroad 25 BTC subsidy * exchange rate

Owner

sipa commented Apr 7, 2013

ACK

Contributor

jgarzik commented Apr 8, 2013

ACK

@sipa sipa added a commit that referenced this pull request Apr 8, 2013

@sipa sipa Merge pull request #2403 from gmaxwell/minfee-to-relayfee
Make MIN_TX_FEE match MIN_RELAY_TX_FEE.
1828133

@sipa sipa merged commit 1828133 into bitcoin:master Apr 8, 2013

qubez commented Apr 9, 2013

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

Member

gmaxwell commented Apr 9, 2013

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 laudney pushed a commit to reddcoin-project/reddcoin that referenced this pull request Mar 19, 2014

@sipa sipa Merge pull request #2403 from gmaxwell/minfee-to-relayfee
Make MIN_TX_FEE match MIN_RELAY_TX_FEE.
87ca3cc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment