@fivelittleducks Pretty sure that everything I’ve written in this thread specifically does treat the possibility of exploitation having occurred as contingent.
I guess one unknown for me is whether the ironwood proposal necessarily does put a hard cap on the qty of migrate-able ZEC in place. That’s what I’m reading between the lines in @zooko’s post (how else is there a hard and immediate guarantee of total ZEC quantity?) and I am arguing against that if it’s the case because if you gate the migration a priori, then you are creating arbitrary winners and losers a priori and in a situation like this one, that seems ethically wrong to me.
Ethical considerations notwithstanding, a posteriori is definitely in play here and should be the default. Conclusions made strictly from evidence and observation are called for, and no conclusions can be drawn without taking action which forces the exposure of theoretical counterfeit ZEC in the absence of an alternative supply verification solution. While arbitrary winners and losers may emerge, no definitive outcome is observable without forcing the issue.
I’m actively looking for errors in this logic. Help me find some.
I didn’t read the rest of the message after this. If these are the two interpretations you can see, then I guess we’re not going be able to help each other understand things better.
If you really didn’t read it, I think you should. You might want to at least read the next sentence which starts with “I also don’t know what I don’t know and am curious what that is…” which is meant to acknowledge that there could be other interpretations that I can’t see.
Yeah, you had good points there but you wrote emotionally the first bit and now it’s standing in the way of your intended outcome. Done that way too many times myself, it’s a worthwhile lesson!
@zooko I read the message and I come from a similar background. The TLDR is that we seem to be handwaving the possibility of an exploit - if it was the case that infinite genuine looking ZEC has been minted there seems to be only 2 possible things to do: rush to exit the pool (100% for those that make it, -100% for everyone else) or ratio the loss against the whole pool (if a big enough issuance happened, effective -100% for everyone).
Above is his point. Mine may be a bit more… dramatic I think. I’m looking at this with a binary outcome. I think any confirmed additional coins >0 would be long term irreparable.
This is also what confused me a bit about why Orchard V2 (aka Ironwood) was effectively any different from the status quo, outside of the obvious formal verification, and any other improvements/findings that come with it. Maybe not allowing trade in the old pool is what differentiates it, but doesn’t seem as important if no services take orchard V1 notes (you’d be silly to if V2 existed).
I totally agree with the upgrade regardless, but feels like we learn nothing new about the exploit, unless it was actually exploited and the attacker beats everyone out of the pool - so I guess this forces their hand…that’s good for everyone sooner than later.
Hope Zooko will still read it, though he’s rightful to feel attacked. I read it and felt a little burn there too. Zooko had good intentions and chooses his words wisely, but maybe don’t come overly clearly in written form. Would love to listen to a longer form podcast on this exact debate/subject!
I believe this vulnerability hasn’t been exploited. I believe it’s a very difficult vulnerability to exploit, and a hacker would focus on projects with very high values instead of Zcash, which hasn’t yet reached a value as high as Bitcoin. Speaking for myself, if I was scared and wanted to migrate pools as quickly as possible, imagine how other, newer users feel? In my view, it will be a real race to switch pools. Furthermore, if it’s proven that the vulnerability was exploited, many users will lose confidence in the project, while many others will be desperate if they can’t migrate pools in time to avoid losing their Zcash. There’s also the issue of fees, which can become expensive when many people decide to switch pools at the same time. There could be a maximum fee limit to avoid penalizing those who want to migrate pools, preferably a free fee only for migration so as not to penalize anyone in this process.
There’s a lot of good questions in this thread. Please see our latest post attempting to clarify those questions and ask (I guess in reply to that post) any more questions you have.
That is the behaviour specified in ZIP 209, yes. It’s specified that way because it’s the only thing that is feasibly implementable in the consensus rules.
That’s up to the wallet! In my humble opinion, this is the sort of thing that the wallet ought to do automatically for the user, but on the other hand maybe some users prefer manual control.
Vizor Wallet and ValarGroup have already demonstrated the automated method on an Ironwood testnet!
