I’d not actually seen that 2018 tweet before now, but I agree with it: we should ban unshielded transactions. The question is only when.
(BTW, ECC staff are perfectly allowed to have different opinions on this topic. It’s a complex topic, and the management structure of ECC is pretty flat compared to some companies.)
It doesn’t even have to be a timeline with a fixed date. It is the intent (to execute) that matters, makes everyone prepared (which includes developer activity). Timeline can be visited at a later point through community discussion.
It’s how the released version of the wallet works, but there is currently efforts to add t addr support though if this covers t2t I do not know. The other thing the wallet lacks, which it could easily have, is a means to nudge people away from t addr usage. This was rejected because it would make taddrs a second class citizen. Which … yes it would and yes it should.
I’ve heard there was substantial UX work for taddrs … which seems not necessary unless you were planning otherwise. And strong push back against nudging people away for t addr usage.
Ok, then t2z work was not what I was referring to. What i was referring to was post launch (edit: i.e. launch of the wallet SDK a month or two ago). People were pulled off of zaddr UX/dev to work on taddr UX.
It seemed inconsistent with merely supporting something like auto-shielding and much much more consistent with Nathan’s public comments than increased transparent transactions would be ok. Obviously, I don’t know for sure and am not privy to the decisions because none of this is transparent or public.
Not sure what you’re referring to. There was barely any work on UX at all! (ZcashCo/ECC intentionally decided not to do its own wallet at that time, based on arguments that I disagreed with and argued strongly against.)
Sorry, UX may imply something more refined than I meant. There’s a basic set of screens in the SDK. Transaction creation, history, etc. Those are part of it, they weren’t just done by nighthawk. This is why ECC employees Geffen, a designer. There’s a bunch of dev-side logic that goes into supporting a wallet SDK too that isn’t just a create transaction API. ECC didn’t just ship a bunch of API calls, they shipped effectively a demo app.
Yes. But then you referred to “post-launch”, which is what confused me. Technically “post-launch” applies to any time after October 2016, so that’s not very specific, but it sounded as though you were referring to decisions long before the development of the reference wallet.
I don’t want to minimize the work done by the wallet team on this, but t-address support in those SDKs (that is, for transfers, not holding money in t-addresses) wasn’t a large amount of work compared to the rest of the light wallet infrastructure. It made sense to do it and it didn’t significantly delay or interfere with the open-sourcing of the SDKs.
Ah, apologies for the confusion. I meant post release of the wallet SDK when i said launched. You’re talking about work done before the SDK was public. I agree with you completely on that being necessary and appropriate.
I’m telling you that, surprisingly, people are being diverted away from z addr features to work on more t addr support above and beyond what was in the SDK when it shipped. As in they are actively spending time on it now.