Add flake rendering outputs#5
Closed
shielded-nate wants to merge 143 commits into
Closed
Conversation
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Bumps [DeterminateSystems/nix-installer-action](https://github.com/determinatesystems/nix-installer-action) from 21 to 22. - [Release notes](https://github.com/determinatesystems/nix-installer-action/releases) - [Commits](DeterminateSystems/nix-installer-action@c5a866b...ef8a148) --- updated-dependencies: - dependency-name: DeterminateSystems/nix-installer-action dependency-version: '22' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…ents. Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Missing closing paren on the `if` condition caused the github-script step to fail to parse, so the 'Dependency check result' status was never posted. Introduced in zcash#1237. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fix syntax error in dependency check status workflow
Bumps [actions/github-script](https://github.com/actions/github-script) from 8 to 9. - [Release notes](https://github.com/actions/github-script/releases) - [Commits](actions/github-script@v8...v9) --- updated-dependencies: - dependency-name: actions/github-script dependency-version: '9' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/create-github-app-token](https://github.com/actions/create-github-app-token) from 3.0.0 to 3.1.1. - [Release notes](https://github.com/actions/create-github-app-token/releases) - [Commits](actions/create-github-app-token@f8d387b...1b10c78) --- updated-dependencies: - dependency-name: actions/create-github-app-token dependency-version: 3.1.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/cache](https://github.com/actions/cache) from 5.0.4 to 5.0.5. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@6682284...27d5ce7) --- updated-dependencies: - dependency-name: actions/cache dependency-version: 5.0.5 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 4.0.0 to 5.0.0. - [Release notes](https://github.com/actions/upload-pages-artifact/releases) - [Commits](actions/upload-pages-artifact@7b1f4a7...fc324d3) --- updated-dependencies: - dependency-name: actions/upload-pages-artifact dependency-version: 5.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Fix malformed `Revision 1` hyperlink target that broke the reference from the Changelog section, convert a Markdown-style link in the Revisions list to RST syntax, remove duplicate explicit targets that conflicted with section-implicit targets, and switch single backticks (rendered as `<cite>`) to double backticks (rendered as `<code>`) for consistency. Also, update `README.rst` with the `Withdrawn` status for ZIP 316, Revision 1. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fix rendering errors in zip-0316.rst
…overability". Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
same time as, or prior to any possible activation of ZSAs. Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Recount each BLAKE2b-512 use in the Recovery circuit. The previous "9 compressions" total was wrong: H^rivk_ext, H^rivk_int, and H^ψ each take 1 compression (not 2 as claimed); H^rcm correctly takes 2. Worst-case total is 7, not 9. Also document the ℓ_qk ≤ 504 bits constraint that keeps the H^rivk_ext input qk ‖ [0x0D] ‖ ak ‖ nk within a single 128-byte BLAKE2b block. Part of zcash#1135. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace 'Case use_qsk = 0/1' with 'Case (not) use_qsk' in the Informal Security Argument, matching the boolean type of the use_qsk flag as defined in § 4.2.3 and used elsewhere in this ZIP. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
…ootnotes
In the protocol-spec edit block that lists the places where PRF^expand
is used:
- Consolidate the byte-tag enumeration: {0x0C, 0x0D, 0x82} as a single
set, noting that 0x0C and 0x0D are specified in this ZIP. Drop the
separate "(also specified in ZIP-32)" parenthetical for 0x82, since
the (dk, ovk) refactor moves that specification entirely into the
protocol spec (ZIP 32 just calls DeriveDkAndOvk^Orchard).
- Add protocol-section footnote references for orchardkeycomponents,
saplingsend, orchardsend, and saplingandorchardinband to make this
paragraph cross-referenceable.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…IP 226
Per the deployment ordering decision (ZIP 2005 deploys before any ZSA
activation), the "ZIP 226" edit block in ZIP 2005 can be applied to
ZIP 226 directly. ZIP 226's Abstract now declares that it is defined
relative to the protocol with ZIP 2005 applied; the first-byte domain
separator 0x0A for PRF^expand remains reserved by ZIP 2005 for this use.
Applied to ZIP 226:
- Abstract: add meta-baseline paragraph.
- Note Structure and Commitment: leadByte=0x03 rule for § 4.7.3
'Sending Notes (Orchard)' or § 4.8.3 'Dummy Notes (Orchard)' invoked
for an OrchardZSA note.
- Split Notes: replace the uniform-random sampling of ψ^nf with the
deterministic computation ToBase^Orchard(PRF^expand_{rseed_nf}([0x0A]
|| ρ^old)), using the first-byte domain separator 0x0A for PRF^expand
reserved by ZIP 2005.
- References: add #protocol-orchardsend; rename ZIP 2005 footnote
title to "Orchard Quantum Recoverability".
Removed from ZIP 2005:
- The "#### ZIP 226" edit block under "Edits to existing ZIPs" (now
redundant).
A broader review of whether other ZIP 226 / ZIP 227 spec updates need
re-statement relative to the post-ZIP-2005 baseline is deferred (the
Abstract paragraph provides the meta-baseline).
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ZIP 226
ZSAs (and therefore split_flag) will not deploy at the same time as
Orchard Quantum Recoverability. The split_flag-related complications
can be removed from this ZIP, with the first-byte domain separator
0x0A for PRF^expand reserved for use by split notes in ZIP 226,
keeping the path open for re-introducing split_flag later. The
removal is cleanly revertable.
Changes:
- H^{ψ,Orchard} now takes a single argument ρ and uses the hardcoded
first-byte domain separator 0x09 for PRF^expand; the split_domain
case analysis is dropped from both the protocol-spec edit block in
§ 4.7.3 'Sending Notes (Orchard)' and the Rationale section's dup.
- Add a reservation note pointing 0x0A at split notes in ZIP 226.
- Drop the four "If this proposal is to be deployed without ZSAs..."
conditionals (§ 4.7.3, § 4.8.3, § 4.20.2/4.20.3); the without-ZSAs
branch is now the only branch.
- All H^{ψ,Orchard} call sites drop the second arg (split_flag or 0).
- Recovery circuit's ψ derivation drops split_flag.
- Flow diagram: drop split_flag/rsplit nodes; rseed flows directly
to H^ψ.
- Spendability argument: drop "split_flag = false" qualifiers, drop
the adversary's split_flag/rsplit inputs, drop the "TODO split_flag
= true" stub and the "Also it is incomplete because it does not
consider split notes" caveat.
split_flag support is preserved in git history; this commit can be
reverted later (with conflict resolution) to bring it back.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Add Dev Ojha as ZIP editor
…tions/create-github-app-token-3.2.0 Bump actions/create-github-app-token from 3.1.1 to 3.2.0
…terminateSystems/nix-installer-action-22 Bump DeterminateSystems/nix-installer-action from 21 to 22
Add Tal Derei as ZIP editor
ZIP 2005: Move to Proposed (and minor cleanups)
…IP 315 Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
Link the transaction fee calculation from the index
ZIP 213: align anchor-depth rationale with ZIP 315 (3 blocks)
ZIP 416 was reserved for specifying unified address support for the zcashd wallet, but with the upcoming deprecation of `zcashd` that is no longer a useful task; instead, we need to fully document the historic schemes used for key generation by the zcashd wallet, for the purpose of future recoverability. This updates the reserved ZIP to serve that purpose.
Subsumed by ZIP 231; consensus is that a symmetric key stored in memo payload data is a simpler solution to this problem. Closes zcash#633
Remove / unreserve ZIP 318
Status changes from Reserved to Withdrawn. The ZIP was opened as a stub in PR zcash#119 but never developed further. Closes zcash#828. README.rst regenerated by makeindex.sh; the regeneration also removes stale entries for ZIP 318, whose source file was deleted in PR zcash#1282 but whose README entries had not yet been regenerated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ZIP 303: Withdraw (stub never developed beyond PR zcash#119).
Replace ambiguous '4 physical-core benchmark machine' wording with 'modern AMD laptop CPU with 4 pinned threads' in both the Security and Measured timing sections.
Today's Orchard worst case is ~436 actions / 556.53 ± 9.81 ms (was ~616 / 769.85 ± 16.18). Updates the derived ratio in the proposed worst-case prose accordingly (a little over half -> about three quarters).
Specify PostNU7PoWAveragingWindow := 51 and redefine PoWAveragingWindow as a height-dependent function (17 pre-NU7, 51 post-NU7), preserving the 1,275-second wall-clock smoothing window across the target-spacing reduction. Add a Difficulty averaging window rationale section covering motivation, simulator recovery, Blossom as a real-world reference point, and devnet variance measurements. Trim the duplicated rationale from the Effect on difficulty adjustment section. Also restore the dense-Orchard worst-case row to the earlier ~616-action / 769.85 ms figure pending verification of the re-run benchmark.
The reference is today's global worst case = Sapling at 3,174.90 ms.
- New Orchard worst case: 432.11 / 3,174.90 ≈ 14%
- New Sapling worst case: 271.51 / 3,174.90 ≈ 8.6% ("less than one tenth")
This also makes the sentence internally consistent. The previous
wording compared new-Orchard to today's-Orchard (432/770 ≈ 56%,
"a little over half") but compared new-Sapling to today's-Sapling
(272/3175 ≈ 8.6%, "less than one tenth") — two different denominators.
With "14%", both halves now reference the same denominator (today's
overall worst case).
Raises COINBASE_MATURITY from 100 to 300 and MAX_REORG_LENGTH from 99 to 299 at activation so the wall-clock coverage is preserved at ~125 min. At unchanged 25-second spacing, the existing 100-block window would shrink to ~42 minutes, less than recent multi-hour consensus splits in deployed PoW chains (e.g. Litecoin's April 2026 MWEB incident).
Decouples MAX_REORG_LENGTH from COINBASE_MATURITY. Reverts COINBASE_MATURITY to 100 and sets MAX_REORG_LENGTH to 300, preserving the current ~125 minute window at 25-second spacing. The Bitcoin-inherited MAX_REORG_LENGTH < COINBASE_MATURITY convention is not the security boundary for coinbase spendability. This change is the minimum needed to avoid regressing on the wall-clock margin. The right long-term value is out of scope here.
Raise PostNU7PoWAveragingWindow from 17 to 102 and MAX_REORG_LENGTH from 99 to 600 at NU7 activation, so that at the proposed 25 s target spacing each parameter's wall-clock window matches the duration it provided at Zcash's launch 150 s spacing: 17 * 150 = 102 * 25 = 2,550 s, and 100 * 150 = 600 * 25 = 15,000 s (~4.2 hours). The previously-merged values of 51 and 300 only preserved today's post-Blossom 75 s wall-clock windows; restoring the launch-mainnet durations is more conservative and matches the wall-clock these parameters were originally chosen against. Update the Difficulty averaging window and MAX_REORG_LENGTH rationales accordingly (including the recovery-multiplier reference, 3x -> 6x). Also correct the current MAX_REORG_LENGTH value in prose from 100 to 99: Zebra defines MAX_BLOCK_REORG_HEIGHT as MIN_TRANSPARENT_COINBASE_MATURITY - 1. COINBASE_MATURITY itself remains decoupled and unchanged at 100.
[ZIP 416] Repurpose for documenting zcashd key generation.
Updates to the blocktime reduction ZIP
Author
|
Wrong source/target branch revisions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.