I didn’t claim that.
Our main weapon against spam (AKA DOS) was always days-destroyed. A concept that Core removed.
I also didn’t suggest that.
2 Likes
I think @tom has a great idea.
Free transactions for most people (you are paying “spam” fees with days destroyed), and fees for high-frequency transactions - that would be pretty freaking amazing! I think that’s also the case for many areas, where high-caliber users basically subsidize all other users (think advertisers paying to keep YouTube free or like a tax system, where high-income earners pay more and people barely scraping by don’t have to pay anything). I think cryptos like Nano, IOTA where users have to pay no fees have a huge selling point.
And again, days-destroyed are protecting us from spam. You can’t easily fake it. Or at least we could think of an algorithm (or recover Satoshi’s one if that was good enough) where you can’t flood the system because you’re spending a scarce resource (days destroyed)
3 Likes
WOW, I actually thought this code is still in.
Did Bitcoin Unlimited also remove it?
I am not sure about removing relay fees - this seems like a groundbreaking change so it needs more thinking, but I certainly think we should return Days Destroyed to the codebase immediately. It is a great spam discouragement mechanism, best of all probably.
There is just no logical reason why Days Destroyed shouldn’t be used as a spam discouragement mechanism again.
1 Like
^ Your remark above is what made it seem to me like you were suggesting to remove it from clients.
If it was a general remark, including a suggestion to remove it from Flowee, then I don’t understand why BCHN is being referenced here - other clients have this minrelaytxfee (or similar) feature too… e.g. BCHD.
A healthy network will in future require a large volume of transactions, paying many small fees. Transitioning gradually from block reward to this is the future that Satoshi proposed.
We do NOT want to drive away users or use cases that have a need for more frequent transaction. They would already pay proportionally to their use.
A system where they subsidize the majority of other users seems to me to
(a) be unstable in the long term (what happens when the subsidizing “rich” decide BCH is too expensive and go to some alternative?)
(b) shift the minrelaytxfee question to a “coinage days setting” (or even more complicated machine) configuration question
(c) unintended side effects on peoples’ spending behavior, possibly inhibiting natural growth of the system
Additionally, I think there is a lot of wishful thinking/armchair economics in the comments. Miners will NOT just include a bunch of MB’s of free transactions because of <insert complicated thought process>.
5 Likes
im_uname here raining on people’s parade again!
-
Dictating policy from one or many external oracles is a terrible idea. If we do that we can pretty much fold up any claims of being a permissionless currency and join the ranks of the EOS constitutional council or XRP. It’ll turn the whole thing into a joke. Seriously don’t do it, don’t even mention it. Internal policy of an independent cryptocurrency should never ever depend on reading from an external fiat.
-
Forcing the miners to float fees is less terrible, but still unequivocally bad. Once you got a jungle of desynchronized fee policies you can say goodbye to any claims to reasonable 0-conf reliability. Yes. I think having a reasonable 0-conf is orders of magnitude more important than crossing some arbitrary red line drawn around one US cent per typical transaction.
-
Free transactions are pointless. The problem isn’t that they encourage spam - we can arbitrarily limit their existence in any number of ways, coindays and hard size limit being two of them - but rather it cannot be deployed for any application that has any aspiration for reliability, at all.
If such a space strictly caters to unimportant applications that need no reliability, I’m not sure why we should care. If it aims to provide value to some useful application, these applications can and will fail-by-congestion at arbitrary times due to adverse conditions inside the “free space”, and that problem is unsolvable. Damage to BCH’s reputation as an unreliable chain will, in my opinion, be far worse than having each transaction pay two cents till the next upgrade. We’ll necessarily have to heavily discourage its use for anything useful, at which point I hope we’ll be self-aware enough to do some serious reflections.
There is one place where free txs are useful: In case you’re spammed by malicious miners with dust that can’t pay for its own movement, free space allows you to eventually consolidate them. But I doubt that’s a relevant problem these days.
Alright, enough pessimism. Looking at actually plausible solutions:
- Some form of algorithm that reads from aggregate fees of past n blocks. It’s easy to see how that’ll work in a congested chain - minimum inclusion fees are fairly useful as proxy to demand, due to users bidding against each other (otoh the UX, as we know, will be absolutely horrible). On a mostly non-congested chain like BCH I’m not sure how that can be done though - in “peacetime” we’ll have the overwhelming majority of tx be at the exact prevailing fee floor, so reading from that aggregate of fees doesn’t yield much useful information. We can’t have the floor constantly lower itself from prevailing fee, since that inevitably ends in a jungle of different policies as miners ditch the unreasonable adjustment algorithm. Again, 0-conf is far more important than crossing some arbitrary line denominated in a constantly devaluing fiat.
There’s probably some clever way to extract more useful information out of the past-transactions aggregate, but I don’t know what it is. If anyone has a new idea here I’m all ears.
- It’s a bit puzzling reading the heavy distrust towards miners here - we know they take initiatives on Ethereum to raise blocksizes, so having an adjustment mechanism that depends on miner/pool voting isn’t completely out of the question. In any case, better solutions on this front definitely exist, at least when compared to the very ugly process of lobbying node developers, which is happening right now.
Re:making minfee a consensus rule, that might not be a bad idea… but imo it’s limited in usefulness, since the only difference between that and strictly relay policy is that miners cannot arbitrary lower fees themselves to ruin coordination. Note that they may raise fees and there’s nothing anyone can do about that.
6 Likes
Here are my additional thoughts after reading this thread:
Agree/Reiterate: Do Not Add Fees to Consensus Rules
I agree with others that making fee levels a consensus rule is a bad idea. IMO, fee levels always need to be flexible. What fees really pay for are mining/node costs, and these costs vary in terms of BCH because BCH’s value changes over time. We should also not take away a miner’s ability to mine whatever valid transaction (exclusive of fee) they want to mine. Sure, a miner could “attack” the network by mining a ton of no-fee transactions, but that behavior is unsustainable in the long run and may even be fought off in the short run by other miners orphaning such blocks. I view Bitcoin mining as a cartel. We’ve already seen this in action with off-chain meetings of miners to make decisions and commitments regarding policies they will enforce. Unlike most real-world cartels, however, miners have a pretty slick enforcement mechanism: orphaning blocks. We do not need to try an centrally plan this behavior. It will emerge on its own as necessary since it’s in miners’ self-interest to police this on their own.
TL;DR: I feel like the consensus ruleset should be as minimal as possible (keep it simple, stupid). Transaction fee management does not, IMO, come anywhere near passing the high bar of necessitating consensus enforcement. In fact, I would view such attempts as harmful to the network.
Interesting, but Not Convinced: Different Fee Treatment Based on UTXO Consolidation/Coin Days Destroyed Behavior
I agree that there is value to the network in consolidating UTXOs. I can also see the argument for discouraging “high velocity” usage of the blockchain, though I don’t subscribe to that point of view. Due to the added complexity that these sorts of policies add to the code and the potential for abuse (e.g., spamming the network by creating and then consolidating massive numbers of otherwise un-economic UTXOs becomes possible, and perhaps even cheap for someone with a lot of BCH who can slowly cycle groups of coins to take advantage of both UTXO consolidation and CDD subsidies) I’m skeptical of the need for or wisdom of such policy.
TL;DR: My default position on these is to oppose the added code/system complexity since I don’t yet see the benefits clearly outweighing the risk.
Great User-Configurable Setting: mintxfeerelay
I am all for individual node operators being able to set their own minimum transaction fee relay. I understand that this potentially leads to problems with low-fee transactions not getting relayed and hurts zero-conf security, but I think the tradeoff is worth it and further believe that it should always be a user’s choice in how altruistic they wish to be when running a node. The ability for node operators to manually change this setting on their nodes could also help them and the network avoid a DoS attack scenario where an attacker starts spamming 0-fee, unconfirmed transactions (especially now that there’s no unconfirmed chained tx limit).
The zero-conf security issue is the biggest problem with relaying only transactions with a certain level of fees. However, I agree with freetrader that it is alleviated if not eliminated, by Double Spend Proofs.
TL;DR: I like user-configurable minimum transaction fee relay settings and think that DS Proofs eliminate the best argument for removing this from nodes/user configurability.
Clarification
I assume that when you say “forcing miners to float fees,” you’re referring to the idea of having miners set their own fee schedules and broadcasting them somehow (such as in blocks they mine), but I’m not sure. I don’t see how a jungle of desynchornized fee policies is any worse when it’s explicit (as in the suggestion to broadcast fee schedules) vs. implicit (as is already the case today). We already have mining pools which don’t mine any transactions, and there is absolutely nothing from stopping miners from setting their own minimum transaction fee policies right now. All I advocated for in my first post was creating an ability for miners to communicate policies which they either already have or will likely have in the future.
I also question the idea that there will ever be a “jungle” of desynchronized fees. As I said further up in my comment, I believe that miners will behave more and more like a cartel where it comes to block acceptance as transaction fees replace coin emissions as their primary source of revenue. Transaction fees are just a price like any other, and prices from disparate parties tend to converge even when they are not centrally planned.
3 Likes
I assume that when you say “forcing miners to float fees,” you’re referring to the idea of having miners set their own fee schedules and broadcasting them somehow (such as in blocks they mine), but I’m not sure.
No, I’m referring to the idea of setting default fees so low, the miners have to set their own minrelay fees independently. (Note: local minrelaytxfee is already a config item, has been for a while. Try it!) Miners mostly adhering to the same policy is a good thing, don’t force them into a strictly worse jungle-of-policies situation by taking away the sensible default.
3 Likes
Aha. In that case nevermind that area of my earlier comment. Anyway, I agree that default fee policy should probably reflect some reasonable effort at estimating the cost of a transaction likely to be processed within x blocks.
1 Like
Ah, the part you quoted was not an advice or suggestion. It was merely an item to earmark for further research. I understand your viewpoint now, good to know!
2 Likes
Interesting point of view. Its obvious that a lot of people would not mind stuff being free, so thats half of your argument gone. Your point that it would somehow not be reliable has been solved already in Thinking about TX propagation.
The concept of “Free transactions” is also missing the bigger picture I tried to explain. This is not just about fees, this is about the wider picture with several metrics. Transactions that have very very low priority need to pay fees. Transactions that have high priority may omit this, but can wait an extra block or two.
This is thus a false assumption, nobody was suggesting a system.
I invite you to look at my post above
where I explain the economics where miners are fully allowed to be greedy, without hurtning the system. No need to trust or distrust.
This statement is shown to be false. Imagine 1 restaurant asking twice the price of all the other ones. The only effect it will have is that they will not get any customers and thus get even less income. Even if 90% of the miners ask for higher fees, the only effect it will have is that people paying lower fees wait for more confirmations.
Your assertion is not supported by basic economics.
Yes. And more to the point, the fee/price should be left to the open market to allow discovery of the optimal. Centrally planned fees, costs, prices etc have been tried and they always cause massive issues. Free market, learn to trust it 
Interesting thoughts.
First of all, I don’t think that asking people to pay a minimal fee is equal to discouraging them from participation.
My design is that a mining policy prioritizes transactions for inclusion. And transactions that need to be in the same block as 100 of its parent transactions can get that guarenteed by paying a small fee. As the system grows and we reach 10k tx/sec then the amount of fee per transaction is going to be very low in order or for miner to still get a good income every 10 minutes. So don’t worry about this being anything like a high fee.
Like freetrader said; they are paying more because they use more block-space.
The abuse is a good point to take into account should a mining software implement this idea: the cost of doing 1 → 300 and then doing 300 → 1 should not end up costing the same as a 1->1. I’m not worried about this being too hard, finding some good curves to fine-tune this doesn’t seem a big problem and this is not a consensus part so iterate and test.
Notice that this would not be any complexity in the “system”. This would be a better algorithm that miners use to build a block. Even if a small number of miners use this, the benefit would be that the system as a whole becomes more responsive to economic incentives. None of the other components need more complexity.
1 Like
I’m not sure whether tom forgot to read most of my actual post before picking out of context quotes to straw-man against, or deliberately chose not to. But I’ll encourage other interested readers to go through my original post.
To be honest, I felt the same way when you simply dismissed my argument with rather strong but scary statements in your reply. To be fair, you started out with a disclaimer of you going against everyone.
To be constructive; your argument rests on the conclusion that free transactions are pointless, based on the assertion that they have no reliabilty.
This assertion makes no sense to me. Reliability is not impacted. Most likely you have not understood the proposal to expand priority to not only be about fees but also about other factors. How would a different way of having priority affect reliability?
I would also really like to ask you to be more constructive and cooperative. There is an proposal and it would be nice if you try to understand it and not just dismiss it like I’m a junior that has no clue. You are exhausing to work with. Please, questions instead of dismissive statements.
1 Like
A quick question to better understand it. Let’s say Alice’s node has 1sat/KB relay fee and Bob runs a BCHN node with default settings. Someone gives Alice a TX with 1 sat/KB and she relay it to Bob. Will Bob’s BCHN node accept it into its mempool?
Will Bob’s BCHN node accept it into its mempool?
No.
From the BCHN method that accepts a transaction into the mempool (or not):
// No transactions are allowed below minRelayTxFee except from
// disconnected blocks.
// Do not change this to use virtualsize without coordinating a network
// policy upgrade.
That second sentence should be taken generally imo, as "do not change the policy here without coordinating a network upgrade.
Thank you! But if somebody mines this 1sat/KB transaction, then the block will be accepted still, right?
Dammit, I can’t have an answer less than 20 characters.
My answer would have been just:
Yes.
Adding to the BCHN answer that they do not allow anything below relay fee.
This is not what the Satoshi client did for various years. This is behavior that was later changed.
In Flowee this still lives; libs/server/validation/TxValidation.cpp · master · Flowee / thehub · GitLab
Relevant upstream ⚙ D4745 remove priority free transactions mechanism (currently off by default)
The proposal I wrote above is essentially to go back to what Satoshi designed: priority transactions based not only on fee, but also on hard measurable things that can not be spoofed. It is my opinion that that would create a more stable system.
1 Like
While there may be some fancy more permanent way to handle min relay fee through an algorithm. I think the simplest approach would be the best. And we already use this simple approach when deciding on block size which is to just change the variable through coordination. Just lower the min relay fee variable. I suggest decreasing min fee from 1,000 sat per KB to 100 sat per KB. A factor of 10 decrease. And if I remember correctly lowering the min relay fee will also lower the dust limit by the same amount.
EDIT: To elaborate why I prefer a simple approach over a more algorithmic one is because the algorithmic suggestions here may take a longer time to discuss, research, and implement. A simple approach will be less risky and gather more support much quicker rather than a complex untested solution.
1 Like
Also I would like to add that SLP tokens are impacted by the min relay fee when it comes to the dust limit. Each time my application sends someone a SLP token it costs me the network fee + dust limit, which is 3x more expensive than a BCH transaction.
1 Like