Comments (25)
Generating 110000 transactions with 1 input and 2 outputs currently costs less than 4.5 XMR ($315000).
Imagine that
With current price of 70000$, it's $2-$3
Or that.
Any "fees too low/fees too high" talk are basically price talks. Monero fees (compared to the total emission) are basically the same as Bitcoin fees now. No need to change them. We already changed them (5x) during the last hardfork.
from monero.
Please don't ignore what is most likely an attack on the Monero network. If you weren't paying attention to what happened on the Zcash network, let me remind you with this fun chart: https://blockchair.com/zcash/charts/blockchain-size.
Sure, a lot of us don't like Zcash for various reasons, but that's no reason not to learn from their experiences.
What was a slowly growing 37GB blockchain quickly became a 270GB blockchain. For them, this was significantly more painful than it will be for Monero, because as you know, their shielded transactions are difficult to verify, especially the large spammy ones that blanketed the network for approximately an entire year. Most mobile wallets simply ceased to synchronize. Of course this is not a problem for Monero due to the much more efficient verification process, so this is not what worries me.
What really concerns me is the casual attitude people have about low fees and the attack in general. I saw this same psychology enveloping the Zcash leadership and most of the users. Low fees were a part of their mantra, or culture as it were, so it was difficult to admit that the low fees might be causing a problem. It took them a long time to even acknowledge that it was probably unproductive and harmful to their project. Literally Zooko was saying that it could be something cool going on on the chain. Look at the usage! This could be organic! They were quite nonchalant even in the face of wallet failures. Meanwhile, the few users they had suffered. Even if you had a wallet that worked, sync times were excruciating.
The only thing that halted the attack was a change to their fee structure. Given the nature of the attack, which were large, multi-output shielded transactions, they started charging more for transactions that had lots of outputs. You might remember that their fee structure was originally just a minuscule fixed 0.00001 ZEC amount.
It looks like what Monero is seeing are a steady stream of 1 in - 2 out transactions at the lowest/slow fee rate. If you want to get in the next block, you pay up a little bit and use the next recommended fee tier. Very affordable still, but it does put you into a different puddle of fees. For practical purposes, users, exchanges, other services will all wise up and start paying a little more, or else they will suffer unpredictable wait times for confirmations. You almost don't need to be the spam creator to eventually benefit from reduction of decoys in this future scenario. Most low fee 1 in-2 out transactions will probably be discounted as useful decoys. I assume that the spammer is someone that will benefit from reducing decoys so they can sell a better performing chain-analytics solution for Monero, given their proprietary transaction data. Maybe they just sell that database.
So I advocate removal of the lowest/slow fee tier. I am not concerned with immediately raising overall fees, but raising the floor could be a reasonable first step. The recommendation from @nahuhh resonates well, but I can't speak to the practicality of it all since I am not familiar enough with the code related to fees. Overall, I advocate taking action, rather than sitting on our hands and hoping that it will simply go away. Yes, this is a useful period to find optimizations. I hope we take advantage of the flow to analyze and improve the project. Once the novelty wears off and we conclude that this is undesirable, I am pretty confident that the community will take action. Already this development has generated about 10x more discussion than ever hit the Zcash airwaves. Fees work! Don't underestimate them, and don't be afraid to pay a little more for the most useful private network on the planet.
from monero.
Interesting comments overall, @kgcrypto, but those "Look what happened to Zcash" arguments slowly go on my nerves.
Zcash had a fee system that was absolutely dumb, barely better than no fees at all. If my back-of-the envelope calculation is correct, back then with the old fee system a mere 10 USD paid the fees for several 10,000 of transactions. For the cost of spamming the Monero network a single day you could probably spam the Zcash network for freaking weeks. They were lucky it took so long somebody took the bait.
And what we have now? It seems dust settled at an average fee between 2 and 3 US cents. I don't know about you, but I find that quite expensive. I did not follow their history closely, but that looks a bit like they panicked to me and overshot.
I currently see the danger to do something similarly unwise much bigger than the whole community just sitting still and watching the show while the blockchain burns ...
from monero.
None of the transactions get dropped now, they all get mined. As I said before, I don't consider the lowest fee tier too low. The whole reason this topic exists is because Monero price is too low, and everyone gets it backwards. It should be possible to send transactions with the current lowest fee level.
But we can think of anti-spam measures. For example, nodes could stop relaying (and reject when sent via RPC) lowest fee transactions when mempool is full (more than the current median size). But nodes could still accept these low fee transactions when mempool is not full (less than 1 block backlog).
P.S. Or stop relaying when mempool is 1.5x the median size, and reject via RPC when it's 1.0x the median size to account for differences in mempool size on different nodes.
P.P.S Also wallets will then switch to the normal fee level (level 2) when it's 0.9x the median size, to avoid sending transactions that might be dropped later.
from monero.
What has happened in recent days on the network may have been intentional, however no action aimed at restricting the blockchain or limiting transaction amounts should be taken. On the contrary, I think that this is an opportunity to make the dynamic block size increase algorithm faster. No transactions can be marked as spam
from monero.
Also, are we entirely sure that the recent swath of transactions are "attack" transactions?
They all appear to be 1/2 transactions, which is definitely not real adoption. Now if it's an attack or something else isn't clear.
from monero.
If we consider it to be an attack. Maybe the operator is introducing 1/2 transactions in order for a remote mapper to identify which outputs are decoys without having to remember what transactions have been initiated by the operator.
Using the 1/2 transaction as Operator's transaction, I know it they're fake.
from monero.
A significant part of Monero's user base is on mobile devices. If Monero wants to remain a currency, it needs to be fast and simple for everyone.
increasing the blocksize faster is not a solution to improving wallet sync.
The Monero network is currently under a flood attack. Someone is generating ~110000 transactions a day - over 80% of the transactions are generated by the attacker.
the max throughput is ~150k tx/day @ 300kb blocks.
Generating 110000 transactions with 1 input and 2 outputs currently costs less than 4.5 XMR (643$).
A current monero transaction has a fee of 20µɱ per KB. This is ~30-40µɱ (0.00003-4ɱ) fee for a normal transaction. With current price of 143$, it's 0.0043-0.0057$.
With 2x base fee, reference transaction fee would be around ~0.01$.
so increasing the attack to $1200. Non-solution.
That's very acceptable for the average user, considering that the median Bitcoin transaction fee is currently 3.35$.
and if monero was 70k, the "normal" fee would be $11. The slow fee, $2.10
This small fee increase for users would greatly increase the cost of an attack, and reduce the cost of node operators.
the fee is a percentage of the circulating supply. You cannot just raise fees because USD doesn't agree with you. That leads to centralization - miners recouping the circ supply.
my suggestion is a more simple solution, but obviously has roadblocks.
- Kill slow fee (1). 0/2/3/4
- after a 10-100 block grace period, use similar full blocks/penalty zone logic that wallets use to elevate from "auto" from slow > normal, nodes should start requiring new tx relayed to be minimum fee = normal
- Nodes should release this requirement 10-100 blocks before wallets are told to drop their fee back down
something like how we change fees during a hardfork, with a grace period, but creating the period based on how full the last N blocks are. - the fee per byte should be via consensus. seems unfair if i can submit fees of 20020 piconero/byte, and slightly outbid everyone without it being noticable.. at least this is what it looks like is currently possible
tldr: FORCING spammers to elevate their fee and activate scaling quickly, cost them (4x more xmr (not easy to reacquire) * 10x every few days). From $1200 > 4800 > 48000/day if they spammed at 300k tx/day.
2x of a slow fee isn't a financial disincentive. Blocks grow quite fast and costly at "normal".
"Slow" should only be used when safe to do so.. when blocks aren't full. really, if natural volume was a 300kb, the way this attack would go is: theyd spam low fee, while we pay for the block increase, and they get their money back (including fees) if they can get their tx to expire, making for a sustainable attack.
only real solution is, imo, auto fees via relay rule.
Which isnt easy
With current price of 70000$, it's $2-$3
Or that.
Any "fees too low/fees too high" talk are basically price talks. Monero fees (compared to the total emission) are basically the same as Bitcoin fees now. No need to change them. We already changed them (5x) during the last hardfork.
+1
from monero.
@kgcrypto The key difference between ZCash spam and the current spam is that ZCash had a fixed (and very small) fee even for the very huge transactions. Monero has a different fee mechanism, so bigger transactions cost more, and the attacker spends ~3.7 XMR/day on this attack - much more than the ZCash attacker spent daily. In absolute terms the lowest fees are not small, they're the same (in coin terms) as Bitcoin fees (0.00003 XMR per tx vs 0.00003 BTC for low priority tx).
from monero.
Hey, let us watch what we see:
-In two days, transactions increased from 20,000 to around 120000 per day.
Result: The dynamic block size works perfectly!
-The transaction pool reaches up to 12000 transactions in places.
Result: All are processed and mined.
-Occasionally transactions are 12 hours old before they are processed.
In this case, there are adjustable fees to set the priority and thus the "waiting time".
Result: These work perfectly.
The only thing that remains is the supposed increase in block size, which has been increased from an average of around 0.1MB to an average of 0.3MB, which corresponds to a factor of 3x. I think the 3x factor is perfect. It is large enough to meet real requirements and small enough to prevent too rapid growth. What you have to pay attention to is:
The ratio of growth must keep up with the future price of hard disks, if this is the case, everything is fine.
You have to keep an eye on this, which I will calculate at some point.
If the aim was to inflate the blockchain, a factor of 3x is very little.
Increasing transaction fees would be a separate discussion, more of a political nature, to make mining more attractive. It certainly seems like a good solution now to make transactions more expensive, but then you would probably have to reduce them again after a few days or weeks when the transactions decrease again. So it's a back and forth.
I think a discussion for the transaction fees is always an important topic, but not because of the current number of transactions, it has to be done independently. Important topics for this are what is the user of Monero willing to pay for a transaction, mining attractiveness, hashrate etc. I think there is space up because Monero has a lot to offer. -> If the price increases, this discussion will be over again.
Hope I am close to the truth.
My sources:
https://bitinfocharts.com/comparison/monero-transactions.html#6m
https://bitinfocharts.com/comparison/size-xmr.html#6m
SG
from monero.
I don't think this is a good idea. 643*2=1286$ and I think the attacker is not worried by this amount of money to spend every day, otherwise the attack would have ended sooner. By using fees bump as our primary security against such flood attack, we're taking the risk that the attacker continue and we just ended up devaluing one of monero's principles
from monero.
This wouldn't require a hard fork, just a change to relay rules BTW. Also, are we entirely sure that the recent swath of transactions are "attack" transactions? There have been several large de-listings recently, and the market is generally pumping the last few days. A 7x increase in the number of transactions is big, but not unprecedented for usually busy holiday periods (for example).
from monero.
Isn't 1/2 transactions the most common form for normal wallet transfers?
from monero.
With current price of 70000$, it's $2-$3
If price reaches 70000$, then the number of Monero users will increase. As such, the fee in XMR will decrease. Fee in USD should not increase too much.
from monero.
minner?
from monero.
For me this attack is an excellent test. Monero is proving that it works. It's just a communication and synchronization issue between the nodes and the wallet
from monero.
For me this attack is an excellent test. Monero is proving that it works. It's just a communication and synchronization issue between the nodes and the wallet
It isn't just that. All these potential dummies transactions have polluted the output pool and will weaken ring signature effectiveness
from monero.
@SChernykh , @rbrunner7 I'm aware of the fee structure differences. I'm a little surprised that you think 2 or 3 cents is "expensive", and even more surprised you're not concerned about the sender privacy being impacted by this at little expense. 3.7 XMR a day for an actor like a chain-analytics company is not going to deter them.
I'm not suggesting we panic and do something rash. Go ahead and watch and learn. In the end I think removing the slow fee is a reasonable tweak.
from monero.
@SChernykh , @rbrunner7 I'm aware of the fee structure differences. I'm a little surprised that you think 2 or 3 cents is "expensive", and even more surprised you're not concerned about the sender privacy being impacted by this at little expense. 3.7 XMR a day for an actor like a chain-analytics company is not going to deter them.
I'm not suggesting we panic and do something rash. Go ahead and watch and learn. In the end I think removing the slow fee is a reasonable tweak.
I dont think rbrunner or sech 1 have said that the slow fee tier was necessary.
id like to hear their thoughts on consensus fee/byte (no custom fee/byte) and auto as minimum tier (0/2/3/4) fee lvls, dropping slow in favor of auto.
I dont see this as an increase in frees, but keeping things equal.
Spammers shouldnt be allowed to spam mempool / network with a low fee tx that get dropped / refunded due to real users tx fees being raised. This is essentially allowing a 0 cost attack to manipulate the dynamic block algo (forcing low real traffic to increase the block size)
from monero.
But we can think of anti-spam measures. For example, nodes could stop relaying (and reject when sent via RPC) lowest fee transactions when mempool is full (more than the current median size). But nodes could still accept these low fee transactions when mempool is not full (less than 1 block backlog)>.
It may also be useful to set a 10" timer for sending one transaction and another from the same wallet and same node.
for example. In the configuration file, of the monero node, a new option can be added to configure the anti-spam timer. a node manager can increase this timer in seconds with a minimum value of 10 seconds.
from monero.
What has happened in recent days on the network may have been intentional, however no action aimed at restricting the blockchain or limiting transaction amounts should be taken. On the contrary, I think that this is an opportunity to make the dynamic block size increase algorithm faster. No transactions can be marked as spam
from monero.
None of the transactions get dropped now, they all get mined.
now ;)
As I said before, I don't consider the lowest fee tier too low. The whole reason this topic exists is because Monero price is too low, and everyone gets it backwards. It should be possible to send transactions with the current lowest fee level.
agreed.
i dont want to force "normal" as min fee. I want to remove slow as a manually selected tier, opting for auto instead.
But we can think of anti-spam measures. For example, nodes could stop relaying (and reject when sent via RPC) lowest fee transactions when mempool is full (more than the current median size). But nodes could still accept these low fee transactions when mempool is not full (less than 1 block backlog).
P.S. Or stop relaying when mempool is 1.5x the median size, and reject via RPC when it's 1.0x the median size to account for differences in mempool size on different nodes.
P.P.S Also wallets will then switch to the normal fee level (level 2) when it's 0.9x the median size, to avoid sending transactions that might be dropped later.
wallet / client
If tx pool > 1x median OR
If 5 block avg > 90% median
- elevate if either are true
- revert if both are false
relay & rpc / server
If tx pool > 1.5x median
If 5 block avg > 100% median
- elevate if both are true
- revert if either are false
edit^
from monero.
Any "fees too low/fees too high" talk are basically price talks. Monero fees (compared to the total emission) are basically the same as Bitcoin fees now. No need to change them. We already changed them (5x) during the last hardfork.
In absolute terms the lowest fees are not small, they're the same (in coin terms) as Bitcoin fees (0.00003 XMR per tx vs 0.00003 BTC for low priority tx).
I always wondered how fixed fee levels could work. Looks like I got my answer: they don't (can't prevent spam).
As inconvenient as it is for users, only fees competition works; it is not about USD price nor about total XMR supply percentage.
I'm no expert but I suppose the mempool statistics history should be used to estimate fees / confirmation time.
P.S.: got here because my transaction is stuck since a couple of hours.
from monero.
@pedroapero I guess you didn't use the latest wallet version
https://github.com/monero-project/monero/releases/tag/v0.18.3.2
Wallet: adjust fee during backlog when set to default
Wallet: fix set priority getting ignored during transfers
from monero.
@SChernykh indeed I was using v0.18.3.1. I'll check for the new one, thanks for the hint!
from monero.
Related Issues (20)
- [Proposal] Change how transactions are broadcasted to significantly reduce P2P bandwidth usage HOT 33
- daemon can send duplicate transactions, causing disconnects
- blockchain always gets corrupt HOT 1
- [Discussion] Stress Testing monerod HOT 7
- Privacy Issue: Unneccesarry merging of coins makes users more traceable (broken change management) HOT 4
- Privacy: Transaction uniformity and receiving address type -- practical statistical de-anonymization HOT 1
- ERROR: chunk size exceeds buffer size while exporting monero database HOT 5
- Scan_tx stucks on newer versions HOT 6
- monerod started mining on its own HOT 30
- "Refresh" logic not resuming refresh from correct height causing excessive bandwidth / processing for nodes
- Compilation errors on gcc 14.1.1 HOT 10
- List of bugs in `export_transfers`
- Disucssion: FIRST_REFRESH_GRANULARITY set too high; causing excessive node bandwidth / processing
- Bug: start_height not being respected both in "refresh" RPC call and Wallet.cpp API.
- RPC Connection only over SSL, SSL - RPC, Check, HOT 3
- Error when running wallet in Gramine (Intel SGX) HOT 1
- Corrupted binaries built from Ubuntu 22.04 HOT 2
- Why can't the transaction be confirmed? This is on my private chain, mining is enabled, and gas is normal. HOT 6
- Why can't the transaction be confirmed? This is on my private chain, mining is enabled, and gas is normal.
- Trezor Safe 3 passphrase entry fails on host with long/special passphrases HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from monero.