How and when will you decide a mining algorithm?
There’s things to learn from the BTC/BCH debacle that would help keep things friendly, making sure nodes can play nicely together (different port numbers, data dirs), etc…
I’m kinda seeing this as a testnet for PoW change & ASIC resistance - there’s been more than enough squabbling about that in the mega thread so this will prove things one way or another.
You mentioned blocksize as a ‘whatever it takes’ measure to keep tx fees low, I find that worrying as it replays the BTCvsBCH narrative - hopefully that can be avoided as it proved toxic & damaged both.
I already answered you: I said that I was using the royal “we”, as in I was referring only to myself.
There will be no announcement about a “team”. If you want to see who is contributing code, you’ll be able to see that on Github, when the changes get implemented between now and July. Even then, you can’t assume that someone contributing code is part of a Ycash “team”. They might just be responding to a development bounty.
This is not some sort of ICO where I announce some all-star team of developers and crypto “thought leaders”, hoping to raise money from people. I’m not asking anyone for money. Quite the opposite: I’m spending hard-earned money out of my own pocket to get this launched.
The split does not differentially favor certain ZEC holders over others. If you hold ZEC private keys, you will be able to spend the same amount of YEC, whether you are a Zcash Founders Award recipient, someone who mined all the ZEC that they hold, or someone who bought all the ZEC that they hold.
This is the case for any chain fork of Zcash. The founders hold the keys to the original Zcash founders reward addresses so just like any ZEC holder they would be able to claim coins on a new chain (if they would want to do so). Which is one of the reasons why every fork up to this point has been a code fork, not a chain fork.
What could be changed from a fork forward would be the addresses that the reward (5% forever?) would pay out to, which I would assume would be a new Ycash Foundation that AFAIK doesn’t exist yet.
Categorically, the Zcash Foundation wasn’t and isn’t involved with Ycash. @hloo can confirm that.
It’s too early to say whether that may change in the future, since we haven’t had time to discuss it internally and work through our thoughts.
The Ycash Foundation will be incorporated in Delaware. I have reserved the name with the Delaware Secretary of State, but have not filed the incorporation papers yet.
Yes, on the Ycash chain, going forward the 5% all goes to the Ycash Foundation.
Confirmed, the Zcash Foundation is not (and was not) involved in Ycash.
I would be very interested to hear in any thoughts you have on potential mining algorithms, @naimed.
In the long-term, the goal for Ycash is mining on commodity hardware, the more commoditized the better. If viable CPU mining is achievable, I would favor that. (To me, the existence of botnets is not reason enough to avoid the goal of CPU mining.)
In the short-term, the decision is greatly constrained by very limited developer resources. At first, I wanted to launch in July with different Equihash <N,K> parameters, under the assumption that, given the time constraints and the limited resources, changing the <N,K> parameters would take less development work than swapping out Equihash entirely for RandomX or ProgPOW. But I’ve been told by someone who mines with FPGAs that many of the Equihash variants are currently being mined extensively with FPGAs using proprietary bitstreams. That miner argued that, for Equihash<200,9>, at least you can go on Ebay a get a Z9 for a couple of hundred bucks. If we switch to the wrong Equihash parameters (and it might be hard or impossible to know which parameters are safe given the secretive nature of the FPGA mining ecosystem), we risk being dominated by FPGAs, and not advancing the goal of mining on commodity hardware at all.
If trying to find a suitable <N,K> is a futile endeavor, it might be a better use of the very limited developer resources to just move straight to RandomX or ProgPOW by October.
So the default plan right now is to launch in July without changing the mining algorithm, and then use the funds from the YDF to fund development work to switch to RandomX or ProgPOW by the end of October.
But if there are developers out that are interested in working on this right now, either as a volunteer or for compensation in either ZEC or future YEC, please contact me. The more developer help, the more the switch to a different proof of work can be accelerated.
Great point. I’ve had discussions about changing the port numbers, and perhaps changing the address format so that there is no confusion about whether a given address is a ZEC address or a YEC address.
Hi! Here are some off the cuff thoughts of my own, and don’t reflect ECC positions or plans:
- As @hloo suggests, I also see Friendly Forks in a similar fashion to this post. I like the framing of pluralism, and look forward to reading more about it.
- I really appreciate this approach that’s engaging with and inviting to this pocket of the Zcash community.
- I recommend for Ycash devs to learn from other Zcash source forks and also chat with Zcash engineers about how to make the implementations operate safely between each other. And, in particular, next point:
- Since this is the first chain split I’m aware of involving a chain with zkSNARK-style shielded funds, I recommend ensuring the “air drop” / “snapshot” will include shielded funds (at least Sapling). This prevents creating an incentive to existing Zcash Sapling z-addr hodlers to deshield their funds. Doing this should be feasible, although I already have at least one technical privacy concern (we want to ensure there’s no way to link shielded transfers across the two chains), and I recommend for any shielded ZEC holders concerned about privacy to wait for some assessment here.
- It is true both that Zcash FR recipients are likely to receive YEC due to the chainsplit and also that they’ve parted with some portion of FR for operating expenses, taxes, etc… The current total FR issuance is an upper bound, and that estimate could be lowered by looking at transparency reports from the Foundation or ECC. (I don’t see this as a negative for Ycash; Zcash FR recipients will initially have some financial incentive tied to Ycash’s success.)
- I have not heard about Ycash before this post, and ECC has not participated in any way in Ycash as of this post. However, I did chat with @hloo in person a week or two ago, and we did discuss the counterfeit protection via the turnstile, and maybe I mentioned to him that at ECC we haven’t put more effort into Harmony Mining in lieu of our other efforts. I do not know if that affected this Ycash project planning in any way.
- As for disagreeing with ECC’s technical decisions around Zcash, I think users have three productive options:
- Help Zcash open up its development process to more teams / contributors than just ECC. The most direct opportunity there is to participate in the NU3 ZIP process. Also, I welcome anyone to proposing ideas on how to open up development or alter governance for Zcash on this Forum, Foundation mailing lists, at Zcon1, etc…
- Code up your own vision, which is how I see Ycash and other Zcash source forks. Ycash is notable, though, as the first Friendly Chain split. After all, “cypherpunks write code”.
- Find another existing project that embodies what you prefer. And as always users can distribute their time, money, and love across multiple projects and communities.
Ok, that’s my off the cuff, personal thoughts. I’m really curious to see how this develops across the community, and I look forward to chatting with @hloo and any Ycashers at the next Bay Area Zcash meetup.
I am both speaking on behalf of the Zcash Foundation, as its Executive Director, and sharing my personal assessments.
@hloo’s plan to create Ycash represents a truly user-driven exercise of voluntary exit, intended to change the trajectory of a project that he clearly loves. In general, forks (or plausible threats of forks) are powerful governance tools; so much so that it was one of the reasons the Foundation partnered with Parity to build a separate Zcash implementation. The Foundation is glad that @hloo is exercising his rights — Zcash is open-source software on purpose, in part to afford this freedom to users. We wish him well in the endeavor.
Forks and Friendliness
Forks are fundamentally political acts. Even in the case of a routine Zcash protocol upgrade: A successful upgrade ideally demonstrates a universal collective choice. If it were possible to force upgrades on everyone, instead of communicating the value and counting on people to decide to upgrade, it would be coercive. An unfriendly fork would mean that an upgrade was contentious enough to prompt a significant segment of users and miners to choose a different path.
A “friendly fork” is a strange beast, to be honest, and I’m not sure that I like the term. On one hand, close collaboration between projects with shared components and goals is worthwhile… but on the other hand, recent forks indicate that fracturing a community could dilute the value of both projects. So it’s possible that even the most amicable of forks could reduce the economic activity and value that otherwise would have remained within the first project. The friendliest fork is the one that doesn’t happen.
That said, attempting to stop a fork when any user has the right to copy, modify, run, and distribute the software would be just as coercive as forcing an upgrade on users that didn’t want it. In my view, it’s better to have collaboration and alignment, rather than a more significant schism of the community.
I do have some open questions about the Ycash fork that I think are worth discussing.
First: One of the main reasons why you’re forking Zcash is concern that currently unmined ZEC will be redirected from miners in the future. You cite a promise about monetary distribution which you feel is in danger of being violated. Hence you want to create a new funding distribution scheme… which violates the same promise in the opposite direction, because it redirects unmined ZEC from the people who would receive it under the current rules. Do the old promises not apply to a forked blockchain? You could argue in either direction, and the cryptocurrency world is still establishing its norms. But it seems strange to ensure a promise (that has not yet been broken) by breaking it differently.
Second: As a consequence, the recipient of the funds you are redirecting is the Ycash Foundation, which will (eventually) have more YEC than any other Founders’ Reward recipient. This concerns me, as the structure of the Ycash Foundation is undecided (or perhaps decided in private), besides owning the Ycash trademark. (As an aside: Redirecting funds throughout the mineable lifetime of the blockchain indicates that you implicitly support some mechanism for long-term support, which seems to lend credence to the idea of a new dev fund for future Zcash work… though you hold the 2.1 million limit more sacrosanct.)
Third: Another primary motivation for this fork is PoW that works on “commodity” hardware, but it seems you’re launching with the current (ASIC-able) Equihash parameters? Given that this is one of your fundamental goals, wouldn’t it make sense to wait until you have committed to integrating a different algorithm that can actually keep “commodity” hardware viable? Particularly since this could put Ycash users at risk if hostile mining pools decided to engage in nefarious activity with accumulated Equihash power.
Fourth: I would generally discourage the use of the royal we in making proposals. It can be confusing in the case when you are not speaking for a multi-person team. I understand now that you were referring to the Ycash project, but that was ambiguous until clarified.
Fifth: It seems likely that promises around monetary policy would have to be modified if Ycash migrated to Proof of Stake (based on the need for continuous inflation in that system). You may even have to modify it for Proof of Work. (Based on some work on the instability of fee-based blockchains.) Maintaining low fees will make keeping the promise even more difficult.
Sixth: Per @nathan-at-least’s point, this could have a privacy impact on shielded users and it’s worth investigating before shielded users move funds on both chains.
For me (and/or the Foundation) as a potential Ycash user, I would care about these concerns being addressed. Particularly with respect to the structure of the Ycash Foundation and the need to fork with the current PoW (which puts Ycash in danger of being attacked by Equihash miners).
I do appreciate the design goals and the spirit of your plan @hloo. I wish you luck, as does the Zcash Foundation. We will continue to support Zcash (and thus Ycash downstream).
Permanence of Promises and Promises of Permanence
One final thought for the community’s consideration.
Now is a good moment to reflect on the permanence of promises, and the promise of permanence. This fork is motivated by @hloo’s view that promises have been broken, and are at risk of being broken again in the future. What if promises about Zcash or Ycash must be broken in the future to ensure their survival? Where do we draw the line?
My view is that if there’s a technical or economic reason to break a promise, the onus is on the proposer to explain why it’s worth it, and to cultivate broad, overwhelming consensus as best as they can. Just as the onus is on @hloo (and soon the Ycash Foundation) to encourage users of Ycash to restore promises that he sees as broken. Absent a polling or governance mechanism that can authoritatively describe consensus, perhaps the best measure will be how much an alternative fork catches on.
I am optimistic that a shielded pool polling mechanism can help, but it’s only one input in a sea of noisy data, and it’s possible for users to lack the information needed for a sound decision. I don’t have any concrete answers here, but the question is fundamental to the governance challenges of any protocol aspiring for decentralized power and decision-making.
Thank you so much @nathan-at-least for your comments and feedback.
I really appreciate this. As a Zcash user and holder, the last thing I want is for this chain split to disrupt the Zcash network in any way. I’ve had discussions about changing the port numbers for the peer-to-peer and RPC communications. (I’ve also had discussions about changing the address format for both transparent and shielded addresses, similar to what Bitcoin Cash did, but perhaps that’s more related to usability, not safe coexistence of the different implementations.) To all the engineers out there, what changes would promote safety?
I think this is really important and I’m glad that you brought it up. If a chain fork were to not include Sapling funds, I would consider that to be hostile to the principles underlying Zcash (precisely for the reason that you put forth: It would incentivize users to deshield their ZEC). I consider inclusion of Sapling funds to be a necessary prerequisite for launch.
That’s a good idea! I hope you do that.
Disagree — I think current Zcash coin-holders, current and future Zcash users, and perhaps even future Zcash coin-holders are better off due to friendly forks like Ycash.
By the way, I had no inkling of this before I saw the announcement. I called Howard earlier today and talked with him about it for an hour. We talked about values, policy, where the Ycash Dev Fund will go (to a USA non-profit), and a few technical details like the “branch ID” or whatever it is called that we added in Overwinter to provide for bidirectional replay prevention. Nothing he said in that conversation raised any concerns for me, and nothing he said was inconsistent with what he’s said publicly.
I think this depends on your definition of “friendly” and one’s view on whether forks always (or with high probability) have a dilutive effect on both communities.
As prompted by my questions and some of this discussion, there are good reasons that the broader Zcash community might not be immediately better off as a result of this fork:
Without separate address formats, the UX could create confusion or lost funds. This does not strike me as better or friendly.
Using the same PoW puts Ycash users at risk of 51% attacks and reduces Zcash security. This also does not strike me as better or friendly.
Doing this could reduce the privacy of shielded users (even with Sapling inclusion) across both chains. Not better or friendly.
@hloo has stated in this thread that he’ll consider inclusion of a new address format—which is great—but the other issues (and previous questions I and others have raised) should be considered critically.
Longer term it could certainly have a positive effect! But simply stating it’s friendly doesn’t make it so, particularly in the short-term.
Here is an important question / thought ?
What is to keep the current Zcash founder rewards (those that have HODL their Zcash Coins) and or Zcash themselves from dumping every single Ycash coin within a few days of its inception and making this a penny coin almost instantly?
And if the response is “We would not do that” I call Male Bovine Fecal Matter
I’am still very sceptical to such “friendly fork” and more and more concerns raise the longer i think about it:
1.) Security concern: As mentioned allready several times if Ycash isn’t the top coin of the algo there will be ALWAYS the threat of a 51% attack. In case such attack soon or late happens it would have a negative impact for Zcash as well. Just be sure that Zcash will be mentioned in every article as well beside Ycash.
2.) Mining Community concern: Zcash since Asic “adoption” has without doubt lost a lot of the mining community. Best indicator is the drop of the active wallets from over 121,000 to ~20,000. The launch of Ycash will come around the same time ETH switches to POS. There is no doubt that the ETH hashpower will be distributed along the remaining projects even given Ycash some miner activity boost when it goes to gpu mining. However, this would as well mean that immediatly there is a good chance Ycash outperforming on miner count & active wallets. I can’t see a positive impact for Zcash here. A real good strategy in my opinion would have been ZEC switching back to gpu mining and taking ALL the free hashpower from ETH. There is a good chance ZEC would become #1 for gpu mining making it as secure as ETH is currently against 51% attacks. Not even talking about the huge active mining commmunity increase and the active wallets. No idea why nobody as even strategical thoughts at Zcash but leave this field to some fork coin…
- Economical concern 1: There is a good chance that economicaly such friendly fork pricewise will turn out like the Bitcoin Cash fork, no matter it was unfriendly “war” fork. Making both currencies at least short time losing a lot on their price levels. Every price change has impact on the (ZE) Dev and Foundation funding as well. At very least there is a risk that one if not both may lose on price short term, mid term and eventually even long term.
4.) Economical concern 2: Dumping Ycash immediatly. There is again a good chance, as witnessed allready at Zcash release that price will fall a lot after release. This is just logical as forks from a given currency and/or airdrops are just a “bonus” to orginal currency holder. There is no really incentive, expect for hardcore believers, to hold such coin after it’s a known impact that price in most cases will fall immediatly after release. At least that’s my overservation on several forked coins, including Zcash itself. Sure, there are some expections, but these are way less.
5.) Economical concern 3: As seen on many pre-airdrop/fork cases. The price of the main currency will temporary rise right bevor the snapshot. No doubt that this will happen to ZEC as well attracting a lot of day traders that will sell right bevor the snap shot their ZEC at highest price as right after the snapshot price will fall. I even have no doubts that exactly this scenario will happen. As soon as the snapshot will happen ZEC price will go down immediatly.
6.) Zcash Dev Resources: I have no doubt that this will take away Zcash Dev Resources which try to help at start and mostly later as well. Each “wasted” Zcash Dev resources means less development at Zcash itself. No matter how big the “help” for Ycash is it will always proportionally impact the Zcash development. This is even more likely as the ECC company and others will have a big stake in Ycash anyway. Just logical in my opinion.
7.) Zcash investors and independence concerns: I have no idea how big the stakes are from the early Zcash investors like Roger Ver and all the others, but someone should/could assume that they still hold large ZEC stakes. All these will become automaticly Ycash bag holders immediatly, just as usual with chain forks. Nobody knows their stance towards the Ycash project. At release date all these big stake holders may act upon their personal economical believe, holding, dumping, or pump and dump. Nobody knows but i think this should be at least a minor concern as well.
8.) “Expiring ZEC founders reward bypass attempt” concern: As i said earlier in this thread it could be seen as an attempt to bypass the expiring ZEC founders attempt. With the ZEC founders reward soon (2020) expiring, having a “friendly fork” with creates a new founders reward for lifetime and with the intention to share future technology/innovations/whatever from Ycash towards Zcash it’s really near to think that just a new development fund is created to replace the expiring one. Even if it’s not intentionally the result will be the same. What happens anyway in 2020 when the founders reward expires and no more funding is generated long term? Some conspiracy theories: Could it be that step by step the Zcash team gets hired by the Ycash team? Could it be that Ycash becomes the major coin and Zcash gets more or less just abandoned? Has the change from Zcash Company into Electric Coin Compain something to do with this? Is it really just and only 1 person behind the Ycash project or supported by way more inside/internal ZEC “people”? And and and. Just raising some conspiracy theories that would raise soon or late anyway. I have no stance on these by the way!
9.) Upolding a promise which isn’t broken yet concern: It has been mentioned allready, but it’s worth to mention it again. How strange is this indeed? Promising to uphold a broken promise which isn’t broken yet and there is even so far no indicator that it will be broken? There are 2 possible options here in my opinion. Either it is internally known allready that the founders reward will be extended or the Ycash statement is at least missleading and suggesting that the promise will be broken. After the whole asic resistance debatte this suggesting isn’t really friendly at all and puts Zcash into a corner with the slogan: “We don’t care about promises ever…”
10.) ZEC foundation support concern: While i agree with everything @acityinohio wrote in this topic expect this one: I wish you luck, as does the Zcash Foundation. We will continue to support Zcash (and thus Ycash downstream)
Seriously? You guys/girls at the foundation are realy great people i honestly like, but you are still lagging a lot behind the goals made for/by the foundation. I strongly hope you re-consider this one and put 100% into Zcash matters and leave alone every non-ZEC project. At least as long as ALL ZEC foundation goals are achieved. After that, if you still have some free spare time support whomever you feel like, but until this happend and the ZEC foundation is lagging i strongly hope ALL effords are put into the ZEC direction and nothing else.
11.) Recent news concern: Right now the online news are distributing all around this Ycash fork with headlines like:
- Zcash announces Ycash hardfork: (Strange i didn’t saw any Zcash announcement so far)
- The Zcash community has announced that Ycash …(A One-Man-Show) shouldn’t be mentioned as the community. There was no poll, no discussion, no nothing, how can someone talk about the community???)
- We are launching Ycash to restore a goal (Again suggests a whole team and/or bigger community part behind this project)
- Ycash will maintain the positive features of Zcash such as zero-knowledge infrastructure.(Ok, and the negative features will remain with Zcash, lol, very friendly, thx a lot)
Stoping here, got to long anyway allready, not that there are not more concerns, but hopefully others will mention them…
I would be very surprised if ECC chose to compromise core development efforts to support a fork. Just because Nathan and Zooko are friendly to forks doesn’t mean that they will actively support them.
This would mean if Ycash “team” contacts Zcash team for help on various code matters, implentations, security questions, whatever, there will be no help.
Because IF Zcash dev team gets back to help requests it is taking away resources to help/fix Ycash fork/code/whatever problems, not?
Count me in for a pool for ycash