I’m not sure that is the best move either. I think the devs at ECC and ZF are doing good work and I would consider them critical to our upgrade path.
My bottom line is I want the dev fund, but we need to streamline what gets worked on because we have a situation where dev fund work vs zcash work is fighting for resources and we don’t have enough engineers.
You certainly have the right to question and criticize, but no one has the right censor legitimate Zcash users from governance based on their personal notions of what Zcash success looks like.
Potentially alienating a massive chunk of coin holders isn’t success. Of course, we all want shielded ZEC to soar. This can be achieved gradually with better UX, not through punishment. Carrots, not sticks.
Their $3M of ZEC on a Trezor doesn’t count for voting unless they send (risk) it all to a hot wallet that supports shielded voting?
I understand both sides of the argument, is it desirable that everyone holds their ZEC shielded?
Of course, but we also have to consider that the current situation for coin voting is immature and evolving and not without risk.
Until our coin voting system is better sorted then T-ZEC holders have to be allowed a vote. All coins are created equal.
Truth be told, with 3 million dollars, I can afford a separate iPhone out of the box for $1000 just for that and a Keystone for $150. And it will be no degradation of storage security compared to Trezor. Because Trezor also doesn’t support multi-signatures.
@Lixin, @keystone can you confirm this for me and our esteemed whale outgoing.doze?
Personally, would you trust your own $3 million dollars right now for safekeeping on the Keystone 3 Pro?
Btw, one time I lost full control over my addresses because Trezor blocked my IP for its server. I couldn’t even see the balance on my addresses. Even though it was ETH related, I still didn’t like it. I had to look for options with a VPN and connect from another laptop.
Whereas Zashi will never do that to you because you can use your own Lightwalletd node.
I don’t have a clear position on this issue either. I agree with both you and Josh. But every time there was a vote I looked for ways to vote and asked my friends to do it. We sat there and moved their transparent balances like fools from Trezor to YWallet, even though we realized that the vote was a formality. The question is how much you are into Zcash that’s all. If voting is important to you, you’ll do what you can. And if it’s not important, then it’s not your vote.
Your goal, yes.There are t and other addresses.These are what characterize Zcash and everyone should have the right to use them without any restrictions.
This is the time to quantify these mission critical activities for each wallet, app, cex, ecosystem member an associate a dollar value to evaluate the choice of where future block generation resources are allocated.
ECC made a strategic choice to direct its first class engineering talent and resources to the zashi application. This strategic choice away from zcashd core development has reduced its critical mission position in the ecosystem, as well as weakening the overall zcash network by once again users will be required to rely on one software node implementation to access the zcash network.
This mission critical decision has reduced its position. Why should critical future block resourcing be funding a simple application, support services and governance guidance?
Please quantify: current zashi user count, cex zallet cli use, number of critical ecosystem participants? Place a dollar value next to each item, keep your core engineers, and cut the rest to the bone. Make a zero budget, work backwards to justify your public mission critical action plan.
There should be a sustainable incentive model for developers. There also should be a sustainable incentive model for Zolders. If both are struggle the incentive model for over 8(or +1=9) years. Then there is need to find the issue with the previous model before figuring out the correct incentive model.
Actually, I am glad with ECC come up with something(future fund model). For instance, without Zashi launching a year ago(a lot people opposed it at that time), I can not imagine the current situation of Zcash in the market.
Frankly, I am so curious about the argument of ZF. After 3 months from 2nd halving, there are no signs for ZF to discuss the future incentive model, no roadmap about future developing. If I remember correct, the last ZF blog discuss the outlook of Zcash development was 4 years ago 5 years ago(The first CEO of ZF wrote it?).
At least, Josh/ECC is actively communicate with the broad community, explore new paths/possibilities, try to self-fund Zashi wallet, build the unstoppable money.
Unstoppable money doesn’t exist with transparent coin voting.
Transparent coin voting is a backdoor to invite all kind of centralized parties to the table, so they can serve their own agenda.
Somehow your financial transactions should be private but your voting should be recorded on a transparent immutable blockchain. Yeah what could go wrong. Remind me again why everywhere in the world voting is a private procedure?
Fix the privacy coin’s wallet so that it’s … private. Make it spin up a new t-address for each receiving transaction by default. This is something that is so ubiquitous in BTC wallets that code has to be everywhere so I’m imagining it couldn’t be such an involved fix to what seems like a major design flaw.
As a user this is far more important to me than hardware wallets, nebulous “vaults” or anything else I keep seeing mentioned with little excitement emoji’s all over the place.
This is somewhat off-topic but of anyone wants a
more decentralized and resilient ecosystem, they should start taking ownership on some of these tasks.
ECC should also continue to foster contributions from other teams so this can happen more organically and naturally. The irony is that this is yet another task on the list.
Under the current proposal, there are two sources of funding from block rewards (community elected / ZCG and coin holders), anyone can get funding off chain, and what is ratified in consensus subject to veto.
This is an incorrect interpretation of what happened in the decision to stop supporting zcashd.
The ECC engineering team is in full agreement that zcashd is legacy software that is far too expensive to maintain, and working in C++ results in a huge cost for safety analysis whenever we make code changes there. C++ is not a safe language, and zcashd is not well-written C++; while the bitcoind codebase has evolved and improved since 2016, ECC has not had the resources to backport many of those improvements (and such backports are colossal efforts because they must be reviewed for safety in the context of the changes made to support the shielded protocols.)
I personally advocated rather hard that the zcashd full node wallet be considered deprecated prior to the NU5 upgrade so that we could focus our resources on developing the Rust wallet stack, exactly because of the huge cost of updating zcashd to support Orchard. Updating the zcashd wallet to support Orchard was a significant cause of the delay in releasing NU5.
Essentially, zcashd is a dead albatross hung about Zcash’s neck, and the sooner it can be fully deprecated, the better it will be for the entire ecosystem.