Because ICP can’t enforce operations without a representation on BTC. Its multisig is that representation. It could act as an oracle, yet the oracle address would need at least some custody of the funds.
If you create a random address for a contract, it can’t handle those funds because it doesn’t know the private key. If you create an address, you can handle its funds, because you know it. If you publish that private key to the network for the SC to use, or if the network as a whole decides on one, then everyone knows the private key. The only solution is for everyone relevannt to only know part.
This integration is possible because the Internet Computer protocol will be able to securely generate the ECDSA signatures involved in bitcoin transactions on behalf of smart contracts, using chain key cryptography (after the Taproot Bitcoin upgrade in November, Schnorr signatures will also be created).
I really do wonder if the real opportunity is for Zcash to stop re-creating all of these things being built by larger teams (dexes, shielded assets, etc) and focus on the utility of zk-snarks and providing it as a service. At the same time, it seems like Eli Ben-Sasson already beat us to the punch (et al Starkware and dYdX) with that business model:
It will be interesting to see how the partnership with Filecoin and ETH manifests…
The Thorchain integration would be exactly that. Joining with an established project instead of recreating it. As for ZK-Snarks, Halo 2 is the next evolution of them and removes the trusted setup. As for providing them as a service, wouldn’t that be via shielded assets, the exact thing you just wondered if we shouldn’t do? Or would you mind expanding a bit for clarity? Would love to hear your thoughts on this.
Honestly, just kind of freestyling here, but I’ll try to explain what I mean.
Aside from the ECC (and maybe the Zcash foundation?) I don’t think anyone really knows what shielded assets would look like until they are developed. What if all this time and energy is spent building them and no one uses them?
I guess my simplified version is that Zcash evolves into providing zk-snarks as a service (ZKaaS) like Starkware is doing, which any blockchain can plug into (ancillary grants such as: Elemental ZEC – UI Component Kit and Payment Processor would be beneficial for integrations), instead of trying to be an alternative to Bitcoin, ETH, etc. Then ZEC becomes more of a utility token rather than a payment coin upon the move to PoS (if that happens which it looks likely) and any chain that integrates said ZKaaS tech, must use this token for transactions (akin to gwei) and it goes into some type of community fund, which the rewards are disbursed to people holding it (not sure about tokenomics here, just spitballing).
In the current proposal, sure THORchain integrates Zcash, but that doesn’t necessarily mean that the value of Zcash will increase (but this is a large thread and I May have missed where someone already addressed this).
Like everyone knows that zk-snarks are amazing and should be integrated into current L1s… just seems like maybe Zcash needs to think about being an L2 instead.
Got it. That would require ZCash to become its own multisig chain, presumably, which would then host coins. It’d be a very drastic departure yet would offer value, which I especially believe given the problems with ZSAs. They can’t be used in any DApps as ZCash doesn’t have DApps. They can’t easily be used for governance because you’d have to prove their nullifier isn’t spent and reveal their quantity, which would need to hold true from time of vote to election close. They can be used as shielded USD and so on, but only with a centralized bridge, offering its own questionable aspects.
Maybe we should make a thread for ICP/Cosmos/ZCash becoming such a network? I’m not sure if that would be 2 or 3 threads in total, and hanh may want to wait on the ICP thread. As for an independent Cosmos thread, @tm3k was the one who expressed interest in ZCash being available via IBC. It also turns out there’s already a thread discussing it so some degree, thanks to a news announcement where ZFND announced a 2-way pegged chain which would make ZCash accessible to Cosmos chains AND offer shielding to Cosmos coins. It doesn’t appear to have gone anywhere though…
Good points. I think this forum (not the fault of ECC or whoever set it up) does an awful job of organizing discussion. Theres a lot of siloed information/good ideas that somehow need to be merged. Longing for the days of vBulletin.
In any case if there is a new thread, I’m happy to participate in that in an effort to prevent myself from muddying this discussion even further.
Some cryptographers will probably argue that calling chain key cryptography a multisig system is an oversimplification…
In any case, the point is that there wouldn’t be a need for an external group of BTC key holders that sign transactions on behalf of the ICP smart contract.
The security of the DEX is the result of ICP consensus mechanism.
Well, it’s primarily BLS, which is an aggregate key system, not a multisig, as used for its role in a consensus mechanism. Ignoring that consensus mechanism would be an oversimplification. That said, for its usage in relation to Bitcoin, it is a multisig via threshold signatures (Threshold ECDSA Signatures - Roadmap - Internet Computer Developer Forum). It’s far more complicated than the traditional idea of a multisig thanks to being m of n, not to mention unified instead of relying on a SC/Script, but that doesn’t change the fact it’s multiple parties in a signature.
Except that these parties are what makes ICP run. Chain cryptography is part of the consensus.
A smart contract does not need to have a private key to generate BTC signatures. Yes, it is similar to a threshold signature but it is not the same as Thorchain where external nodes act as signing agents. From the perspective of a user, the security model is like UniSwap or PancakeSwap. I “just” need to trust ICP and the smart contract code, not the honesty of an individual or a small group of people.
I honestly don’t know what point you are trying to make anymore. Is it that the system is multisig like you said?
I get that. I do know. I’m not trying to call it insecure. I’m identifying its technical properties.
Uhhhhh… a SC does need a private key mapped to it. But yes, it cannot have a private key. It is a threshold signature protocol in use for the BTC private key. It is the same as Thorchain because Thorchain nodes who hold funds also produce blocks on their chain. You do just need to trust ICP and SC code, and I trust both of them in this case (well, assuming the SC code is valid). Technically, this is the same as Thorchain though.
I was never trying to call ICP bad. I was identifying how it technically worked and how that system can have problems. While ICP would presumably have vastly more nodes with much more at stake, and they wouldn’t squabble over the ZEC integration’s day to day yet rather ICP’s itself, reducing the amount of concern we face for the integrity of ZEC operations, I wanted to note the technical systems. That’s all.
I understand. Though I think the distinction is very important. After all, a smart contract is also “just” a program. But when a program runs on the ETH network, we know that its validity is enforced by the nodes.
I’d like to point out that even though at some level there are similarities between Thorchain and ICP, these solutions differ significantly.
Contrary to Thorchain where the trust lies in the honesty of the team and a few signers, the security of a smart contract on ICP is intrinsic to its protocol.
I think you agree with that but I think it’s important to spell it out in case someone does not read the entire thread.
Also, I’m not vouching for ICP at all. But at least, on paper, in theory, it seems secure.
Yeah ICP is busy working on direct Bitcoin integration at the moment. I would love it if zcash integrates with them. They seems to have a solid team. Also if they integrate bitcoin, zcash might be a similar process as well. However there is currently no dex but would be great as a wallet option for now. The ecosystem is showing massive growth too.
As one other note, I’d honestly want to drop discussion of shielded ZEC. Thorchain, as a custodial solution, must share their view keys from auditability. Unless the discussion is solely “It should be shielded to be future proof”, when shielded TXs will drastically change soon anyways with Orchard, and will likely change yet again before plain TXs are dropped… It won’t offer any benefits to usage, will increase CPU load on their end, and cost us more money to fund.
There is one angle, I guess, where it’s not shielded to be future proof but shielded to be more future proof? Where incremental changes to the shielded code to match hard forks will be cheaper than writing both plain code now, maintaining that, and later adding shielded code? Especially since I believe the next hard fork will also drastically change the TX format in general, notably with ID derivation?
I guess it’s still worth discussing based on the potential for the removal of plain TXs, which I do personally encourage. When that day comes, services like Thorchain would just publish their view keys to prove auditability. The question is if we want to support that plunge now (which could also just help by showing industry adoptance of the tech along with how it can still encourage transparency/compliance), and can get amicable rates.
As one other note, I’d like to remind everyone the above proposal solely said they’d look into shielded TXs, yet only offers plain TXs. Therefore, I truly do just want to drop discussion of it for the reasons above. I’m currently not providing any feedback on the proposal itself. Just feedback on the feedback of the proposal, and unsure feedback at that.
Here are some updates from the Thorchain community, they seem supercharged to bring permission-less native L1 swaps for the top cryptocurrencies & stable/dollar pegged coins! ETH chain was brought back online on Onct 21 for trading and the network has been stable since then.
Thanks to @tm3k who ran a ZEC on Thorchain sentiment check and received massive engagement on Twitter.
Thorchain devs have started work on a mobile wallet with the aim of becoming the RobinHood of Defi: https://twitter.com/ThorWallet
I do hear that LPs have yet to be fully paid back, so I’d like to wait a bit longer, and one of those tweets discuss supply centralization which is a fascinating discussion. The team has 150m tokens allocated to them. Their mainnet only has 108 million tokens currently on it. This should be seen as a major concern for its long term viability, as the total amount of RUNE used in liquidity pools is roughly ~10m. They could take half the supply multiples time over for every pool, feasibly emptying the protocol. There are safe guards against such a mass exodus, for now at least, but I don’t appreciate how their Twitter glossed over that.
They also refer to a 180m RUNE wallet which… doesn’t exist. Their mainnet supply is less than that and no BNB wallet has that much. The ERC20 supply also isn’t anywhere close to that. The only explanation is a USD valuation when it actually has ~18m RUNE, which is one digit off from the official quoted reserves number of 28mil. That’s ~28% of the current mainnet network though, not 36%. Their Twitter is really unreliable for information…
I have a friend who went over these numbers a lot recently so I tried to help out. https://thornode.thorchain.info/cosmos/bank/v1beta1/supply should be the current supply numbers which shows their mainnet doesn’t have anywhere near that? And then I also heard 10m RUNE exist which shouldn’t (violating the fixed total supply with no current explanation) yet I’d have to double check that.
That said, this all says “Thorchain is bad”, not “ZCash + Thorchain is bad”. In that regard, it may not be the best place to have these discussions. I solely wanted to address the above post which says “Thorchain is great” while quoting tweets which have spotty information, not to mention a claim there’s “no counter party risk” and “no fees”. Thorchain does explicitly have fees for its transactions, which include swaps, and there is most certainly a counter party risk of its multisig as they have demonstrated multiple times (notably by centralizing all funds into the team and requiring a Google form for the chance of getting your funds back). I’d hope for this discussion to remain factual instead of based on hype.
@aiyadt Mind if I ask if you had any further thoughts on shielded ZEC? I wrote a half hearted commentary above and would appreciate your feedback on its value/feasibility. I know you said unified addresses will break it, yet that’ll still need new address handling code and transparent TXs will also break shortly unless I’m mistaken about the new TX ID system. Then I know zooko considered shielded receiving support not needed as well. That does leave sending to shielded addresses as a valuable discussion topic? Just trying to organize into a potential ‘summary’.
I’m also curious if you can provide the specific reasons the existing BTC code can’t be used, as I know that was declared yet I don’t believe it was answered beyond “similar… but not the same” and “there is no re-useable code” despite all currently supported BTC forks being almost entirely identical with PRs which mirror all changes, as hanh noted. Like sure, the address formats will be distinct, yet their BTC code doesn’t rely on SegWit so I don’t see how their would be any major changes. I do acknowledge heavy testing is required yet that doesn’t resolve the development side of your claims.
If it is about how transactions are evolving divergently on ZCash, and you wanting to future proof now by using the standing Rust ZCash libraries, I do agree that could be valuable if shielded sends are also handled properly. Hopefully that’d only change TX construction though, not observation and reporting, meaning half to the majority of the BTC code would still be usable.
Hey Luke, I’m checking in to the forums since my last post, so allow me to reply to several comments you have made.
Native Swaps on Thorchain’s Decentralized Network:
Thanks for clarifying your perspective of atomic swaps as a definition for using the word native, but the primary notion of the word “native” in Thorchain network’s context is the fact that users get to deposit, withdraw, trade native Zcash coin and not a centralized token representing ZEC like WZEC, RenZEC as discussed earlier in this thread:
“a new DEX could be built instead”
There are handful of DEX that have achieved the liquidity required to be functional in the volatile crypto market. Apart from the liquidity, a DEX also needs active participants for arbitrage opportunities and returns to Liquidity Provider. Thorchain meets all the criteria and is one of the top 5 DEX’s in the ranks of dy/dx, UniSwap, etc.
If someone can “kickstart a new DEX on its own” for 250k, I would be happy to see it happen, Thorchain began with very humble beginnings in 2019 and took 2 years to architect and build out the network, community and liquidity.
Yes, Thorchain needs more projects to join them, and the respective projects also need the decentralized infra that Thorchain has built, for anyone can plug in and extend Thorchain front end within their own product like ShapeShift has.
And yes, Thorchain must be looked upon as a partner for this grant, they have provided us with direct access to their developers whose bandwidth is very limited and they have made themselves available whenever we needed them.
We will update the grant to return savings & unused cloud server billing hours at the end of the final delivery.
It has been challenging to find capable, experienced developers to commit to a 12 to possible 16 week timeline for building, testing and supporting the Zcash on Thorchain integration. The grant does not specify that we would be providing support after a successful launch, but it is presumed that any Zcash specific issues with network upgrades, V5 transactions updates, debugging issues, etc. would need to be handled by the developers post launch. Zcash community benefits by adding developers and contributors.
Now, the 2 active grants of the Nighthawk Team are Milestone 3 of Nighthawk Wallet & on-going maintenance & hosting of lightwalletd.com instances. The zcashblockexplorer.com has been well received by users and we are also working with ECC to support a test-net version of the explorer which will help test Orchard Transactions and ultimately support NU5 when the network upgrades in Jan.
Both Nighthawk Wallet & lightwalletd instances have happy users and we continue maintaining, fixing wallet bugs and improving uptime for servers. The last update for Nighthawk Wallet is posted here Nighthawk Wallet Design & Development Grant - #23 by aiyadt
We are open to share the LinkedIn profiles of the new developers working on the Zcash Thorchain grant after approval and before any Milestone payment. Zcash is not seed funding a new development company. Our primary company has been operational since 2011 and serviced several Fortune 500 clients and early Bitcoin adopters, we can share its details with ZOMG. We have recently doubled down our focus to build privacy tech, preferably using Zcash.
The dev hours and costs reflect the quote by the developers who will be working on this grant from start to finish. As shared in my last post, Thorchain network has started again and are on their way to launch the $THOR token in the first week of November. Everything has been working per their timeline as trackable here Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
And again, to reiterate, none of the developers working on Nighthawk Wallet would be developing on the Zcash Thorchain Grant proposal. So there is no point in blocking a parallel project.
The estimate of $25k worth of ZEC trading daily came from the pre-July trading numbers for LTC which has a similar trading volume on CEX & Thorchain. Multiple 25k x 365 days and you get $9M+ annual volume, which I consider to be on the lowest spectrum as with the increase in size of the Thorchain community and increase in interest in DeFi from institutional players(even Cathie Wood recently mentioned how DeFi loans and interest rates have started to make a dent in the traditional banking business), I am expecting much larger volumes for Zcash on a DEX.
And again, the swaps happening on Thorchain enable users to transact in native coins and pay the fess from the native coin too. Your definition of Thorchain not being atomic swaps does not reduce the value proposition of Thorchain.
Thanks for your critique.
There is no need to further delay this grant as we are just delaying/disenfranchising early adopters(from the world of DEX) from taking part in the growth of Zcash from here on.
The market needs a native ZEC swap functionality on a DEX with high liquidity, and large Zcash holders want a way to earn an APY on their holdings.
The opportunity cost for ZEC also needs to be considered, Monero has been eyeing native integration with Thorchain too, and since Monero is a competitor to the privacy rhetoric, it would be a good step if Zcash can reach the Thorchain community as the first privacy coin before XMR. Additionally, there are synergies between Thorchain & Zcash with Naomi recently bringing them up on Fox News I told Charles Payne to buy Bitcoin in 2015 - YouTube
There is a fund raising for Thorchain’s IDO happening on the first of November.
Shielded ZEC is a no-brainer as a store of value, but the transactions made to third parties can be made public by the third party, so it would make sense to keep things simple with T-address only support while Zcash wallets like Nighthawk allow receiving of ZEC in T-addrs and shielding them.
Please read my replies earlier the thread for how there are no reusable code in the context for Zcash tests which are required for deployment. And the fixes that are applied to every similar project applied in PRs apply to Thorchain specific code.
@ZcashGrants It has been a month since @Souptacular invited more members of the Zcash Community to comment on the updated schedule and costs. And we have had several discussions since then and the synergy has even been mentioned on Fox Business News. The user base believes Zcash integration with Thorchain is very vital for ZEC to keep up with the demands of the DeFi space.
The user base wants an answer on this initiative, can we have an answer for the grant proposal?
And if someone else would like to volunteer and finish this proposal for $80k, I am ready for a Knowledge Transfer of the work done till now because I see so much value in this integration. And as a ZEC holder, I believe in a Dev fund that can get proposals like these done.
My objection is by that definition, CEXs are also native. It’s a word which quickly loses distinction and meaning,
Full acknowledgement on the liquidity/community aspect, yet not on the tech aspect. I’d like to cite a full atomic swap tool that was built with 0 financial funding for XMR and then later applied to ZEC. It’s by no means a DEX, yet it does show the basis of one (swap technology, though obviously atomic v multisig are very distinct) can be done in a month or so by people who are passionate without financial incentive.
Thank you for clarifying you’d return excess server costs.
You still have not provided any evidence this is a multi-week timeline for building when there’s a standing BTC impl already applied to BCH, LTC, and so on. That’s my primary complaint as of right now, beyond Thorchain in general. When you then say it wouldn’t cover ZCash upgrades… This was also the primary thing I asked for in my most recent post (even though I did first ask about any further thoughts on shielded ZEC).
Thank you for the update about the Zcash Block Explorer grant. It does appear that slipped by me.
It’s not a concern of existing projects being blocked, in my opinion which honestly doesn’t matter. My concern is ZOMG putting hundreds of thousands into projects which won’t be completed or won’t be completed to the desired quality due to a lack of frame of reference/over extension on your hand. That’s why I put forth comments about establishing a track record. I do understand how milestones work and I also know your work thus far has been as expected. It’s really not my place to further comment at this time. I just wanted to explain why I said what I did when I did.
As for the timeline I suggested weeks ago, I fully acknowledge Thorchain has reopened. That doesn’t mean they’ve proven themselves. That just means they stuck around after the hack. While it does show some level of follow through on their security practices (there’s a further discussion there I rather not get into right now), it doesn’t mean this issues won’t happen again within the next month. I believe there’s value in seeing them not just come back online, yet also stay online and managing what’s going on now that they’re back.
I was not trying to reduce its value proposition by calling it non-native. I was trying to remove an element of hype as I feel like most of Thorchain is a hype based project, hence why it got so big despite so many critical issues. Your second to last post even included false claims from the founder of Shapeshift. If that isn’t the definition of backing a project with hype instead of substance, I don’t know what is. Combined with the fact it natively handling BTC makes it no different than a CEX, yet they use it as part of their DEX marketing… And while it may swap native coins, until it enables synths which would be a wrapped token form in which case they’ll be partially non-native, though I’d argue even right now they’re minting synthetic mapped assets for a few seconds at a time while swaps execute in practice, that doesn’t make the swaps native to ZEC. I still maintain native swaps is the wrong term.
I’m also trying to keep an eye on it by the few contacts I have in that space. The leading comment I’ve heard is some of it will be paid back in RUNE, not the original asset, yet obviously we’ll have to wait and see.
Them saying they have a 180m reserve wallet representing 36% of the protocol when no wallet has anywhere close to the properties (closest is the reserve wallet with 28m RUNE worth roughly 280m USD at ~25% of the protocol) has absolutely nothing to do with the THORSwap IDO. This also isn’t the only example of their Twitter making bad claims.
Here they claim to have no emergency keys. The team has been able to shut the down the chain whenever they want for a long time, if not forever. They can halt LP addition, multisig migration, trades, and specific chains (that being a more recent addition). They can also control numerous variables such as fees and timelines, including the timeline which limits how quickly funds can escape the protocol. They also have a rather explicit backdoor where all RUNE upgraded from the BNB chain is sent to them. This could theoretically enable an infinite loop where they upgrade RUNE, receive it, and upgrade it again. There’d be ~10 seconds of latency per round, optimally, letting them mint hundreds of millions in a minute or two. Combined with being able to effectively disable the rate limits on funds leaving the protocol, they could empty the pools. If that isn’t a backdoor, I don’t know what is.
They also did have the complete private key of the vault used in their previous network at one point, while the network was still operating as intended.
So it sounds like you don’t support withdrawing to shielded addresses, yet agree with Thorchain not needing to receive to shielded addresses. Thank you for re-affirming that view point.
Sorry if this is a bit hard to track, as I didn’t embed the relevant quotes. I may do so later if it’s an issue. Thank you for your long and detailed reply. I appreciate it.
