This thread will serve as a central point for forum discussions, speculations, and progress updates from the Electric Coin Company; regarding the announced partnership to integrate Zcash and Filecoin features into the Brave Browser ecosystem.
As far as we know today, there are no details about exactly what or when the deliverables for this effort will ship (presumably, via a Brave browser upgrade or extension).
Good Project!
I believe brave extensions must be approved by Google App Store?
āThe judge and an appeals court both determined Apple should allow apps to provide links to other payment options, a change that could undermine the up to 30 per cent commission that both Apple and Google collect on digital purchases made within a mobile appā
It could be really helpful for whoever in ECC is driving this project please stand up. Would be interested in understanding the required infrastructure to service the brave wallet zec services?
Great Work!!
This is a huge opportunity!
Look forward to trying out braveās wallet using zec.
this is so good!
this is one of the biggest partnerships in zcash history. no doubt iām super excited about this one 
this is basically the Zcash on metamask that everyone has tried to do.
I am curious as to how the Brave team is so confident that shielded support is coming this summer, when the attempt from Zephyr stumbled into pretty big technical challenges. Are the Brave devs just better software engineers, or did they take a fundamentally different approach? Are they going to do any of the stuff @hanh mentioned?
Never bet against Brendan Eich. He will personally implement it in one weekend, if necessary.
At a glance, a browser plugin is much more limited in a sandbox compared to having access to the full browser stack all the way to the OS. I would assume that brave shielded support might have to reach down into OS APIs that are far off-limits to a mear plugin. I havenāt looked at it closely and just guessing. But, a huge roadblock to a pure client/browser/plugin is that several big dependencies donāt support a WASM target making a ābrowser walletā - in the sense of a pure javascript client implementation - extremely challenging. Access to the underlying OS would make it more like a desktop/mobile wallet with a UI in the browser.
They are doing it in c++ directly in the browser source code using interop with rust. It is very different than being a browser extension like other people mentioned.
However, the biggest unknown imo is about the scalability of the network. If we see a significant increase of usage of shielded transactions, it will be āthe return of the spamā. If there are little increase of usage, well, it would be a bit disappointing.
I guess we want an increase but not too much 
And marketing, education, advertising, creating videos is important for what reason when the scalability of the network is uncertain? Anyone who uses the wallets can see there is major problems when sync times are so slow. I have experienced this many times when it takes many hours to sync. It seems like there is just so many problems that need to be fixed and the priorities are not aligned with making ZEC a store of value or trustworthy. marketing, eduction, advertising, videos does not create trustā>They can actually can expedite the loss of trust when things dont work as expected.
Are these theoretical limits correct? What would the practical limits be?
Could the blockchain do 100,000 orchard TXs a day? Did the spam attack essentially simulate how 250,000 TXs a day would behave or would more ānormalā orchard TXs behave differently from a scaling perspective?
Are there any relatively low-hanging fruit improvements that could be made in the short-term?
Zip 317 is currently the only method of prevention. It was the ECCs main focus for a long time.
Iām not sure if the attack methods ever truly reflected what just normal swamp usage would look like but its the best weāve got to go on, probably not too far off; the chain grew a lot very quickly, data traffic between nodes increased a lot every single day, slower computers bogged down. If the theoretical maximum is over 250k per day, then it seems like a 100k is well within reach.
id like to see a test day with 100k transactions. is that 1000MB of blocks per day? how the network would handle it. how much was the max transactions when the āsandblastingā happened? also how would the network react with the latest updates?
Well, the number of transactions is relative to the number of inputs/outputs that transactions have. Some of the Spam transactions in the bloat phase of the attack were very, very large and had over 1000 actions. Divide that into 500 transactions with 2 actions and thatās still 1/5 of the theoretical maximum per block (plus assuming all paying the proper fee). I donāt have much intuition on that but I would assume that the computational work would scale pretty much relatively as well. Maybe differences in the computational routines and stuff but Iām thinking theyāre probably gonna use ABOUT the same amount of electricity and bandwidth.