ACK

Reflects what wallets do as well.

ACK.

This effectively also bumps max. "absurd" fee to 1 BTC. Do we really want it?

utACK.
You also need to take care of the isDust() test at https://github.com/bitcoin/bitcoin/blob/master/src/test/transaction_tests.cpp#L346.

@jonasschnelli Fixed, thanks

@paveljanik Good point; I agree that the absurd fee should stay the same. We probably should decouple those two constants, especially as in the future it's likely that the min fee will be floating anyway.

Absurd fee rate split off to its own value, and Qt fixed to actually use it(!).

Design decision: I did not add a CLI option to adjust this value independently due to the present string freeze. @wumpus, let me know if I should add this.

Did I miss a discussion of this somewhere? I'm not sure I understand what is wrong with the current 1000 satoshi feerate. Why does it need to be changed?

@morcos Indeed - There appears to be a large, unspoken component to this?

Reaction to stress test?

@jgarzik So, the math is that at 10uBTC/KB at current prices you need $2.5k/GB worth of BTC to flood mempools. That seems kinda low to me, especially when the supermajority of wallets aren't using rates that low.

Obviously a floating minfee and/or eviction would make more sense, but until that's implemented this is a decent and easily understood workaround.

@morcos @jgarzik This was never intended to be changed to 1000sat in the first place. I'm not sure what more to explain than what is in the OP/commitmessage?

I think I could be convinced this makes sense. But it definitely needs more public discussion. Some wallets will potentially send transactions that'll never be relayed now. Even before the min relay fee was reduced to 1000sat, transactions with small fees were effectively relayed anyway (they were subject to a rate limiter that hardly ever kicked in). But with changes to 0.10, low priority transactions now are not relayed at all if they don't meet the min relay fee.

It's also not clear to me that it makes sense to change the mining minimum. There isn't an issue as long as the mining minimum is below the relay minimum right?

@morcos This just restores the default to what was already the expected behaviour. I'm not sure what more there is to discuss in the scope of this PR? If someone wants a change to the expected defaults, that IMO belongs in a new PR focussed on changes (although I think the time discussing further changes is better spent convincing miners not to use defaults).

Can anyone spend a minute or so to find where exactly was the change of expected values? What PR?

@paveljanik As linked in OP, #3838; note the actual change of policy was not discussed, just the workaround for the bug being addressed at the time.

@luke-jr mikehearn@037b4f1 shows 10000...

Isn't it this change? gavinandresen@13fc83c

@paveljanik mikehearn/bitcoin@037b4f1 modified the mining code to use nMinRelayTxFee (1000) rather than nMinTxFee (10000).

@luke-jr how are you defining the expected behavior? Don't people expect the network to continue to behave the same way 0.9 and 0.10 nodes do? And i think even before 0.9, low priority low fee transactions would have still been relayed, so they would probably eventually be mined in the free section of blocks. This will be the first time that low priority transactions of feerate >1k sat have no chance of getting mined, I'd say thats a pretty big change in expected behavior.

@morcos I am defining the expected behaviour in this regard, as the last default value to receive discussion and agreement. #3838 was a temporary workaround to avoid delaying the 0.9 release, and was not meant as a permanent change to the default miner policy.

0.9 and 0.10 nodes will probably be around for a while, so if someone wishes to finally fix the relay/miner divergence issues, it should be possible to reduce the relay fee back to 0.01mBTC by 0.12. In any case, low priority transactions will still eventually become high priority transactions, get relayed, and then mined - so there's no major issue there that I can see.

expected behaviour in this regard, as the last default value to receive discussion and agreement

That's one way of looking at it, but people have been using a 1,000 fee rate for some time now (without any reason to believe that it was unintended), so from their point of view, this is a 10x fee raise, and calling it "just restoring the default", while perhaps technically correct, is a bit insensitive.

Off the top of my head, some services / wallets that make use of < 10,000 feerates:

• Breadwallet cc. @voisine (default feerate)
• Mycelium (non-default feerate)
• @blockcypher 's micro-transactions service

The most relevant details are:

1. What are the market prices experienced in the current market?
2. What is the behavior delta for those market participants?

It seems dishonest to describe an arbitrary price increase as "restore expected behavior", and it seems unprofessional to spring an unexpected price increase on the market without warning.

@jgarzik If a supermarket discovered its computer was only charging 10% of the expected price for items, would fixing that bug so the correct amount is charged be a price increase? The last time this default was discussed, it was decided on the amount restored here. The details you describe as relevant are for changes. I guess if we want to open a conversation about changing it, that's fine, but I thought the same factors leading to this default have remained the same. Looking at price graphs, I see I am wrong: price has risen 5x since 2013 Mar. So maybe instead of restoring the default here, we should change to 0.00002 BTC? Maybe not worth the time to discuss, at that small a difference, though. Either way, this probably is the wrong place for discussing a change, so I'm closing this.

@julian-smith-code I agree, but we're not arguing economic useful/uselessness here. In the current conditions such a transaction would never be included in a block, so hence raising the minimum relay fee so that it is rejected in the first place makes sense. The block chain isn't very suitable for very small transactions, and the threshold is determined by fee pressure.

@laanwj Android Wallet changed default fee to 0.0001.
schildbach/bitcoin-wallet@ba4f3fe

Besides making spam more expensive the minimum should be raised to prevent wallet bloating (e.g. voat and wikileaks). If you want to get ride of 543 satoshi transactions you can pay a max fee of 2715 per KB without making a loss (not counting time/performance loss). These are very unlikely to get confirmed any time soon. If we continue to hit the 1 MB cap, probably not before the block size fork. You are stuck with them for a while.

0.0001 minrelaytxfee works with Blockchain.info, Bitcoin Wallet Android, Circle App, Electrum, MultiBit, Copay and Breadwallet (if users chose max fee). Don't see why this shouldn't go into 0.11/0.12.

The mempool has about a 4x in memory overhead, so 250MB of txs takes up about 1GB. At 0.1mBTC/KB and $290/BTC you're looking at $7k worth of BTC to make many 32bit nodes crash; at the previous 0.01mBTC/KB this is a trivial $700, and $7k will be crashing even 64bit nodes.

Also, another way of looking at this is from the perspective of miners: 1MB * 0.01mBTC/KB = 0.01BTC, a truly insignificant 0.04% of the block reward.

I wish to make a brief comment here that this pull request will prove to be unnecessary. However, beyond that note, I wish to note the following:

@morcos noted that "Some wallets will potentially send transactions that'll never be relayed now. Even before the min relay fee was reduced to 1000sat, transactions with small fees were effectively relayed anyway (they were subject to a rate limiter that hardly ever kicked in). But with changes to 0.10, low priority transactions now are not relayed at all if they don't meet the min relay fee."

and

"we should modify miner.cpp to continue using a smaller minimum. This would make it hard to relay low fee transactions unless they are above the AllowFree priority threshold, and for those that got relayed, they'd stand a chance of being included in a block because of their fee (which would get them in a lot quicker than their priority).
I think this should give us the effect of preventing spamming, but still allowing economically valuable transactions for a low fee (although not very reliably unless you do some priority calculations)."

I'd like to hear @luke-jr and / or @laanwj's thoughts on that as it seemed that there is already a problem (correctly identified by @morcos) where already transactions aren't going to be relayed, and this pull request (as currently written) would have the effect of making it worse.

Furthermore, I think that there is an opportunity here to re-examine "dust / spam" and re-envision it as a "giving opportunity," or as "microgiving potential." Although @gavinandresen has stated (as @coinx-ltc pointed out earlier), "Bitcoin is not appropriate for transactions less than a penny or three.
If Moore's Law continues to hold, then one day it might be," it is my feeling that there are ways to re-evaluate the possibilities of microgiving in bitcoin.

Thanks for reading and considering these points.

• ABISprotocol
  http://abis.io

FWIW it looks like a significant amount of hashing power has already done this, F2Pool, AntPool, BTCChina, Eligius(?), etc.

@petertodd Simply because F2Pool, AntPool, BTCChina (and possibly others) may have done this (implemented restoration of minimum feerate as currently proposed), does not mean it is right, it only means they have made a bad situation worse. See my remarks above.

I am eager to see the replies from @luke-jr and @laanwj to my earlier points which emphasized some of @morcos's remarks, and I look forward to their thoughts on that.

Notes: See also my thoughts in #6402 and #1536.

ABISprotocol
http://abis.io

@ABISprotocol not sure which wallet still sends out 0.00001 fees besides Airbitz. See my list above.

If Moore's Law continues to hold, then one day it might be," it is my feeling that there are ways to re-evaluate the possibilities of microgiving in bitcoin.

I think the recent stress test and SPV mining showed that we are not there yet. The network is not yet able to handle all kind of transactions.

Simply because F2Pool, AntPool, BTCChina (and possibly others) may have done this (implemented restoration of minimum feerate as currently proposed), does not mean it is right, it only means they have made a bad situation worse. See my remarks above

Actually having a different policy on nodes than on miners makes the situation worse. See the recent double spend attacks and the slowly clearing mempool.

@Mirobit If you can't have end users of declining bitcoin nodes be able to set their own policy (note there is presently no one minimum relay fee) then I would see this as a problem. Further, bitcoin development presently is trending in a manner which is excluding an increasing number of people in the developing and underdeveloped world from ever being able to take part in it.

I will make the point here, as has been made elsewhere by @matthieu on July 8th, that "The minimum fee required to have your transactions included in the #bitcoin block chain has been multiplied by 24 in 2 days." However, this is not just an issue with getting one's transaction accepted, but it is also an unfortunate trend in bitcoin development that I have seen. (Recall #2577 from 2013 and the huge discussion that ensued on @gavinandresen's proposal to treat dust outputs as non-standard, un-hardcode TX_FEE constants ~ it created a lot of community anguish, made certain tiny transactions impossible, and here we are again.) Right now, I could very easily spend a dime anywhere in USD, but if I were to spend the equivalent in BTC, there is not a guarantee that it would be accepted as a transaction. This is already a problem and it is not because the minimum fee rate has not been restored (here) to 10000 satoshis. (For those who didn't participate in the discussion on #2577 in 2013 - 2014, I encourage you to view a comment of mine on the issue here.) Some of the discussion here makes me wonder if everyone forgot floating fees and the nature of that work.

In observing this sad trend of gradual fee increases and what I see as censorship of small transactions, in a year's time, given what happened in 2013 with #2577 and what is now happening with this issue here in 2015, it is entirely likely that further transaction and fee policies will be adopted which will edge out even those who are trying to make BTC transactions equivalent to 0.20 USD. Sharp currency declines (in the USD, euro, other currencies) and increases in value of BTC would create situations in which one might need to purchase small quantities of BTC, but paradoxically such policies as those proposed in this pull request might stymie entry-level buyers in the marketplace. In addition, the potential for microgiving in bitcoin is reduced by these kind of development proposals, and microgiving is one of the most significant developments to come to finance. It is one that cannot be adequately implemented by legacy systems in no small part due to their burdensome fees, which up to this point, bitcoin has not had. However, this appears to be changing rapidly.

As a consequence, a large number of people in the developing and underdeveloped world will be edged out by policies created by people who create and develop this new economic system without consideration of the voices of those who are least likely to be heard here. This implies that the billions who potentially could have been helped by this technology, now, will not.

Got mentioned so I guess I'll chime in. Just about the form, @luke-jr, a workaround that's over a year old isn't a workaround anymore. It stratified in.

I'm a little concerned but actually not overly worried about microtransactions. For the western world, there's still a lot of space above 5c. Only a minority of use cases will suffer from this (one could argue still important use cases but who knows).

I'm more concerned about the general price of transacting on the Bitcoin network. Look at us, we're a bunch of affluent white males discussing ad nauseam on a github pull request an issue that's likely to make your average Indian worker unable to use Bitcoin. And it's one of several issues that are pushing in that direction. Is that the "financial revolution" we want? Decentralization for who?

I'm also worried about miner greed (no offense @luke-jr, don't really have you in mind here). Bitcoin is pretty secure right now, as far as mining is concerned. Yet we spend significant time discussing how to micro-optimize miner profitability, rather than worry about inclusiveness and keeping network access cheap.

