New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mining] [ProgPow] Reduce DAG size #1014
Conversation
Line 761 in 249cee7
|
You're right, forgot to commit that file. |
additionally, there are 3 separate declarations of (and all different values) for My mistake, they are for dev and test nets. Disregard |
That is for the different networks main, test, dev |
3226c9c
to
e9d4f40
Compare
nitpick: I'll also suggest not changing a constant's value. Instead of assigning the current value to be deprecated as a same named variable with "_OLD" at the end and updating the existing to the new value -> I suggest creating a new constant value and reference that one going forward (and leave the existing constant and its value as is). In my opinion, this will make it easier to catch issues from existing code that may still be referencing that constant value and are operating under the assumption to be unchanged (or therefore needing change). It is a constant after all. Up to you. Just a suggestion :) |
For mainnet I'd recommend a start height of 2000000, as that's the same fork height as the next mandatory release. |
Excellent idea! There will be multiple combined reasons for people to upgrade! |
c784beb
to
2bd1611
Compare
Just applied @Rock-N-Troll's suggestion, and set the mainnet transition height to 2000000. |
Yesterday I tested this on a new devnet. As far as I can see, the wallet part worked and at the configured block height the epoch was reset to 0. Sadly, mining software continued at epoch 193. The problem seems to be that mining software has hardcoded the epoch derivation from the block height. Thus, for mining software to work with this, they would have to either hardcode the change, or to add a new parameter to the |
Or we would have to compile a new version of their software, which they can merge once everything is known to work. |
But none of the mining software is open source, so how do you want to do that? |
Ah, well then we'll have to coordinate with them, then. 🙏 |
This is a bad idea, allowing GPU's that were ROI'd 4 years ago, to mine again will crush the price. |
Here is a spreadsheet you can use to calculate the Veil DAG size. |
I feel as if you are thinking in the wrong way. Just because something is roied, and we would be allowing older cards doesn't mean the price will get crushed. It's already crushed if you haven't looked at the markets lately. Either way I can even give examples. Both ravencoin and ergo have had dag sizes under 4GB for years now, is their price crushed? No it's not, actually if you read into their communities and the general mining community overall a lot of people have switched their rigs to both ergo or raven (Even cards that could mine on eth). There is boat loads of support for them specifically because they allow a bigger pool of miners and focus on the mining community which holds their coins together. Time and time again it seems the veil devs don't seem to understand that trying the same things over and over again, then expecting different results isn't going to work. Back to the point of "the price will tank", actually it won't. It's pretty simple. The less efficient cards will hop off the network when it isn't profitable (which right now I'm only making 4$ a day on 330MH on veil with the latest cards). Alongside there are new cards being released in 2022 that still have a 4GB dag. What are those that have those cards supposed to mine? We can be the coin people come to when they are kicked off the other networks for having too little vram. Our community will explode. Look at what happened with eth classic. They had a bunch of 51% attacks, and decided to reallow 4GB cards, boosting their price, community, and security. |
I just opened some issues for WildRig (andru-kun/wildrig-multi#144) and T-Rex (trexminer/T-Rex#1371), in order to agree on the required mining software changes. |
WildRig is already working with the new DAG size in the devnet. Thanks to @andru-kun for the fast implementation. Now let's see if we get @trexminer working too! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 2bd1611
We need to coordinate with mining pool and the mining community before 'releasing' this, and committing to the master branch also commits to including it whenever any other upgrade demands a new release. |
Sadly, no news from @trexminer yet. This PR shouldn't be merged until we got T-Rex miner working, because we might need some little other changes to the |
What about TT-miner? |
I thought TT-miner is not maintained anymore (maybe you know more?), so that mining software would not support VEIL anymore after the DAG size reduction 🤔. |
I believe TT-Miner is on this thread: https://bitcointalk.org/index.php?topic=5025783.1220 |
2bd1611
to
490ff68
Compare
TT-Miner developer contacted us over discord, and is now developing the required changes for their mining software. |
490ff68
to
950fd20
Compare
TT-Miner also tested and working for both solo and pool mining with the reduced DAG size! |
T-Rex miner working now too! |
* Reduce DAG size to 2GB (reset to epoch 0) * Increase the epoch length such that DAG size will increase approximately 750MB per year
950fd20
to
8b3658b
Compare
Just set the mainnet transition height for the DAG size reduction to 2100000 (in aprox. 4 months). |
Thanks. A block height of 2 million would have been okay when being discussed three months ago, but we are ready now. An extra 100,000 blocks gives higher RAM GPUs a bit more time to mine before additional miners with cheaper GPUs join in. Most importantly, we needed more time for all stake holders to update, with a minimum of non-upgraded community members! In the future, we want to be very, very conservative on mandatory updates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving changes, although I personally am not equipped to test the ProgPow DAG size reduction. I understand that this has been tested with third party mining software, and that now we have the three popular ones updated to suit.
Changes:
Required external changes: