profile
viewpoint

str4d/android-floating-action-button 98

Floating Action Button for Android API 4+ based on Material Design specification

str4d/age-plugin-yubikey 83

YubiKey plugin for age

mmcloughlin/ec3 53

Elliptic Curve Cryptography Compiler: an incomplete experiment in code-generation for elliptic curves in Go

str4d/android-wizardpager 44

Android pager-style wizard flow sample code - DEVELOPMENT MOVED

Electric-Coin-Company/dev-ci-zcash 34

dev-ci testing using zcash clone, synced with github.com/zcash/zcash

alecmuffett/videonion 19

video onion hackery (osx scripts)

daira/tweedle 15

Generator and supporting evidence for security of the Tweedledum/Tweedledee pair of elliptic curves suitable for Halo

startedcloudpeers/tlfs

started time in 16 hours

startedcloudpeers/tlfs

started time in 16 hours

push eventstr4d/zcash

Jack Grigg

commit sha 31b07fe1384705d3fc78af47cba33465994481ff

Make `PrecomputedTransactionData` a required argument of `SignatureHash` The ZIP 244 changes mean that we're going to need to alter every callsite to pass through all of the transparent `CTxOut`s being spent. Given that we need to pass it over to Rust, it makes more sense to just have `PrecomputedTransactionData` be the vehicle for conveying this data across.

view details

push time in a day

push eventstr4d/zcash

Jack Grigg

commit sha 7147dcb3354fc19c5548a207fa66c624a2fbb96e

Move shielded signature checks out of `ContextualCheckTransaction` The ZIP 244 changes mean that shielded signatures will now require access to any transparent inputs of the transaction, so we need to validate the shielded signatures around the same point during block connection or `AcceptToMemoryPool` as when we validate transparent signatures.

view details

push time in a day

PR opened zcash/zcash

ZIP 244 updates A-consensus L-rust A-rust-ffi NU5

Closes zcash/zcash#5446.

+152 -114

0 comment

7 changed files

pr created time in a day

create barnchstr4d/zcash

branch : 5446-zip-244-updates

created branch time in a day

issue commentzcash/zcash

ZIP 244: Implement changes to bring its transparent semantics closer to BIP 341

I just realised this is quite a bit bigger than I thought. Now that shielded signatures need to commit to transparent input values (if present), shielded signature verification can no longer occur in ContextualCheckTransaction, because we don't have access to the transparent inputs at that point.

I'm going to handle this issue in several stages:

  • Refactor the existing consensus code to move Sapling and Orchard signature validation into ContextualCheckInputs.
    • We don't need to worry about Sprout because it can't occur in v5 transactions that use ZIP 244.
  • Refactor PrecomputedTransactionData to be passed around as a reference instead of a pointer.
    • Anywhere we are computing it already, we can pass the CTxOuts within it (on the Rust side).
    • Anywhere we are not, we'd need to alter the SignatureHash call chain anyway to pass through the CTxOuts, and would then perform the same precomputation once we reach SignatureHash anyway.
  • Migrate to the latest ZIP 244 version (as outlined in OP).
str4d

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 pub fn sapling_default_address(     sapling_find_address(fvk, dk, DiversifierIndex::new()).unwrap() } +/// Returns the internal full viewing key and diversifier key+/// for the provided external FVK = (ak, nk, ovk) and dk encoded+/// in a [Unified FVK].+///+/// [Unified FVK]: https://zips.z.cash/zip-0316#encoding-of-unified-full-incoming-viewing-keys+pub fn sapling_derive_internal_fvk(