I realize this comment is pretty poor form on a pull request. But I believe it to be relevant, and a plea to consider other levers than expensive transactions.

@ABISprotocol The technology is fundamentally unable to support microtransactions directly on the blockchain.

The fact that miners have been reverting the minimum relay fees drop is solid evidence of this.

It's important to be specific in what you're talking about when you say microtransactions. In some contexts it means value transfers under "$10" in others, under "$1" in others under "$0.01" and in yet other under "$0.00001". There is some level under which just simply cannot be supported: because a single attack at moderate cost could saturate the bandwidth of a substantial portion of the network (keep in mind Bitcoin is a broadcast system, and any system that can't keep up can't participate).

Also keep in mind that the relay limit is not "the fee", it's a floor below which the fee is so low that it's only worth considering the transaction according to the free transaction rules.

@petertodd Incorrect, it has always been able to. However, development trends have been gradually been migrating away from supporting microtransactions, thus, as I pointed out earlier, inclining towards excluding billions of persons. That is something that should be handled differently from a development approach.

@gmaxwell Generally agreed, though an important point to add to this is that the definition of what an acceptable "microtransaction" might look like in bitcoin appears to be getting bigger and bigger due to changes in development - trending upwards over time, thus emphasizing the concern I mentioned. Here I am not speaking of value transfers of approximately or just under BTC amounts equivalent to today's USD 10.00, but rather, amounts which fall in the smaller figures area you mentioned. I also am making the assumption that no-fee dust transactions would have to be handled as off-chain transactions and would not be able to be handled on-chain, for the reasons I pointed out here. I am also assuming that on-chain dust could be viable on the chain if development methods would be inclusive of it, see for example Blockcypher's approach to microtransactions. I am aware of the Confidence Factor issues and how they have resolved them recently.

And in light of this trend I have identified, and in light of the fact that no-one has addressed @morcos's concerns which I quoted above in an earlier comment, and in light of the fact that bitcoin's use is growing (but with the incremental and gradual cost to transact in a way that shuts out much of the world, there is no question that this development trend in bitcoin could and should indeed change in the context of both short and long-term bitcoin-development strategy.

But if it does not, as @matthieu aptly stated, "Is that the "financial revolution" we want? Decentralization for who?"

My hope is that this will be for everyone, not just for some. I look forward to your thoughts and insights on how this can happen.

@ABISprotocol We are working towards genuine scaling of Bitcoin in multiple ways, for instance my own #6351, CLTV, pull-req to make payment channels more practical, and the Blockstream-sponsored work on the Lightning network, among many other things. But note how these efforts are to fundamentally change how you use Bitcoin - the blockchain protocol itself has poor scaling.

Anyway, as Luke-Jr has mentioned elsewhere, developers have no power over transaction fees; the min relay fee is simply a sane minimum that is set based on what miners are willing to mine. If miners are mining transactions with significantly higher fees than the minimum, then it only makes sense to increase that minimum. If we don't, we're just letting network bandwidth be pointlessly used up relaying transactions that won't get mined anyway.

Future work such as the various memory limited mempool proposals out there may eventually allow the fixed minimum relay fee to be removed, to be replaced by an automatically calculated limit, but for now, we should merge this pull-req. (and backport it for v0.11.1)

I honestly believe it's time to back up and think for a second the direction we're moving in. Moving ahead with this change (and many other changes that have already been phased in) we're essentially excluding a large part of the worlds population in participating in this decentralized project that was setup specifically to liberate and empower them. Essentially pushing them into hands (or rather mercy of) commercial companies (I'm looking at you Blockstream) to provide them with solutions that other commercial companies haven't been able to do for decades.

Do we really want to push through changes that will make offchain transactions a necessity rather than an opt-in-option? From my experience people always move to the cheapest and most trustworthy alternative, if the blockstream guys truly believe in their company and the solution it provides people will utilize your offchain solution because it's better, not because they HAVE to.

Besides that I believe we're all smart people and intelligent enough to realize that once this change get's phased in it will NEVER be reduced ever again, not even at 100k$/coin. Examples you ask? The blocksize limit was meant to be temporary as well. And even tough the majority of miners agreed with increased blocksizes of 8MB this hasn't been changed either. I think this raises the question move and more whose interest some devs are really defending here.

@petertodd , if some nodes are unable to handle the bandwidth or traffic that the network requires let them adjust their minrelay to be inline with their connections and computers capacity. And if miners do not/cannot mine certain transactions because of a limited blocksize then let them decide which ones rather than developers (see my previous points).

Given all this I'll make sure to screenshot/copy this comment seeing as previous constructive comments I've made on other pull requests have gotten censored (deleted) in favor of comments that are inline with the opposing parties.

@LeMiner Your comment contains several logical fallacies and irrelevant points. Furthermore, it doesn't contain a single technical argument and it's written in an very confrontational style.
The comment is certainly not constructive for this discussion and if you persist I wouldn't be surprised that this or later comments get "censored" again.
I think bitcointalk or reddit are probably better places for this type of comment.

@petertodd

In brief response to your last comment that "Future work such as the various memory limited mempool proposals out there may eventually allow the fixed minimum relay fee to be removed, to be replaced by an automatically calculated limit, but for now, we should merge this pull-req(...)" to me, this seems to contradict an earlier statement you made, in which you clearly commented that, and I quote,

"Obviously a floating minfee and/or eviction would make more sense(...)"

Indeed it would.

I also want to note the following as alternate suggestions. While I am personally supportive of solutions that work towards helping people realize on-chain, truly p2p transactions with the lowest possible cost, including microtransactions (as generally defined in my earlier comment), I don't want to ignore other points of view (even if they are not what I would prefer), and I'm including here in my remarks some alternative thoughts which were offered up by reddit user /u/eragmus/ ~ which I've quoted here as follows:

"In the long-term, Lightning will solve the problem in the ideal manner.

In the short-term (until Lightning arrives, which could take 1 or 2 years), we obviously still need a solution. As mentioned earlier, to protect the network against attacks, it would appear that off-chain is the only solution (since fees must rise some amount to make attacks more expensive) in the form of a service like ChangeTip. Bigger blocks would not solve the problem entirely (it might help a little), since making blocks too big at this point comes with its own tradeoffs. Increasing size to a reasonable 2-4MB would only increase the cost of an attack 2-4x, from ~$5,000 to $10,000 or 20,000."

While I do disagree that off-chain is the only solution (e.g. see BlockCypher's approach to microtransactions) I wanted to include more points of view to this discussion.

Finally I want to note that, as I have emphasized before indirectly, there are a large number of persons in the world getting by on the equivalent of 1 to 2 USD per day if salaried. At one time I lived abroad for several years for less than fifty USD per month. This is much of the world. These are statements of fact which cannot be ignored and which are as relevant to the discussion as subsidy, cost of mining, and other vital factors. The trend of upward cost of transacting in the bitcoin network is not going to reverse if the status quo continues, but developers do have a choice in how they proceed right now and moving forward. I do not recommend this pull request be approved.

Thank you for considering these remarks.

ABISprotocol
http://abis.io

We're not setting costs here, we're drawing conclusions on what will happen next based on costs vs income. Right now, the network generates 25 BTC per block, 6 blocks an hour, 24 hours a day, for a total of 3,600 BTC/day. At 3 transactions per second, or 259,200/day, that's a cost per transaction of 0.139BTC or thereabouts.

With fees set to 0.001 BTC, the network is subsidising each transaction to the tune of 0.138 BTC (better part of $3/transaction). That's okay now, but that subsidy is going to come down soon (and if it didn't, you'd be Dogecoin, and we've got a whole different set of economic challenges from being inflationary). If we increase block size to 10MB and pack that block full, we might get that down to 0.129. To get the two to meet, and totally ignoring mining infrastructure costs as a result, you would need 139MB blocks fully packed with transactions, causing the block chain to expand at 20GB per day.

