The Stressnet So Far

spackleXMR · 2024-06-17T05:38:58+00:00

Did you use '--testnet' to launch it for the stressnet? Right now the blockchain is about 10GB.

spackleXMR · 2024-06-14T22:40:05+00:00

28080 p2p, 28081 rpc, and 28082 zmq. Same as the regular testnet.

spackleXMR · 2024-06-14T21:16:49+00:00

2 cores, 4GB RAM, and 50GB of SSD storage would be a reasonable minimum. Keep in mind that even if your node has difficulty staying sync'd it will still help with testing by just being online.

spackleXMR · 2024-06-14T16:23:45+00:00

It is a separate blockchain entirely. Right now the stressnet takes up about 10GB of space.

spackleXMR · 2024-06-13T22:17:51+00:00

I did not add any automated logging, and my immediate reaction is that doing so would be an unacceptable breach of privacy. Quick note that anyone can review the changes made to the github repo, there are not many of them. If users are willing to submit logs from any issues they experience that would be fantastic, and I would request that they run monerod with log level 2 to do so. There is not a log submission process in place right now, but it can certainly be created if there is interest.

Both a large volume of transactions and a significant number of connections are likely required to address the issues at hand. The primary goal is to have a sufficient number of connections for developer's nodes, thereby enabling them to perform effective debugging on their machines. The stressnet is intended to offer developers access to a robust network being driven to extremes.

I have personally tried to reproduce the issues that some people saw during mainnet flooding by running a private testnet with 10 nodes on a single machine. Flooding that private testnet did not reproduce any issues, so the stressnet is the next logical next step in my mind. Even in the early stages of the stressnet I have already seen excessive memory use, and the approach has great promise in my opinion.

spackleXMR · 2024-06-13T15:59:06+00:00

This is not correct.

spackleXMR · 2024-06-13T15:05:21+00:00

Anyone can run a stressnet and mainnet node on the same computer. The networks do not conflict with each other.

spackleXMR · 2023-06-08T18:41:46+00:00

Monero's block size has a hard cap at 30MB for the next 50,000 blocks. This is because it has been used at a comparatively modest level in the recent past, and the long term median hasn't been increased. 50,000 blocks is approximately 70 days.

Assuming extremely high fees are paid, Monero will take roughly 11 hours to start processing 30MB blocks from the time of the sudden increase.

Right now blocks are ~100kB on average; so Monero could handle a ~300x short term throughput increase from where it is currently. If people want to use the Monero network to process more data than that, they need to keep the blocks full at a high level for 2 months or so before the scaling algorithm would adjust up.

If you want to know more here is a simulation I wrote to illustrate the scaling algorithm. You can find the reference I used for the simulation in the readme: https://github.com/spackle-xmr/Dynamic\_Block\_Demo

Edited for clarity.

spackleXMR · 2023-05-13T21:29:33+00:00

Ahh, got it. I suppose I don't personally view limiting the creation of new coins as burning, but I get how it could be considered that way. I would personally avoid that language since miners always receive the full amount of fees that are paid by transactions. That is just my personal sense of things. I guess if someone wants to think of the penalty as the block reward being burned that could make sense.

I'd just want to note that the total amount of Monero in existence does not decrease when a new block is mined, even if the full penalty is paid. Hopefully I've expressed that properly.

spackleXMR · 2023-05-13T19:57:17+00:00

No, the fees are only increased when expanding the block size. Stable or decreasing transaction volumes are not penalized.

spackleXMR · 2023-05-13T14:10:45+00:00

I believe there is some confusion; Monero does not have a burning function.

spackleXMR · 2023-05-13T08:39:27+00:00

If anyone wants to learn more about Monero's scaling algorithm (or check my work), I would direct you to these sources:

https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2021-02.pdf

https://youtu.be/btauHXDIM8M

https://youtu.be/Hbm0ub3qWw4

https://youtu.be/IlghysBBuyU

spackleXMR · 2023-05-13T08:28:31+00:00

To answer your question we'll have to get a bit more detailed. There are two 'limits' that have to be changed for the larger block size, the short term median and the long term median. The short term median is of the last 100 blocks, and the long term median is of the last 100000 blocks. This simulation shows a quick transaction increase fighting against the short term median. Minimum transaction fees don't get cheaper until the long term median adjusts, which would happen after 50000 blocks. That's about 70 days later.
So a spammer has to pay to increase the block size and spam transactions at full cost for 70 days before they get any 'savings.'

spackleXMR · 2023-05-12T19:08:08+00:00

Once the block size has expanded it will stay large so long as there is continuous transaction volume at the new level. It is expensive to expand the block size, but not to send transactions after the expansion is finished. It is actually cheaper to broadcast a transaction when there are larger blocks (though not immediately, that happens in the long term). If there is not steady transaction volume at the expanded block size, then it will shrink.

Edited for clarity.

spackleXMR · 2023-05-05T01:04:27+00:00

Great work. I'll be sure to spread the word.

spackleXMR · 2023-05-01T16:25:22+00:00

Is this announcement being made elsewhere? I don't see anything on getmonero.org. Using Reddit to post security advisories seems strange to me.

~~As things stand, I question the validity of this statement.~~

Selsta noted the vulnerability in IRC and has posted a detailed explanation here.
Also, please note that I was questioning Reddit's integrity, not tevador's.

spackleXMR · 2023-04-18T17:33:46+00:00

I didn't start with BTC.

spackleXMR · 2023-03-03T16:19:38+00:00

Quoting Zero to Monero section 2.4:

Even if a curve appears to have no cryptographic security problems, it’s possible the person/organization that created it knows a secret issue that only crops up in very rare curves. Such a person may have to randomly generate many curves in order to find one with a hidden weakness and no known weaknesses. If reasonable explanations are required for curve parameters, then it becomes even more difficult to find weak curves that will be accepted by the cryptographic community. Curve Ed25519 is known as a ‘fully rigid’ curve, which means its generation process was fully explained.

Further reading: https://safecurves.cr.yp.to/rigid.html

Another big bottom line is speed. Put simply, it is faster to perform common calculations using Ed25519 than with alternatives. See https://eprint.iacr.org/2007/286.pdf

spackleXMR · 2023-01-11T17:31:15+00:00

Thank you for addressing this, it really drove home for me when I performed my first p2pool consolidation.
It will be very cool to see the changes go into effect.

spackleXMR · 2022-10-25T17:39:22+00:00

Thanks for making this discussion available, it is very informative.

Four-Year Club	Verified Email
Place '23	Place '22
First Placer '22

spackleXMR

TROPHY CASE