Restore minimum feerate to 10000 satoshis

luke-jr commented at 2:52 am on May 30, 2015: member

Only the minimum relay fee was intended to be reduced to 1000 satoshis, but due to mempool bugs, nodes can’t handle divergent relay and mining fee rates properly yet. A quick workaround was merged for 0.9 by using the relay fee for mining (PR #3838), but without any consensus for the actual mining default to be dropped. Unfortunately, many miners seem to still run with default policies, and this fee rate makes spamming too cheap still. This brings the minimum fee rate back to up 10000 satoshis, which reflects the last consensus for standard mining fee rate.

petertodd commented at 11:52 am on May 30, 2015: contributor

ACK

Reflects what wallets do as well.

maaku commented at 6:14 pm on May 30, 2015: contributor

ACK.

paveljanik commented at 6:40 pm on May 30, 2015: contributor

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

jonasschnelli commented at 7:07 pm on May 30, 2015: contributor

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.

luke-jr force-pushed on May 30, 2015

luke-jr commented at 7:33 pm on May 30, 2015: member

@jonasschnelli Fixed, thanks

luke-jr force-pushed on May 30, 2015

petertodd commented at 6:22 am on May 31, 2015: contributor

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

Split absurd fee rate from minimum relay fee rate d0732d3688

luke-jr force-pushed on May 31, 2015

luke-jr commented at 6:46 am on May 31, 2015: member

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.

morcos commented at 1:29 pm on May 31, 2015: member

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?

jgarzik commented at 1:37 pm on May 31, 2015: contributor

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

Reaction to stress test?

petertodd commented at 4:10 pm on May 31, 2015: contributor

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

luke-jr commented at 4:27 pm on May 31, 2015: member

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

morcos commented at 6:11 pm on May 31, 2015: member

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?

luke-jr commented at 7:15 pm on May 31, 2015: member

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

paveljanik commented at 7:19 pm on May 31, 2015: contributor

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

luke-jr commented at 7:23 pm on May 31, 2015: member

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

paveljanik commented at 7:26 pm on May 31, 2015: contributor

@luke-jr https://github.com/mikehearn/bitcoin/commit/037b4f1485404a69f96ac6c448a97d21315c8663 shows 10000…

paveljanik commented at 7:31 pm on May 31, 2015: contributor

Isn’t it this change? https://github.com/gavinandresen/bitcoin-git/commit/13fc83c77bb9108c00dd7709ce17719edb763273

luke-jr commented at 7:43 pm on May 31, 2015: member

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

morcos commented at 7:43 pm on May 31, 2015: member

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

Restore minimum feerate to 10000 satoshis

Only the minimum relay fee was intended to be reduced to 1000 satoshis, but due to mempool bugs, nodes can't handle divergent relay and mining fee rates properly yet.
A quick workaround was merged for 0.9 by using the relay fee for mining (PR 3838), but without any consensus for the actual mining default to be dropped.
Unfortunately, many miners seem to still run with default policies, and this fee rate makes spamming too cheap still.
This brings the minimum fee rate back to up 10000 satoshis, which reflects the last consensus for standard mining fee rate.

ff1f171546

luke-jr force-pushed on May 31, 2015

luke-jr commented at 8:04 pm on May 31, 2015: member

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

bitcoinfees commented at 2:38 am on June 1, 2015: none

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

laanwj added the label TX fees and policy on Jun 1, 2015

jgarzik commented at 10:26 am on June 1, 2015: contributor

The most relevant details are:

What are the market prices experienced in the current market?
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.

luke-jr commented at 4:30 am on June 2, 2015: member

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

luke-jr closed this on Jun 2, 2015

laanwj reopened this on Jul 8, 2015

laanwj commented at 4:08 am on July 8, 2015: member

Reopening this, may have become relevant as a temporary workaround for the recent mempool flooding @gmaxwell.

gmaxwell commented at 4:12 am on July 8, 2015: contributor

I think it shouldn’t be off the table. I considered the prior reduction a mistake. Though it should be considered with some care. Eyeballing actual behavior even outside of the recent flood attacks looks to me like the actual competitive fees are higher than this already, but numbers should be more carefully crunched.

coinx-ltc commented at 11:09 am on July 8, 2015: none

ACK, to quote Gavin: “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.”

Currently bitcoin core allows 0.14 cent transactions. With the new minimum and a tenfold price increase it would be 0.14$. Witch is still accpetable and resonable. If people disagree we can easily lower the number if the price passes 1000$ again.

laanwj commented at 11:17 am on July 8, 2015: member

According to arhuaco on IRC, android wallet uses a fee of 0.00005. So going back to 0.0001 could exclude quite some legitimate transactions. Maybe 0.00005 is high enough though to stop the worst spam. As @gmaxwell says this does need some deliberation.

(in the meantime you can override it with e.g. -minrelaytxfee=0.00005 on your own node)

btcdrak commented at 11:36 am on July 8, 2015: contributor

@laanwj in all fairness rolling out updates to Android wallets is trivial and it might encourage wallet authors to add fee controls.

btcdrak commented at 11:37 am on July 8, 2015: contributor

I think we should also be giving some thought additionally to #1536

coinx-ltc commented at 11:38 am on July 8, 2015: none

@laanwj An alternative client implementation shouldn’t be the criteria for any decission about relay policy. A single dev shouldn’t have that power. Andreas can easily change the fee and most Android users update their apps quite regularly. @btcdrak Agreed, should be reconsindered. At least the faucet argument is out.

laanwj commented at 12:18 pm on July 8, 2015: member

An alternative client implementation shouldn’t be the criteria for any decission about relay policy. A single dev shouldn’t have that power

That’s not a very good argument - as one could say the same about bitcoin core’s devs. Then it’s up to the user to specify their own -minrelaytxfee they are comfortable with. The only requirement on the default is that it’s not broken or harmful. I’ve reopened this issue because there was some talk that this may be the case.

My own nodes are working fine, but were reporting ~50MB for the mempool size which indicates spamming is possible (and if there is no upper bound, that is bad). Using -minrelaytxfee=0.00005 brought this down to ~5MB.

Of course this would not be a permanent fix hence ’temporary workaround’. At least for 0.12 we should aim to have proper mempool limiting, discarding transactions based on relative criteria instead of hardcoded absolute limits.

morcos commented at 12:40 pm on July 8, 2015: member

I’m in favor of this change, but I think 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).