Fixing this is not about poking at some minor changes with numbers, it's a research topic to find if there are any solutions. As I believe virtually everyone has told you, it's highly unlikely that there is a solution that involves pushing more transactions through a single stream.

We see the problem, we're telling you the only solutions we can see. We can't help that you don't like them.

@rnicoll As I think I noticed someone comment elsewhere, the development team focuses primarily on ensuring bitcoin works whereas research issues might be a different matter. You mentioned subsidies as did I. It's one piece of the puzzle. In this research paper, posted in June of 2014, titled "Near Zero Transaction Fees Cannot Last Forever," you can also see a brief discussion of various issues where the author examines fees and microtransactions. Kerem Kaşkaloğlu, the author, points out,

"In the long run, the policy on transaction fees
should be set so that enough many miners have
incentive to run clients having a good enough
combined hash power to protect the network.
But on the other side of the coin, the fees that
miners collect should not be any higher than
sufficient in order not to discourage users from
using Bitcoin as a means of transferring money."

Note that last point, and consider it in light of the billions of people that I was referring to earlier.

The author notes that creating a fixed transaction fee would make microtransactions under that amount too expensive to process, and goes on to suggest he will

"refrain from proposing a specific transaction fee setting
methodology whether a percentage of the
amount of BTC sent or a fixed fee plus a percentage"

Note: While the paper doesn't indicate what a micro-transaction is for the purposes of that paper's analysis, by way of reading it closely (see for example pg. 97), it seems that the author is referring mostly to amounts under 40 cents USD of value at that time in June of 2014. Obviously this should be even further concerning to anyone who is using bitcoin and wants to see its use spread on a global scale; it simply can't unless the development direction changes to include the billions in developing and underdeveloped world who live on 1 to 2 (USD equivalent) per day.

Another way to think of it is this: Let's say that this currency becomes even more adopted than it is today, which is likely to be the case, and gradually permeates much of world culture, in a manner similar to the introduction of the internet. Yet in order to participate, given upward fee trends and other issues contributing to costs to transact in bitcoin, very soon you would have to give up a day's salary to enter the system, or more (remember many people are being paid equivalent of 1-2 USD per day if that). To put that even further in perspective, imagine if you are paid 25,000 a year for a job in the USA, and thus a day's worth of your salary is about 100 USD. Imagine if someone suggested that you should spend that to buy into a new currency being introduced in your area, and further imagine that someone would tell you that fees from 80 to 100 USD would be expected per transaction. Now keep in mind the vast number of people making 1 to 2 USD per day. There is simply no motivation for entry into such a market in the developing world if the cost to transact is as high as high as what they get paid per day. As the cost to transact goes higher and higher based on this observable trend (due to all the factors mentioned in this thread), then people who are affected by these rising costs to transact will do one of three things with respect to bitcoin (and virtual currencies generally):

1. Ignore bitcoin (an unlikely possibility, but it is one that would occur),
2. adopt alts which are more inclined to allow people to perform microtransactions,
3. and/or use bitcoin increasingly off-chain, which is likely to come with its own set of problems for the network.

I see the problem, and I can't help that you don't like that I'm providing you with alternatives to the perspectives that you currently have. I have included relevant thoughts and considerations in my prior comments for review. Thank you for your consideration and for your time in reading these remarks.

Respectfully,

ABISprotocol
http://abis.io

Closed this again.

Mempool limiting and dynamic fee determination are superior to a static parameter change. I opened this as a temporary workaround for 0.11.0, but as 0.11.0 is already released (with simply an "important note" in the release notes regarding this parameter) we should aim for a proper solution in 0.11.1.