Closed us77ipis closed 1 year ago
https://github.com/Veil-Project/veil/blob/249cee76d69c3f057acd156c5ab4b76ae795df9c/src/rpc/mining.cpp#L761 is still using ethhash::get_epoch_number
You're right, forgot to commit that file.
additionally, there are 3 separate declarations of (and all different values) for nHeightProgPowDAGSizeReduction
. Only the one referenced by the constant method call is used but the others should be removed.
My mistake, they are for dev and test nets. Disregard
That is for the different networks main, test, dev
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.
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!
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 mining.notify
stratum message telling the epoch. But one way or the other, mining software has to be changed. Also woolypooly will have to change things for the pool to continue working.
they would have to either hardcode the change
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?
none of the mining software is open source
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. You will also need a hard fork which means you needs to get all the Veil partners to update at the same time.
Here is a spreadsheet you can use to calculate the Veil DAG size. veil-dag-sheet.xlsx
This is a bad idea, allowing GPU's that were ROI'd 4 years ago, to mine again will crush the price. You will also need a hard fork which means you needs to get all the Veil partners to update at the same time.
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 (https://github.com/andru-kun/wildrig-multi/issues/144) and T-Rex (https://github.com/trexminer/T-Rex/issues/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!
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. @us77ipis Have you got any action from TRex yet?
Have you got any action from TRex yet?
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 getblocktemplate
rpc for getting T-Rex working with all its DAG pre-computing optimizations.
What about TT-miner?
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 Seems inactive since January 2022, which is more than the older version in github that looks like someone just uploaded a copy years ago.
TT-Miner developer contacted us over discord, and is now developing the required changes for their mining software.
TT-Miner also tested and working for both solo and pool mining with the reduced DAG size!
T-Rex miner working now too!
Just set the mainnet transition height for the DAG size reduction to 2100000 (in aprox. 4 months).
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.
Changes:
Required external changes: