Sean Bowe @ebfull

We're very grateful that OpenAI has provided our teams with assistance to protect Zcash users from these nasty bugs as well. (We also have no new issues to report!)

zooko🛡🦓🦓🦓 ⓩ @zooko

2 weeks ago

Thanks, Anthropic, for helping protect Zcash users. At Shielded Labs’s request, they ran a security audit of Zcash with Mythos. It did not find any more serious bugs in the Zcash protocol. Shielded Labs and others are continuing security hardening work. Stay tuned for updates.

91 287 2K 630K 148

x.com/i/article/2066…

Before, usage of ZKP's required trust in: - Cryptography assumptions (ECDLP is sound, hashes are collision resistant, etc) - Developers to make a sound design for what they want to prove. - Careful implementation of a circuit satisfying the design Now this should compress to: - Cryptography assumptions - A correct definition of the needed security properties. Automated proof checking will prove that your real ZKP verifier + circuit combo then satisfy the above two.

@omw_to_the_moon Users can migrate in one shot, or gradually in a more private way, or do whatever they want from the protocol's perspective. It's the wallet that decides or offers the user a choice. What the wallet can't do is make payments in the old pool without going through the turnstile.

Quick update on the last ~48 hours of Zcash Ironwood! 1. Protocol devs from across all the orgs met twice to discuss specification and implementation progress. Agreement on a couple additional changes: disabling Orchard pool bundles in coinbases, anchors as auth data for migration UX with hardware wallets, and the order that ZIPs and specs will be handled. 2. Ironwood circuit and ZIP 2005 integration drafts are going through the review process. @ValarGroup has already spun up testnets and his team has done a wonderful job scoping out and implementing some of the wallet-facing changes. We are beginning an Ironwood upgrade book for eventual consumption by auditors, wallets, protocol developers, etc.. 3. Formal verification work on Ironwood continues. A collection of different individuals who either have or will continue to work on formalization efforts will be meeting tomorrow where we'll settle on the specific strategy for getting the Ironwood SNARK formally verified. I'm hosting this and will post minutes and details after. Efforts from teams will be ideally combined where useful, existing approaches and progress unified and we'll figure out the easiest path for the next couple weeks. I've paused my own work on this to do Ironwood circuit stuff, but I'll be resuming on that tomorrow. These are the big pieces, there are also some major security auditing tasks taking place in the background -- at least three major firms are auditing Orchard currently, and multiple new AI auditing suites are hammering the codebases to ensure nothing else critical is sitting around anywhere. So far so good! Really proud of how much progress is being made every hour on this by all five of our major teams/orgs and our supporters inside and outside the community. Also love the general wartime vibe shift. Let's go!

Sean Bowe @ebfull

2 weeks ago

UPDATE: The various orgs and protocol developers mentioned have agreed on the specific consensus rule changes for Ironwood, after settling the finer details. Here's a summary: 1. Ironwood introduces a new pool using the Orchard protocol, just like the existing pool. 2. The

19 71 306 152K 47

@MicahZoltu Appreciate the feedback. Our review processes for network upgrades are actually very slow and deliberate... Despite these changes being relatively straightforward and narrowly tailored to our goals, they will still undergo over a month of auditing and analysis.

I got asked about Arc's "privacy" proposal: 1)its not private and I hope they don't say it is. A private zone is a TEE, ran by an admin, who sees and controls everything. 2) These ideas aren't knew, but a promising integration of them is great. 3) We can get better privacy.

Sergey Gorbunov @sergey_nog

2 weeks ago

Since we started the project, I’ve been telling the @circle team that this will be the last privacy solution in blockchain space. And we delivered. What we have built is not just privacy-preserving smart contracts. Instead, it's a paradigm shift in how blockchains,

3 19 114 54K 93

Why is a call to exit the pools necessary? Telling people honestly what happened is what that article did. I don't care if people exit the shielded pool, but I'm not going to pretend it's the right option for everyone. It harms privacy by exposing shielded user balances. The urgent intervention we're putting together is to make it possible for people to exit the pool for another one, in the process generating the same exact evidence of counterfeiting. Why would we be doing that if we're engaging in some kind of cover up like you suggest? We genuinely don't believe there was counterfeiting. If there was, the pool would have been drained by now and a call to exit the shielded pool would be moot as a method to pressure the hypothetical counterfeiter to exit themself. No profit-maximizing counterfeiter could know how many other people exploited it, so they would have no incentive to hold off. The "harm minimization" you're recommending would thus hurt many of our users instead. People should just do the thing they could do all along: buy and sell the ZEC based on their value assessments and risk calculations. > exploit or no exploit, last person out is screwed to be clear: if there's no exploit, the last person out gets all their ZEC.

@satorinakamoto @colludingnode @lucidzk "even more damning" "there is a clear answer" "this is rhetorical" Maybe it's more complicated and there's a chance you're wrong or haven't thought it through? No room in your framework for this? "i'm not even interested in arguing" 👍

@mkuegi Restoring confidence in the supply cap and scarcity of ZEC is really important for our project and our social contract. Many of our normal governance functions (like coinholder voting) are affected by this situation so it must be resolved before we can proceed with anything else.

UPDATE: The various orgs and protocol developers mentioned have agreed on the specific consensus rule changes for Ironwood, after settling the finer details. Here's a summary: 1. Ironwood introduces a new pool using the Orchard protocol, just like the existing pool. 2. The circuit for the Orchard protocol—which applies to both the existing Orchard pool and the new Ironwood pool—will have a flag that consensus rules can toggle. This flag disables payments to *other* users within that pool, while maintaining the ability to create change notes. (This enables a privacy safeguard.) 3. The old Orchard pool will have this flag enabled after the network upgrade, and payments to the old pool will also be disabled by constraining valueBalance. 4. Because payments are disabled on the old pool, wallets must send new payments to Orchard receivers (inside existing unified addresses) via the new pool, and they should also migrate funds away from the old pool. This combination enforces a bound on the circulating supply of ZEC through the use of the existing turnstile mechanism; the amount of ZEC that anyone can transact with is no more than the amount that is supposed to exist. Meanwhile, users' wallets can migrate funds to protect them from risk, which also gradually provides evidence that counterfeiting never took place. Now that we have this decided, we'll collectively move on to the implementations, specifications, and ecosystem support/outreach. (We also have many different auditing and formal verification efforts taking place behind the scenes to provide assurance about the circuit correctness. More on that soon!)

Project Tachyon @TachyonZcash

3 weeks ago

Together with @zodl_co, @ZcashFoundation, @ValarGroup and @ShieldedLabs, we're advocating for a network upgrade that would make ZEC's circulating supply auditable, providing additional reassurance that no counterfeiting occurred in the Orchard pool before this week's bugfix.

69 102 505 182K 49

The complexity added to the circuit is the addition of new constraints rather than the modification of existing ones, so this is easier to justify and analyze for soundness purposes. We have to balance it against the privacy risk during migration. Note that we are definitely going to have a formal analysis of the Orchard circuit soon, so the risk here is mostly in delaying that analysis. But since the change is insignificant, I find this unlikely. Forcing users to leave Orchard (through the turnstile) in order to make payments is necessary, or else there is no coherent definition of a supply cap. If people can trade and value ZEC within the Orchard pool as though nothing changed, then people can theoretically transact with more funds than are supposed to exist -- without the turnstile being able to identify it. There are some philosophical questions here about subjective interpretations of value, what custody really means at a deeper level, the properties of soundness in financial systems, the technical contradictions of cryptographic assurance... and I can't wait to share my own thoughts on them all. :P

There's open community discussion now! :) Votes make sense for controversial things and normal situations. This is a limited, urgent intervention that is being put together by consensus of all the orgs and protocol designers. Fortunately, there are other ways to obtain evidence that our proposal is unacceptable to the community. There'd be no way to achieve this if there were pushback from just one notable protocol developer anywhere in our orgs, which is why even this straightforward agreement on the consensus rule changes took a couple days.

@mkuegi The action circuit in Orchard will require spend and output commitments to have the same (g_d, pk_d) if the flag is enabled. If the flag is disabled the constraint is not enforced and it matches the normal behavior.

@EurasianViking No, the new pool is being introduced in the upcoming network upgrade. Once that happens, if you shield your transparent funds it cannot go into the old pool.

@mert @zkDragon @ebfull Dev is the goat

bug != exploit with that out of the way, the data around the shielded pool movements (or lack of movements) is extremely bullish long term invest in religious zealots working on revolutionary tech is a solid principle / see druck on why he changed his mind on bitcoin:

a @adidogCEO

2 weeks ago

the activity around the $ZEC pool the exploit was found in is the wildest data i've seen for a situation like this the only thing that would explain this behavior is that the majority of the tokens in this pool is highly concentrated to a small set of users and they don't want

15 2 28 15K 8

Circuit code is just an elaborate way to define the polynomials the verifier uses to check the proof, which may or may not be embedded in a verifying key. But formal verification of SNARK *soundness* specifically does not need to trust that the circuit code was translated correctly. We just need to extract constraints on the witness implied by the protocol and verifier polynomials. Then, we prove any satisfying low-level witness yields a high-level witness. R1CS makes this process easier but the arithmetization itself doesn't matter for the proof. I think this is really important, because halo2's circuit code and arithmetization are complicated. If a soundness proof of Orchard's SNARK had to model halo2 circuit code in Lean and trust that translation, it would actually inject an unnecessary/convoluted layer between the proof and the real SNARK. Instead, we can work backward from the SNARK description to a mathematically equivalent constraint system sufficient for the proof. (In practice, we actually do both, simply because it's easier to write the proof (currently) with the circuit description's help, but we don't need to rely on the translation in the end. It can be discarded once you've circled back to the IOP or whatever.) Don't get me wrong though, R1CS makes many other things simpler and safer as well, and things like it should be preferred when possible (as I have advocated for.)

If you think you had a dizzying week as a Zcasher, imagine being a Bitcoiner: apparently, someone made an unusual UTXO that could technically be in violation of a future controversial BIP, so the forces of good and evil are debating the philosophy of softforks for the 68th time.

Fear of shielded ledgers due to complexity, despite breakthroughs in formal verification, is doomer / decel / techno-pessimist behavior.

mert @mert

3 weeks ago

@udiWertheimer @TachyonZcash @zodl_co @ZcashFoundation @ValarGroup @ShieldedLabs lol im afraid youve become possessed by an ai datacenter doomer / bernie sanders hybrid I told you three times now that tachyon pool will be *formally verified* and *mathematically sound*. Ai might help discover vulnerabilities in software but it turns out it ALSO helps you

2 2 52 19K 5