You know the worse part, old shielded pools are treated as second class citizens in Zcash (don’t act as long term store of value when pools get deprecated — whether or not it is beneficial is a separate thing) while everything to do about t-addr is first class in Zcash.
Well, I don’t love t-addresses. I support getting rid of them when all of their functionality can be easily replicated with z-addresses, and users no longer have reasons to want them.
1 Like
Nice! I honestly didn’t know this. So you agree on the principle of deprecating t2t when we can.
I haven’t seen anyone offer a reason to have t2t.
I support deprecating all t-address transactions at the wallet level right now.
I would only support removing t2t from the protocol if we are sure that it is not something that users currently are using because z-addresses are too hard to use or don’t have the same functionality.
This is worth researching. In particular we would need to ask mining pools, exchanges, and developers building on Zcash if they would be OK with removing t2t. I suspect some of them will say there is some friction that would cause. If so, then we need to remove that friction so they have no longer want to use t2t txs.
One thing that comes to mind are the Bitcoin style OPcodes that I think only work with t2t transactions? Is anyone using these right now or planing to? Can that functionality be easily replicated with z-addresses?
3 Likes
Awesome! Really happy that you’re w/ me & others who agree on the principle.
2 Likes
I think the principle here is the one of least resistance. Exchanges are going to have to be spoon fed z addys. why change when they make money of t. It is only us at the moment that care. the rest of the world will and we need to make sure privacy is still obtainable.
The roadblock is doing extra work for little to no benefit at the exchange level. If exchanges dont support z-addys, why would I as a newbie even think about them?
And it is not a roadblock, its a misunderstanding between different people. for example no exchange should share their back office software with anyone but their hsm provider. zcash should work with the hsm provider. its has to be air gapped like this for insurance. - it will lead to better results too.
There is effectively one HSM provider in the world. they got anti trusted into two. So the solution is to offer zcash pcie cards or zcash based hsm’s that “zcash up everything inside” HSM’s have trusted setups, they need to talk to each other, business rules, etc.
This then makes supporting zcash z addys COTS.
Im writing a proposal to try to get to the bottom of this. So far two of the hsm manufacturers have shown a very positive response and both have been following zcash for quite some time.
We need COTS that supports z addys.
Ive done a lot of background research on this already and think it is not only obtainable but I really feel it is the way forward.
We need to find out what modules are being used out there first though.
1 Like
t-address incoming support is not an added value feature, it is a privacy leak
Zecwallet is the only wallet that can be used as a bridge between 99% of exchanges and Z-addresses thanks to this feature. Let’s remove it and none of us will be able to use Z-addresses at all.
2 Likes
If we drop T addresses, many exchanges will start supporting Z addresses and Zcash usage for its intended purpose will increase.
Zcash network would be far better off if we lost all wallets that offered T address support and half the exchanges. More shielded support would follow and our community would become stronger without the transparent transactions that dominate the network today
1 Like
Great news! Which exchanges have you already discussed this with?
I suggest we talk about facts, not “if”
Without T-address management, we don’t have the ability to manage Z-addresses today. It’s a fact!
everything to do about t-addr is first class in Zcash
I understand the sentiment behind this but I believe this is a mischaracterization. For example, the ECC mobile SDKs are not yet capable of t2t transactions and never have been. The wallets that stem from them, like Nighthawk and Unstoppable don’t even provide the ability to view your t-address. We didn’t even implement z2t until long after z2z was fully functional. Similarly, t-addrs are barely supported by lightwalletd–the server upon which most light clients rely. I’ve been developing wallets at ECC for over 2 years and I’m just now starting to get around to t-addr things and, even then, it’s still not t2t. I don’t even know how to construct a t2t transaction.
There are many other examples of t-addrs getting less time and energy. Overall, I do not think it is accurate to imply that “everything to do about t-addr is first class in Zcash.”
4 Likes
As you know, Zcash is not Monero. Zkps are superior but take computational power that obfuscation does not, and that has implications for the velocity of 3rd party adoption.
This is one of the most important points and it gets overlooked a lot. How many people sounding alarms about t-addrs or imagining what exchanges can/cannot do have actually built software systems at scale? Of those, how many have done this while navigating international regulations? What about while staffing a developer organization as large as Coinbase with competing priorities and resource constraints?
I’m not being flippant or judgemental, I’m just suggesting that the real world constraints are the primary problem. What sounds good in theory is often not best in practice when all things are considered.
Demanding a unilateral stance seems like an oversimplification of this incredibly complex and evolving issue.
Do I agree that we should keep transparent transactions forever? That depends.
Do I agree that we should deprecate transparent transactions? That depends.
Is this argument the best use of our collective energy right now? Certainly not.
4 Likes
Depends on? (asking for your opinion).
Every exchange is going to have some issue: headcount, prioritization, compliance, etc. That shouldn’t be the reason to support t-address in the long term.
If we keep t-addr deprecation aside, question we need ask, does ECC & ZF have bandwidth to check real volume exchanges for z-addr support (Kraken, Coinbase, Binance etc)
It is a simple consensus question do we believe in deprecation of transparent transactions? YES or NO. when? how? what? are important but thar’s secondary.
Let’s make zcash mandatory default and remove t forever
A proper governance tool inbuilt of zcash
Donation option built in zcash to send along with donation as optional button which could be little as 0.0001 zec
And further implementation of pos would make it easier as funding does happen through donation instead
Either zcash to be asic resistant or just be pos
Zcash z address as default with view keys option
Halo 2
Simply no.
There are many in community who drag zcash to very low level of development and get it in a loop where the project goes no where
This misses the point. You are right, we can’t get rid of taddrs now and its not clear when we should.
But, we all need clarity of purpose and a shared mission. Zcash exists because I and others thought Bitcoins transparent transactions are a bad idea. Privacy is also the one thing that differentiates Zcash from other currencies and it looks really bad when we cannot say: “we’d like to be fully private”. It’s a loser in the market place and the market place for ideas.
You are right, this argument is a waste of time: so why are we arguing? The only legitimate reason i can come up with to opposing a statement about guiding principles is there is a fear that if we agree our goal should be removing t2t transactions (and allowing optional transparency via other mechanisms), then there would be some mob rule and we’d remove them too soon. But does that make any sense given how things have gone in Zcash so far? Is it remotely plausible that will happen given the current governance mechanisms?
Why are we arguing. It’s better to just say we have a shared purpose, agree on the goal, and move on.
2 Likes