Add this to the ## Added section of zcash_primitives/CHANGELOG.md.

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 impl ExtendedFullViewingKey {     pub fn default_address(&self) -> (DiversifierIndex, PaymentAddress) {         sapling_default_address(&self.fvk, &self.dk)     }++    /// Derives an internal full viewing key used for internal operations such+    /// as change and auto-shielding. The internal FVK has the same spend authority+    /// (the private key corresponding to ak) as the original, but viewing authority+    /// only for internal transfers.+    ///+    /// Specified in [ZIP 32](https://zips.z.cash/zip-0032#deriving-a-sapling-internal-full-viewing-key).+    pub fn derive_internal(&self) -> Self {

Add this to the ## Added section of zcash_primitives/CHANGELOG.md.

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 impl ExtendedSpendingKey {     pub fn default_address(&self) -> (DiversifierIndex, PaymentAddress) {         ExtendedFullViewingKey::from(self).default_address()     }++    /// Derives an internal spending key given an external spending key.+    ///+    /// Specified in [ZIP 32](https://zips.z.cash/zip-0032#deriving-a-sapling-internal-spending-key).+    pub fn derive_internal(&self) -> Self {

Add this to the ## Added section of zcash_primitives/CHANGELOG.md.

therealyingtong

comment created time in 3 days

PullRequestReviewEvent

PR opened zcash/halo2

SHA-256 chip tweaks
+97 -100

0 comment

5 changed files

pr created time in 3 days

create barnchzcash/halo2

branch : sha256-tweaks

created branch time in 3 days

push eventzcash/halo2

Jack Grigg

commit sha 54125fbc8c73da47c9c98adb7e141fec89164232

dev: Rename `LookupFailure` to `FailureLocation`

view details

Jack Grigg

commit sha 5520d1348070a80759cba92bcde770beae29daa5

dev: Move reusable logic onto `FailureLocation`

view details

Jack Grigg

commit sha 558e03aa935948e02868e00b7c11bb5c1d15070a

dev: Enable `VerifyFailure::ConstraintNotSatisfied` to point to region offsets

view details

therealyingtong

commit sha 3d22943ebee2aa0187ab68ab0524eb1d792467a0

dev::bad_lookup test: Do not assign zero in lookup table. We now expect the lookup to fail when q = 0, but it still passes, revealing a bug in the MockProver.

view details

therealyingtong

commit sha 7f526f01e64624fa0b30041056dc75d7c5087996

dev: Implement fill_from_row() for MockProver.

view details

therealyingtong

commit sha fe75ceee283f169135804f4642e0a5a2a3522775

dev::bad_lookup test: Fix lookup expression.

view details

str4d

commit sha f565883db08be9e02753f61bfe0af250cc9640bb

Merge pull request #448 from zcash/dev-fill-from-row [dev] Implement `Assignment::fill_from_row()` for `MockProver`.

view details

str4d

commit sha f9b3ff2aef09a5a3cb5489d0e7e747e9523d2e6e

Merge pull request #433 from zcash/mockprover-failure-locations dev: Enable `VerifyFailure::ConstraintNotSatisfied` to point to region offsets

view details

Jack Grigg

commit sha deabd62eeedcb86bce531e62e92acf5a9f1486aa

Migrate to pasta_curves 0.3 and blake2b_simd 1

view details

str4d

commit sha 6630a143c1895dc7d608411fd9686cf29e637924

Merge pull request #450 from zcash/update-deps Migrate to pasta_curves 0.3 and blake2b_simd 1

view details

Kobi Gurkan

commit sha 617416b6f0362e1657a0fdb160a12b5ba0657b98

fix(ci): wasm CI now uses the correct targets

view details

Jack Grigg

commit sha 77af83697cd70a1634da30d9c05982da2f6420f3

Add `poly::Evaluator` for building polynomial operation ASTs Co-authored-by: Sean Bowe <sean@electriccoin.co>

view details

Jack Grigg

commit sha b7ea224389619938ef533b5f08e86d957ecc8419

Migrate `lookup::Argument::commit_permuted` to `poly::Evaluator`

view details

Jack Grigg

commit sha 3c757dc593c7ec44a166a334fd5ede14bd31397d

Migrate `vanishing::Argument` to `poly::Evaluator`

view details

Jack Grigg

commit sha 556bb66a47c381ba0879fa38b6007016443facf1

Parallelize `poly::Evaluator` We now traverse `poly::Ast` `num_chunks + 1` times: once to collect the polynomial rotations we need, and then once per chunk.

view details

Jack Grigg

commit sha b3b783e0f473ce7ff5ace320d82efd5179f79f7e

Switch `poly::Ast` from `Box` to `Arc` This saves a bunch of `Clone`s and `Drop`s, which were consuming significant amounts of time in large circuits (Orchard), which meant we didn't save as much time as we could :)

view details

Jack Grigg

commit sha 21028245991e3409595956e7875a97499e2176c3

Remove unused `Polynomial` operations with internal parallelism These have been replaced by operations on either `poly::Ast` nodes, or operations directly on chunks of polynomials within a higher-level parallelism context. Addition and scalar multiplication are (currently) still used in various areas of the prover, so those are left in place.

view details

str4d

commit sha eb74bf6ccb8062866706ad4084fcd26733d452ea

Merge pull request #447 from zcash/poly-ast-evaluator Add `poly::Evaluator` for building polynomial operation ASTs

view details

Las Safin

commit sha 1613445cdbc552b012c541a222ae3b228de29204

Fix compilation with rustc 1.57.0 The type inference algorithm seems to have been simplified, meaning that the combination of T::from(x.into()) doesn't work anymore. In any case, the code was also incomprehensible to a human, as it's not clear by which "route" it does the transformation. It took me a few minutes to figure out it's a `u64`.

view details

Jack Grigg

commit sha f5a8c9dff9a5f7c869394e3fefe40db23eac60c2

Depend on `rand_core` instead of `rand` All non-test code no longer depends on `OsRng`, instead requiring the caller to provide it.

view details

push time in 3 days

push eventzcash/halo2

Kobi Gurkan

commit sha 617416b6f0362e1657a0fdb160a12b5ba0657b98

fix(ci): wasm CI now uses the correct targets

view details

Las Safin

commit sha 1613445cdbc552b012c541a222ae3b228de29204

Fix compilation with rustc 1.57.0 The type inference algorithm seems to have been simplified, meaning that the combination of T::from(x.into()) doesn't work anymore. In any case, the code was also incomprehensible to a human, as it's not clear by which "route" it does the transformation. It took me a few minutes to figure out it's a `u64`.

view details

Jack Grigg

commit sha f5a8c9dff9a5f7c869394e3fefe40db23eac60c2

Depend on `rand_core` instead of `rand` All non-test code no longer depends on `OsRng`, instead requiring the caller to provide it.

view details

Jack Grigg

commit sha 66a65376136382ebbf363b7eb1c846b827222cc6

Pin bumpalo to `>=3,<3.9.0` for wasm32 targets `bumpalo 3.9.0` raised its MSRV to 1.54; our current MSRV is 1.51.

view details

Jack Grigg

commit sha 9e63eeff1b2c4407bd9dfd714d5a0a44b275cbc9

Enable `getrandom/js` feature flag for wasm32-unknown-unknown Our dev-dependencies include getrandom, and the wasm32-unknown-unknown target requires this getrandom feature flag in order to compile.

view details

str4d

commit sha 2dccf7f23bd5e52594b897189a9ba96013c234af

Merge pull request #463 from zcash/ci-wasm Fix WASM builder in CI

view details

str4d

commit sha 36db257e8201ac23976fc1928dd14cfa5e98ef75

Merge pull request #464 from L-as/main Fix compilation with rustc 1.57.0

view details

Jack Grigg

commit sha 3c6558f0490d97c0b5cb86ebd9584bb542294037

Move `halo2` code into `halo2_proofs` crate

view details

Jack Grigg

commit sha f79ec5cadd34936857c0ded04ae1dfebdcc92d29

Recreate `halo2` as an empty library crate This is now where the recursion logic will live. Closes zcash/halo2#462.

view details

str4d

commit sha d111807798d4719df36dc2b05b0104b69efdceb3

Merge pull request #465 from zcash/462-workspace Refactor into workspace with `halo2` and `halo2_proofs`

view details

Jack Grigg

commit sha ba85f91f63f2ff53382a4583697982c191650b31

Add a `Constraints` helper There are two existing patterns for constructing a gate from a set of constraints with a common selector: - Create an iterator of constraints, where each constraint includes the selector: ``` vec![ ("foo", selector.clone() * foo), ("bar", selector.clone() * bar), ("baz", selector * bar), ] ``` This requires the user to write O(n) `selector.clone()` calls. - Create an iterator of constraints, and then map the selector in: ``` vec![ ("foo", foo), ("bar", bar), ("baz", bar), ].into_iter().map(move |(name, poly)| (name, selector.clone() * poly)) ``` This looks cleaner overall, but the API is not as intuitive, and it is messier when the constraints are named. The `Constraints` struct provides a third, clearer API: ``` Constraints::with_selector( selector, vec![ ("foo", foo), ("bar", bar), ("baz", bar), ], ) ``` This focuses on the structure of the constraints, and handles the selector application for the user.

view details

Jack Grigg

commit sha 12d729aad52666d3293a2cb46e341bb13388a49c

Note that `Constraints::with_selector` accepts arrays from 1.53

view details

push time in 3 days

pull request commentzcash/halo2

Public inputs gadget

This PR needs to be rebased, to now target halo2/src. Also I'd like to hold off merging this PR until we've cut halo2 0.1.0-beta.2 removing all the old halo2 content.

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 impl ExtendedSpendingKey {     pub fn default_address(&self) -> (DiversifierIndex, PaymentAddress) {         ExtendedFullViewingKey::from(self).default_address()     }++    pub fn derive_internal(&self) -> Self {

Document this (yes the existing documentation is sparse; we should improve it as we go).

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 pub fn sapling_default_address(     sapling_find_address(fvk, dk, DiversifierIndex::new()).unwrap() } +/// Returns the internal full viewing key and diversifier key+/// for the provided external fvk and dk+pub fn sapling_derive_internal_fvk(

Document what this API is for (specifically implementing UFVKs, since otherwise this would be duplicative of ExtendedFullViewingKey::derive_internal).

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 impl ExtendedSpendingKey {     pub fn default_address(&self) -> (DiversifierIndex, PaymentAddress) {         ExtendedFullViewingKey::from(self).default_address()     }++    pub fn derive_internal(&self) -> Self {+        let i = {+            let fvk = FullViewingKey::from_expanded_spending_key(&self.expsk);+            let mut h = Blake2bParams::new()+                .hash_length(64)

ZIP 32 specifies BLAKE2b-256 here:

                .hash_length(32)

This bug should be caught by test vectors.

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 impl ExtendedFullViewingKey {     pub fn default_address(&self) -> (DiversifierIndex, PaymentAddress) {         sapling_default_address(&self.fvk, &self.dk)     }++    pub fn derive_internal(&self) -> Self {

Document this.

therealyingtong

comment created time in 3 days

Pull request review commentzcash/librustzcash

Derive Sapling internal keys.

 pub fn sapling_default_address(     sapling_find_address(fvk, dk, DiversifierIndex::new()).unwrap() } +/// Returns the internal full viewing key and diversifier key+/// for the provided external fvk and dk+pub fn sapling_derive_internal_fvk(+    fvk: &FullViewingKey,+    dk: &DiversifierKey,+) -> (FullViewingKey, DiversifierKey) {+    let i = {+        let mut h = Blake2bParams::new()+            .hash_length(64)

ZIP 32 specifies BLAKE2b-256 here:

            .hash_length(32)

This bug should be caught by test vectors.

therealyingtong

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

issue closedzcash/zcash

Update zcashd to accommodate ZIP-244 signing changes.

Update to zcash/librustzcash@81c69dd0a93dcb07bc136d31969f9f8021a5ec48

closed time in 3 days

nuttycom

issue commentzcash/zcash

Update zcashd to accommodate ZIP-244 signing changes.

This is no longer a blocker of #5184 (we fixed the upstream ordering problem). This is also a duplicate of #5446.

nuttycom

comment created time in 3 days

Pull request review commentzcash/zcash

Add zcash_script V5 functions with dummy implementation

 EXPORT_SYMBOL int zcash_script_verify(     uint32_t consensusBranchId,     zcash_script_error* err); +/// Returns 1 if the input nIn of the serialized transaction pointed to by+/// txTo correctly spends the scriptPubKey pointed to by scriptPubKey under+/// the additional constraints specified by flags. Must be used for V5 transactions;+/// may also be used for previous versions.+///+/// allPrevOutputs must point to the concatenation of all outputs from previous+/// transactions that are spent by the inputs of the given transaction.+/// The outputs must be encoded as specified by Bitcoin (value followed by+/// pk_script, including a leading CompactSize).

Make the same changes here as are made to zcash_script_new_precomputed_tx_v5() to address review comments.

conradoplg

comment created time in 3 days

Pull request review commentzcash/zcash

Add zcash_script V5 functions with dummy implementation

 void* zcash_script_new_precomputed_tx(     unsigned int txToLen,     zcash_script_error* err); +/// Deserializes the given transaction and precomputes values to improve+/// script verification performance. Must be used for V5 transactions;+/// may also be used for previous versions.+///+/// allPrevOutputs must point to the concatenation of all outputs from previous+/// transactions that are spent by the inputs of the given transaction.

So the intention is that we parse txTo, then use txTo.vin.len() as the counter for parsing allPrevOutputs? That seems reasonable; we'd load allPrevOutputs into a CDataStream, read CTxOut from it txTo.vin.len() times, and fail if we either run out of data, or there was excess data left over afterwards.

It would be slightly cleaner on our side if the encoding were prefixed with a CompactSize denoting the number of CTxOuts (i.e. the exact same format as is used for vout in a transaction), because then we could just do:

std::vector<CTxOut> allPrevOutputs;
try {
    ss >> allPrevOutputs;
} catch (std::ios_base::failure e) {
    // Fail
}
if (!ss.empty() || allPrevOutputs.len() != txTo.vin.len()) {
    // Fail
}

vs with the currently-proposed encoding (which requires inlining the parsing logic):

std::vector<CTxOut> allPrevOutputs;
allPrevOutputs.resize(txTo.vin.len());
try {
    for (int i = 0; i < txTo.vin.len(); i++) {
        ss >> allPrevOutputs[i];
    }
} catch (std::ios_base::failure e) {
    // Fail
}
if (!ss.empty()) {
    // Fail
}
conradoplg

comment created time in 3 days

Pull request review commentzcash/zcash

Add zcash_script V5 functions with dummy implementation

 EXPORT_SYMBOL int zcash_script_verify(     uint32_t consensusBranchId,     zcash_script_error* err); +/// Returns 1 if the input nIn of the serialized transaction pointed to by+/// txTo correctly spends the scriptPubKey pointed to by scriptPubKey under+/// the additional constraints specified by flags. Must be used for V5 transactions;+/// may also be used for previous versions.+///+/// allPrevOutputs must point to the concatenation of all outputs from previous+/// transactions that are spent by the inputs of the given transaction.+/// The outputs must be encoded as specified by Bitcoin (value followed by+/// pk_script, including a leading CompactSize).+///+/// If not NULL, err will contain an error/success code for the operation.+/// Note that script verification failure is indicated by err being set to+/// zcash_script_ERR_OK and a return value of 0.+EXPORT_SYMBOL int zcash_script_verify_v5(+    const unsigned char* scriptPubKey,+    unsigned int scriptPubKeyLen,+    int64_t amount,

Both of these are unnecessary in this API; we can always obtain them from allPrevOutputs[nIn]. This will also be correct for pre-v5 transactions: I double-checked, and scriptPubKey will always be interpreted as the actual scriptPubKey here, never redeemScript for P2SH (that component of the logic is handled inside this function, not by the caller).

conradoplg

comment created time in 3 days

Pull request review commentzcash/zcash

Add zcash_script V5 functions with dummy implementation

 void* zcash_script_new_precomputed_tx(     unsigned int txToLen,     zcash_script_error* err); +/// Deserializes the given transaction and precomputes values to improve+/// script verification performance. Must be used for V5 transactions;+/// may also be used for previous versions.+///+/// allPrevOutputs must point to the concatenation of all outputs from previous+/// transactions that are spent by the inputs of the given transaction.+/// The outputs must be encoded as specified by Bitcoin (value followed by+/// pk_script, including a leading CompactSize).

This reads weirdly; it suggests the format is (CompactSize, value, pk_script) when it is actually (value, CompactSize, pk_script).

conradoplg

comment created time in 3 days

more