Funny I’m unable to vote. There’s an error when trying to sign up.
so it is a fake poll… damn they are really desperate 
Anyhow… that shows what kind of trust we can have in people orbiting the progpow sphere…
I think another MTP advantage is that it is unique. When a stranger takes a look at the technical information of Zcoin, the perception won’t be “another ProgPoW”. It has a totally different ASIC/FPGA resistant algo it developed itself.
For the next community meeting or maybe a separate livestream, I have tentatively gotten Henry Quan from Epic Blockchain who has built Grin ASICs and their company is comprised of former AMD engineers. He can talk about MTP, ProgPOW and maybe some RandomX.
Kristy can attend again though I suspect she will also write something to djm34
If @djm34 can come on too it’ll be great so we have some balanced views.
I have also extended an invite to Marc Bevand as well who has helped audit MTP and also ProgPOW.
Personally I want clear technical reasons as to why a particular solution is good or bad hence the invitation to technical people. Code is all available for everyone to inspect.
2 Likes
In my opinion it is a good idea to stick with a GPU friendly algo for 2 reasons:
- The current loyal following will be able to continue to mine XZC with their existing hardware
- There is a good chance to entice ex-ETH miners to join the network when ETH goes to proof of stake
From a perspective of sustainability - which clearly has to be addressed, like it or not, if this currency is to last into the 2030s and beyond. - I think that another method should be found for securing the network. The move to POS could well be an option, it is one which is used by Tezos, Cardarno and soon Ethereum, all of which are successful projects. I get the argument about the rich getting richer, so how about this; reduce the MN collateral to 100 or even 10 coins, then anyone who wants to get in on the act is not prevented from doing so. the cost of owning a node is reduced to the cost of buying a mining rig. You could even vary the collateral size depending on currency value. Make it so that a node cost no more than a months wages for the average worker in X country.
I like the idea of Optical proof of work, but if the rigs cost a packet to set up then we are back to the rich getting richer argument again.
To summarise, I think that progPOW is the way to go in the short term, but in the long term we need a different solution to burning electricity to secure the network.
The next community meeting will be on the 22nd February 2pm (GMT +8). We will be discussing the possibly of changing the PoW. So if you have an opinion on this this you should attend!
There was a great discussion on the community meeting which discussed the economics of what happens behind the scenes in GPU, FPGA and ASIC mining and hardware productions.
For those who missed it, catch the replay at https://youtu.be/MLnF2YmhcTA
regarding point 2. : First ETH has to implement ProgPow which may take some time and then may-be they will implement POS at some point. So expecting miner coming down mining zcoin from eth is a long way away, and quite frankly I rather see the inverse, depending who would implement progpow first.
If zcoin implement ProgPow first, once eth move to it, many miners will leave, together with dedicated hardware showing up (because there will be then enough incentive to build them, and considering the algo has been out for quite some time, I assume it will be pretty well optimize, I tend to believe that it is already ready at least in the form of a blue print, they just need to wait for the good opportunity to release… )
So say zcoin implement ProgPow and they get impatient and there is some hype around zcoin price ( too many if already), they release their dedicated hardware obviously faster than GPU… then what will happen is that every GPU miners will move to another coin, then ETH arrives, and the dedicated hardware will move to ETH… so basically zcoin would lose twice.
As I wrote several time on discord, ProgPow is a very bad idea because that put zcoin in the shadow of eth (in terms of image) but also the whole zcoin ecosystem will be too dependent on ETH.
Regarding the Masternode at 100 or 10 zcoins, this is also a very bad idea… For at least 2 reasons:
- If we put MN at 10 zcoins, we can imagine the large MN owner will just create more MN, other people will joins, so basically it means 10x more MN, which means also longer delay between MN payments so right now it is probably around 20 days… so basically you would get 1 payment every 200 days (yeah sure ).
Personnally, I keep my MN as long as it is viable to do so, which means that the value of monthly payout is bigger than my VPNs monthly fee… so If we end up with one payment every 200days, unless zcoin has increased a lot in value, it won’t be the case anymore and basically people will just spend money without getting any returns (not mentionning the halving which will come at some points…)
For large MN owner, it won’t change anything, because at any time, they will always get the reward from a MN… so the richer still get richers, the ones who are impacted are those who own small numbers of znode… and the new comers who will just pay VPS monthly fee with no returns…
- Second argument, basically the inverse, comes from the fact that MN are locking very large amount of zcoin away from the exchange, if the collateral is decreased, there is large chance, that people won’t create more masternode (because the VPN cost will start to become prohibitive) and will just keep those they have releasing the locked zcoin (assuming there are at the moment 3k MN that would be releasing 2.97M zcoin on the exchanges… which won’t be good for the price obviously…
But sure it will make znode cost well below monthly average wage but the return won’t pay the VPS fees… so basically it will be a lost for everyone… (except VPS provider companies…)
The only way you can win with a change of collateral is to take advantage of the mess it will be to reconfigure all the masternode (especially for those having large number of znode), if you are fast enough, you can make a killing for a couple days
3 Likes
Right now I think ProgPOW is not happening on Ethereum.
Though in any case, ProgPOW will be modified a little to differentiate it a little and to suit it for our purposes especially since we don’t have issues with requiring Keccak since there is no legacy for that.
One of the things we can do if we implement ProgPOW is to drop the block times further to 2 or 2.5 minutes since the headers are a lot smaller than MTP.
1 Like
If I was in charge I would modify MTP. Whatever you can do to lesson FPGA’s profitablity.
I would also fix these if they aren’t already.
Let monero stay on randomx.
Progpow - Could be a good option but recently a bug was discovered so there may be more bugs to be found.
MTP has been patched against those potential attacks before it was released to public
MTP will be always susceptible to FPGA with the advent of FPGAs with large memory banks.
Those attacks have been fixed and even others addressed. https://arxiv.org/pdf/1606.03588v2.pdf
ProgPOW bug is fixed.
1 Like
Just reviving this thread that we are still considering this but only after Lelantus and our other roadmap items are completed. We want to make sure we focus on delivering on the really important stuff first but it’s good to keep this discussion going.
Hope to have a proposal up soon.
whatever GPU friendly algorithm would make me happy. it’s been 2 years i think, since the last time i mined XZC. i can’t afford crashing every few hours mining XZC. i dunno why, since XZC uses MTP, i can’t keep the miner stable, always crash every few hours
1 Like
Thanks William for the feedback!
Everything has pros and cons in many ways:
A) Optical POW is not tested yet and still very much a theoretical. Pros power neutral Cons likely high dollar entry.
B) ASICS high power, high dollar constant arms race. Operation favours centralization noise dampening isn’t cheap. Pros high security barring “secret” new chip designs.
C) Multi Algo progpow and randomX have as shown by EPIC problems with adjustments given how differnet the two are. DGB (yes it’s a shit coin) have one decent feature namely how their multipow distributes work. However, the DGB model can not to the best of my knowledge accommodate more constraint based algorithms like RandomX and Progpow.
D) ProgPow on its own, in light of the seed bug and additional utilization of it in a birthday attack as outlined on github seems like a potentially mixed bag. There are to the extent of my currently limited knowledge only a handful of operations that could perform a birthday attack as outlined on github. Trusting that these operations not abuse that position is frankly lunacy. If it were to be tabled, higher complexity seeds and the advantage might give to one GPU manufacturer over the other would be the route to go down to keep it on reasonably solid footing. RVN’s implementation is currently working well but they have chosen to incorporate some changes that may render a birthday attack ineffective.
E) RandomX on its own was outlined very well by Reuben a couple of posts back. However, as more and more projects incorporate it, the dangers of botnets get significantly diluted, 5 or 6 smaller- medium sized projects I know of are currently looking at implementing it or have people working on implementations.
F) UGLY KLUGE is a thoroughly unpalatable solution to most it is essentially redneck anglegrinder and welder pow where you add enough bits to end up with something that will not store easily on an FPGA or cost an absurd amount to implement on sillicon. The problem with this is it also limits its own implementability on GPUs.
G) Options that suck for everyone there is an implementation of lyra2x330 out which has a worksize that floods out hardware pretty well. Making it mineable both by CPUs and GPUs at roughly dollar parity on efficacy. I have no idea how that would implement on FPGAs or ASICS apart from a few comments of “DAMN that worsize is the size of Texas” and “it needs HBM.”
With the rather underwhelming performance of reasonably high dollar FPGAs on ETH (yes I know that is only public streams), it might be an option for bigger heads than mine to comment on.
$ parity on entry is about as fair as it can get in terms of making it inclusive for as large an audience as possibly. Who cares if a 2000$ FPGA gets 2mh/s if a 200$ CPU gets 200kh/s and a GPU somewhere in between or something proportionally close.
I think the bugs u mentioned on ProgPoW have all been addressed afaik.
I don’t see anything addressing what Solardiz raised on Github but I haven’t dug into it at the commit level. It’s not so much an attack in the sense of breaking it as it is some really specialized setups could have extensive advantages on it.
It boils down to the next evolution needing to support efforts put into a say a rebrand and help drive the coin forward providing the best possible security that lines up with visions and aims for community.
All of the options I mentioned work except for the possibility of the last one implementing too well on hardware. but they are not for everyone.
For ZCoin mining, I am for the exclusive CPU mining : everyone has a CPU, then everyone must be able to mine XZC :-).
Why exclusive?
Would looking for something where 1$ of CPU is roughly equal to 1$ of GPU or FPGA?