I don’t want to derail this thread, but the strategy of “make a new t-address for each receiving transaction” provides no actual privacy. I’ll briefly describe why, and what the problems are.
There are two issues here: first, the detection of funds. The light client protocol was not initially built with support for the transparent protocol - transparent support was essentially “hacked in” later on, and as a consequence, a wallet reveals its “interest” in a transparent address to the light wallet server when it queries to check whether funds have been received on that address. This can be mitigated via checking over TOR, but this also isn’t sufficient because if the wallet queries for multiple addresses at once, the light wallet server can then know that the same wallet controls all of those addresses, linking them.
The second issue here is that when spending funds received on transparent addresses, unless funds received on each address are shielded independently and in such a way that no observer of the chain can use timing information of those transactions to cluster them, those addresses end up linked together when the funds received by them are used as inputs to a shielding transaction.
Fixing the former requires changes to lightwalletd and its use by the ecosystem; however, lightwalletd currently has no maintainers. So we are pinning our hopes on Zaino to move us forward on this front. But then, the second issue remains; while it’s possible to use auto-shielding functionality to reduce the burden here somewhat, the UX of this is kind of horrible because in order to avoid temporal correlations, you have to set up the auto-shielding to take place over a long period of time, using a Poisson process to randomly choose when to perform the shielding operations. Having a mandatory delay of hours to make the transparent funds accessible is gross.
Basically, rotation of transparent addresses provides no actual privacy, and anyone in the Bitcoin world who is claiming that it does so is lying to you. Use the shielded protocols instead.
The zcash_client_backend library has just been updated with complete address rotation support in service of making it possible to recover funds from fully transparent wallets. We still have to decide exactly how we want to approach the issue of whether to support transparent address rotation, given that for it to be used securely, it will impose a substantial UX cost.
Me too. But the reality is that as @nuttycom lays out succinctly, there are a lot of reasons why it isn’t always practical to be 100% in the shielded pool. Zcash is among other things a financial tool, but it’s one that isn’t yet a complete ecosystem. There are perfectly valid reasons tax reasons, accounting reasons, or other financial reasons (collateral, proof of holdings, etc) for holding ZEC, at least temporarily in a transparent address. That’s why T-addresses were created and still exist.
Fwiw my intention is to be exclusively in the shielded pool in the not distant future, but as things stand in this present moment it’s not feasible for me to do that. I need to do things in the financial world that aren’t doable right now or aren’t practical to do with solely shielded ZEC.
I hear you, we should be doing everything we can to incentivize moving to the shielded pool. And keeping your coins there certainly is the marker of someone serious about Zcash and its optimal use case. It doesn’t mean though, that there aren’t voices worth listening to on the transparent side of things. IMHO.
I am listening, I don’t mean to pick on you or other folks. I am frustrated with the unnecessary friction and hope we can power through this collectively.
I appreciate your cogent explanation and understand what you have pointed out. I now see why it’s a bigger deal to assure strong privacy originating in transfers to a shielded address mediated by transactions via t-addresses than simply creating new, unused t-addresses.
The two issues and their solutions do seem like substantive dev projects; and given that the only practical way to get ZEC into a shielded address these days involves transfer through a t-address, they seem like important issues to be solved. More important (in my opinion) than hardware wallet integrations and other projects that have more marketing than engineering significance.
WRT the delay of moving funds from t-addr to shielded, as a user, I would of course prefer that to be instant but I would also be ok with waiting hours or even a couple days (especially if that delay was parameterized and exposed so i can click a more-private slower / less-private faster button in the wallet).
Whoever is funding whatever in the Zcash dev ecosystem, as a user I’d prefer to see the nuts and bolts of the engineering made priority one.
The fact that different users have different preferences about what needs to be prioritized is the whole issue that governance is supposed to solve! For a lot of folks, shielded hardware wallet support has been a #1 priority for many years. And, there’s some irony here: the reason that the PR I linked above was written now is exactly because we added HW support, and immediately got requests from users who have funds locked on Ledger devices who want to import their seed phrases onto Keystone wallets and use those to recover and shield their funds. So shielded hardware wallet support has indirectly caused exactly your use case to be prioritized, when it might have otherwise languished in favor of other (NU7?) community priorities!
Note:The following post is not an endorsement of any sort on any mechanism. Repeat. I’m not advocating for any mechanism in particular. I’m posting as a Zcasher that has a lot of questions and not as Developer Relations Engineer.
This post is titled “So What’cha Want?” And lays out some options or possible paths/solutions forward
I understand we are presented some sub-optimal paths here because @joshs is telling us that there’s an urgency on ECC’s side and also because it’s a commitment he made with the Board and also with the Zcash community.
I don’t like to focus on solutions before knowing what we want to achieve. So I decided contributing with more questions than certainties here, my apologies.
Both community and coin holders have voiced out that they want some form of funding coming out of the protocol itself when the lockbox was polled and voted.
How should that be? Depends of how Zcashers want decision power to be distributed and how disagreements to be settled.
A whale zodler said that there’s too much noise. Another posted a signed message saying that until Coin Holders didn’t decide on funding the funds shouldn’t be spent. We don’t know much else about Coin Holders and what they want. We can assume they want to continue to hodl ZEC because they are Coin Holders. And not much else.
Deciding what’s funded, is an exercise of both direct and indirect power. But that’s what has been happening so far. There’s nothing new there, except for Coin Holders having a more prominent voice for the case of Coin Holder Voting (CHV).
Currently, “The Governance” mostly happens off-chain. There are discussions until there’s a reach to consensus to actually launch an “NU” with a new version of the consensus protocol that is a univocally forking to a new version. I don’t see how Coin Holder Voting as it is in the immediate term will change that.
In terms of immediate technical feasibility, except for the case of not doing anything at all or extending things as they are some period of time, I don’t see a winning candidate clearly from the presented options on this post or in the forums. I have the impression that the zBloc is technically far away and its composing parts are not a high priority of any of the development teams. Except for the coin holder voting CLI and servers, the rest of the tech bits to make zBloc feasible like easy to use Frost wallets, voting front ends, auditing mechanisms, etc are an expression of desire.
The CHV mechanism is “closer” but not definitively 100% ready to used at scale. There’s a lot of trust involved in the polls as they are now. The 2.0 version that Hanh has announced dev complete days ago will need more work to be fully functional as people would probably expect it to be. It needs to be fully audited and to provide the infrastructure that can allow people to run polls and others to audit the results properly. There’s a lot that will have to happen manually to run CHV. It’s not that zec-whales will digit everything that happens with polls from deep under water.
It has to be noted that when one asks a question, one should be prepared to face the answers.
I feel that while some zcashers have the certainty that these coin holders will back their claims and calm their disscontempt, anxieties, wash out all their pain and bring a soothing breeze of air, while others are afraid that some Zetacean plutocracy will erupt from deep waters and dictate terrible things. I estimate that probably neither of those two things will happen.
But we do have to be careful of something that is implied here in this post from another thread
It could be possible that someone will a lot of capital can borrow a lot of ZEC and cast itself as an ephemeral-evil-Zec-whale and cast an election with that brings great distress to the ecosystem and win it over. Could it be possible? It could.
But I also want to think about that under a different perspective and I think I’ve have talked about something like this with @nuttycom.
Currently nothing stops anyone from forking Zcashd or Zebra and start a campaign for their fork to be adopted by miners. It’s not that we are risk-free in terms of “palace politics” moves. I guess that coin-holder voting makes it more visible, at the end of the day, code will have to be written, deployed, ran and PoW will have to be produced. Coin-holder voting will not change those mechanics. Am I putting this correctly @nuttycom?
What happens if coin holders vote on something that has no implementors willing to do it?
Is that soothing the “less governance noise” that some zec-whale wished for? I don’t know. Do miners actually care to be “up to date” with Zcash ecosystem nuances to decide which Zebra fork is better if several versions with different features compete to be “the real zcash”? I’m not sure.
To wrap up all of this rhetorical questions, I want to us to focus on things we do know. I think both the zec-whales and Zeals want a funding mechanism that allows:
Some great extent of the development to be funded from the protocol
that accommodates big development orgs like ECC, ZF or QEDIT and smaller contributors like small dev shops, individual contributors and non-engineering community projects
Accountability for those who carry those projects out.
A mechanism to voice whale and zeal opinions/concerns/proposals
ZEC to thrive and succeed at its mission.
Am I missing something? what are your thoughts? what is the best mechanism to achieve those goals?
a) The zcash community voted for a lockbox an a one year extension to ZCG. One of the major reasons has been the difficulty in holding organizations an individuals accountable for the funds received. Let’s maintain this vote.
b) No major decision in this community has ever been conducted using CHV method, how can this method get baked into governance when it is still in its earliest stage.
c) should it not be an expectation that every current organization or individual receiving funds from the zcash network, publicly state the preferred governance positions. Including current board members and staff.
d) should it not be an expectation that the orgs which have received the most zec funds loan some human hours to important governance ideas and discussions. (Publicly) @pacu (great beginning summary)
I am not sure I see what difference this will make. The ECC received tens (or hundreds?) of millions in funding and here were are now. The whole lockbox would just add ~2 m.
So what would happen if ZF and ECC stopped getting money from the community, which I would definitely recommend! They would have to look for investors to continue funding them.
If they don’t find them, they would stop working and the community would realize that they haven’t actually done anything except make a lot of money to fund their living and real estate, and the rest as the community would be left with an unfinished project after 8 years. But it would also be a good thing, we would see prices drop to about 1-5$. I think that would be great, the community would get something back instead of just footing the bill.
True, but there was also runway… and I seem to recall one of the main concepts of what Josh suggested when the ECC revamp occurred was to not receive direct dev funding anymore but to seek out other sources of funds. So they hired additional staff, which raised their costs and now need a bailout to continue “building the future”. It sounds tired to be honest.
ECC keeps thinking about tapping into the locked funds—are their brains made of wood? Use some common sense! If the price keeps tanking, no amount of ZEC in the lockbox will be worth anything or able to support ECC or any other organization. The key is to figure out how to boost the market price. Maybe start by having ZF convert all their BTC into ZEC.
If ZEC’s price were the same as XMR’s right now, would there even be this many concerns???
I never really got involved in the community forums or dug deep into ECC and ZF before. But after finally understanding everything, it makes sense why ZEC’s price has been dropping. It’s understandable.
Also not pay out any more and if there is no other way then the last time.
Incidentally, I would be very interested to know whether ZF and ECC trade against the community on the exhcanges and also do zec mining on the side to enrich themselves?
whether active or passive in both cases is irrelevant here. Because I trust them to do anything.
The reasons for these downtrends without bounces during each bear trend are already guessed by many. This may be a misinterpretation, but in one way or another anyone who starts looking for the reasons also considers that this self-financing model is apt to decline. Usually we wave away this phrase “miners sell too”. But here we are now at a place where they are at a severe loss and most likely not selling.
But the most important thing is that with this model, sooner or later self-funding will be over for everyone and forever.
When we first started talking about LockBox I somehow took it not as an emergency vault, but as an attempt to rebuild the model and an opportunity to create a truly self-funding system in a new PoS-steaking environment. In truth, the price of ZEC would have to be very high anyway for this model to work, but I never see anything impossible if we’re talking about cryptocurrencies with deficit bitcoin issuance. But how to get to this model?
It sounds fantastic, but ideally there should be a defined SMA price for the period, below which the current ZEC price goes down, automatically triggering an emergency mode in which some optional features are paused. Absolutely fantastic.
Hey all, seeing all these discussions about ECC funding and lockbox decisions, what do you think about a governance platform that makes these proposals and votes more accessible?
Looking at the debates here, it’s clear we’re struggling with:
Complex multi-stage decisions about funding (or anythink)
Questions about how to include both transparent and shielded holders
Difficulty tracking discussions across forums
Need for better visibility into proposal status and outcomes
Other protocols have unified platforms for this - just checking the pulse if the community thinks this could help simplify our governance process?
Would be interesting to have, but at the moment the governance system isn’t that clear cut to tally.
If it was pure ZEC holder voting then that could work. As of now we have polling involving: ZCAP, ZecHub, ZAC, Zcash Brazil, etc… and I don’t know if those could be accounted for in that style system.
Another question that parallels this discussion, ECC appears to be the most tenuous financial position - what about ZF? And Shielded Labs? Would be interesting to look and compare functions, company sizes, burn rate and runway.
