Ecosyste.ms: Timeline
Browse the timeline of events for every public repo on GitHub. Data updated hourly from GH Archive.
Maddiaa0 closed a pull request on AztecProtocol/aztec-packages
feat: prover coordination test with a reorg
w## Overview Prover coordination test with a reorg
benesjan created a review comment on a pull request on AztecProtocol/aztec-packages
Had to bump this as I was hitting the limit.
AztecBot pushed 2 commits to release-please--branches--master AztecProtocol/aztec-packages
benesjan created a review comment on a pull request on AztecProtocol/aztec-packages
I had to bump these constants to be able to pass 2 hiding points and 2 logs via "transient storage" in private refunds flow.
TomAFrench pushed 1 commit to master AztecProtocol/aztec-packages
- feat: Sync from noir (#9410) Automated pull of development from the [noir](https://github.com/noir-lang/noir) progr... b4db379
TomAFrench closed a pull request on AztecProtocol/aztec-packages
feat: Sync from noir
Automated pull of development from the [noir](https://github.com/noir-lang/noir) programming language, a dependency of Aztec. BEGIN_COMMIT_OVERRIDE fix: formatter didn't format `>>=` well (https:/...
AztecBot pushed 1 commit to gh-pages AztecProtocol/aztec-packages
- add C++ Benchmark (googlecpp) benchmark result for 09c9ad894ad64f44c25c191004273ae2828186d5 9f60ee9
benesjan pushed 28 commits to 10-23-refactor_passing_partial_note_logs_through_transient_storage AztecProtocol/aztec-packages
- feat: sequencer cast votes (#9247) Update to make the sequencer cast votes when it is considering block production. bd05d87
- fix: 4epochs kind test et al (#9358) - Updated lock file paths to use /var/lock instead of home directories (~/). A... e480e6b
- chore(master): Release 0.60.0 (#9310) :robot: I have created a release *beep* *boop* --- <details><summary>azt... 09c9ad8
- chore: have 'aztec' honour the 'DEBUG' env var (#9413) 771a2ac
- refactor: passing partial note logs through transient storage 61edddb
- fixes e322c25
- WIP 4fad448
- cleanup 6fc4cc9
- cleanup 7662082
- WIP 8883a4f
- cleanup beb4c8b
- WIP cd5dc9a
- WIP 399c22c
- WIP 2ba92d7
- WIP 4f55279
- WIP a135dfe
- WIP 9cd0107
- WIP 7bd801d
- WIP bb0a2fa
- WIP 68315fb
- and 8 more ...
benesjan pushed 4 commits to 10-23-refactor_passing_partial_note_logs_through_transient_storage AztecProtocol/aztec-packages
stevenplatt pushed 1 commit to srp/16-validator-xfer-test AztecProtocol/aztec-packages
- updated slot time log message 3cc9968
github-actions[bot] created a comment on a pull request on AztecProtocol/aztec-packages
# Changes to public function bytecode sizes > Generated at commit: [35d0f739cc716dcbd679cd303be24057d426f33f](/AztecProtocol/aztec-packages/commit/35d0f739cc716dcbd679cd303be24057d426f33f), compar...
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
Actually, do we need `compute_preaddress` in the first place? I'd just get rid of it and keep the inlined version here.
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
Ideally we'd just return this from the wallet in one go, it makes no sense to fetch the components to then produce the secret whenever we need it.
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
The same thing happens here etc
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
Is there ever a point in computing the point from preaddr + ivpk? We only use the point when encrpyting for someone, but that's done by going backwards from their addr. I don't see where we'd ever ...
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
```suggestion // TLDR; P1 = (h + ivsk) * G ```
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
```suggestion // Given h (our preaddress) and our ivsk, we have two different addressSecret candidates. One encodes to a point with a positive y-coordinate ```
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
```suggestion // Given h (our preaddress) and our ivpk_m, we can derive our address point. ``` Sounds like the preaddress is a separate thing otherwise
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
This is missing the `y > half_range` check, and the fact that we only take the x coord
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
The 0..12 is a bit too magical - and why do we need to pass the original keys?
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
There should either be a comment or at least conveyed through the name that this value is autogenerated by a TS script.
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
From the comments in https://github.com/AztecProtocol/aztec-packages/issues/8966 it seemed like we needed to do `addr = -addr` if the y coordinate was high - does that not affect the x coord?
nventuro created a review comment on a pull request on AztecProtocol/aztec-packages
```suggestion let pre_address = self.compute_preaddress(); ```