coinx-ltc commented at 1:00 pm on July 8, 2015: none

@laanwj Situation with the core dev’s is a little bit better since there are multiple and almost all changes are discussed. @morcos What is the point of unreliable transactions. Most users/services want certainty that their tx goes through (fee bumping hasn’t been included in a single wallet yet). Only a spammer would try to get his tx directly to the miner (maybe using the relay network).

jsmith-dev commented at 1:04 pm on July 8, 2015: none

I just want to say this transaction b5c44cc69b9f6b5c48933f16be58b54f6f09aa6d4f088882b3dbddde969f6df8 from my Airbitz wallet to a destination was ’economically useful’ and that the 1000 Satoshi fee was appropriate in this case. There are real-world small value transactions which are useful. At 10,000 Satoshi - my fee would have been like 25% of the transaction.

morcos commented at 1:45 pm on July 8, 2015: member

@coinx-ltc You could make it reliably relay by either using a feerate higher than the new higher minimum or taking the time to correctly estimate if your priority is above the AllowFree threshold. @julian-smith-code There is a tradeoff here. If we’re allowing (by policy) low value and low fee transactions to relay, then it is easy to spam. This PR would require the feerate to be 10x higher. I’m suggesting that the feerate only need to be higher for low priority transactions, as that should be just as effective in preventing spam but allow a few more use cases through for low fee transactions. That is what would happen by default with this PR, except those transactions though now relayed, would be prioritized for mining by their priority instead of their fee and would only be allowed in a priority section of a block if it exists. I’m suggesting to allow them in the fee section provided they still have some fee.

laanwj commented at 2:32 pm on July 8, 2015: member

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

Mirobit commented at 3:04 pm on July 10, 2015: contributor

@laanwj Android Wallet changed default fee to 0.0001. https://github.com/schildbach/bitcoin-wallet/commit/ba4f3fe8e57edcab831bfe0684c4babe52269b51

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.

petertodd commented at 1:45 pm on July 11, 2015: contributor

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.

petertodd commented at 1:50 pm on July 11, 2015: contributor

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.

ABISprotocol commented at 3:24 am on July 14, 2015: none

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

petertodd commented at 8:08 pm on July 15, 2015: contributor

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

ABISprotocol commented at 2:19 am on July 16, 2015: none

@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

Mirobit commented at 10:21 am on July 16, 2015: contributor

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

in src/init.cpp: in ff1f171546

802@@ -803,7 +803,10 @@ bool AppInit2(boost::thread_group& threadGroup, CScheduler& scheduler)
803     {
804         CAmount n = 0;
805         if (ParseMoney(mapArgs["-minrelaytxfee"], n) && n > 0)

jtimon commented at 6:20 pm on July 16, 2015:

Can you replace with if (ParseMoney(mapArgs["-minrelaytxfee"], n) && MoneyRange(n)) while you’re at it?

ABISprotocol commented at 10:12 pm on July 16, 2015: none

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

matthieu commented at 0:44 am on July 17, 2015: none

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.

petertodd commented at 1:21 am on July 17, 2015: contributor

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

gmaxwell commented at 1:28 am on July 17, 2015: contributor

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.

ABISprotocol commented at 2:05 am on July 17, 2015: none

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

petertodd commented at 5:29 am on July 17, 2015: contributor

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

LeMiner commented at 7:09 am on July 17, 2015: none

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.

jtimon commented at 8:21 am on July 17, 2015: contributor

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

ABISprotocol commented at 9:52 pm on July 17, 2015: none

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

0"In the long-term, Lightning will solve the problem in the ideal manner.
1
2In 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

rnicoll commented at 10:09 pm on July 17, 2015: contributor

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.

ABISprotocol commented at 10:47 pm on July 17, 2015: none

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

Ignore bitcoin (an unlikely possibility, but it is one that would occur),
adopt alts which are more inclined to allow people to perform microtransactions,
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

laanwj closed this on Jul 18, 2015

laanwj commented at 8:20 am on July 18, 2015: member

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.

DrahtBot locked this on Sep 8, 2021

Restore minimum feerate to 10000 satoshis #6201