Considering a fee increase for the next hard fork #9240
Comments
|
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 |
Imagine that
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. |
|
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). |
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. |
|
Isn't 1/2 transactions the most common form for normal wallet transfers? |
|
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. |
increasing the blocksize faster is not a solution to improving wallet sync.
the max throughput is ~150k tx/day @ 300kb blocks.
so increasing the attack to $1200. Non-solution.
and if monero was 70k, the "normal" fee would be $11. The slow fee, $2.10
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.
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". Which isnt easy
+1 |
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. |
|
minner? |
|
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 |
|
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. |
|
@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). |
|
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 ... |
|
@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. 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) |
|
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. |
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. |
|
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 |
1 similar comment
|
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 |
now ;)
agreed.
wallet / clientIf tx pool > 1x median OR
relay & rpc / serverIf tx pool > 1.5x median
edit^ |
I always wondered how fixed fee levels could work. Looks like I got my answer: they don't (can't prevent spam). 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. |
|
@pedroapero I guess you didn't use the latest wallet version
|
|
@SChernykh indeed I was using v0.18.3.1. I'll check for the new one, thanks for the hint! |
|
Hey, let us watch what we see: -The transaction pool reaches up to 12000 transactions in places. -Occasionally transactions are 12 hours old before they are processed. 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: 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. My sources: SG |
A significant part of Monero's user base is on mobile devices. If Monero wants to remain a currency, wallet synchronization must remain fast for everyone.
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.
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$. That's very acceptable for the average user, considering that the median Bitcoin transaction fee is currently 3.35$. This small fee increase for users would greatly increase the cost of an attack, and reduce the cost of node operators.
The text was updated successfully, but these errors were encountered: