Last week by the numbers
neptune-core
twenty-first
neptune-types
neptune-proton
triton-vm
Neptune Happenings
Alan Szepieniec appearance on X Spaces roundtable.
neptune-proton desktop wallet v0.3.0 for Linux and Windows
This week brought a couple of releases of the neptune-proton GUI wallet. New features in v0.3.0 include a new screen for viewing UTXOS, improved display of empty screens (with fun animations), and the ability to clear peer standings.
v0.1.3 brought graceful handling (detect, resume) of neptune-core connection loss and enables display of national currency equivalents by default.
Initial Block Download: Parallel Sync
@aszepieniec has completed work on the syncing PR, including running numerous tests. He implemented prioritization of related P2P messages so that critical messages are more likely to be processed in a high contention situation.
Burned Amounts and Verifiability
@aszepieniec added a small patch to the block explorer to indicate burned outputs. The most significant burn to date was 1,526,640.0 NPT, and can be viewed here
There was some discussion of adding neptune-core RPC methods for listing burned outputs and for obtaining the present circulating supply (sum of coinbases). For now, these remain future work.
Privacy Implications of Burns
It was noticed that the current burn transaction implementation, which is transparent, leaks information about the source UTXO amount and also the change UTXO(s). Eg: “I own Y coins and I still own Y - X coins”. This seems to be ok, so long as it is clearly documented behavior. Anyway, it is not expected that burning will be common usage, and there is presently no UI exposed for it.
Tip5 Bug Chase and Performance Optimization
@jfs investigated a bug reported deep within the twenty-first crate, concerning a buggy output in a function internal to the tip5 hashing algorithm. He discovered that the issue is real however an undocumented feature in a subsequent method completely eliminated/corrected the bug, meaning no code changes were necessary and hashing is correct. Documentation and tests were added for this.
He also managed to speed up one part of the Triton VM compilation pipeline by a factor of six, which reduced CI times from over three hours to 30 minutes, though end-user compile times only dropped by about 10 seconds.
STIR Implementation and Future Work
@jfs reports that STIR is working with a prover, verifier, and parameter derivation, but there is one open question mark that needs review. The next step involves making the code more amenable to translation into TASM, which might require restructuring the verifier setup to avoid allocating structures and parsing the proof ahead of time. The plan is to integrate STIR into Triton VM and explore the “STIR and SHAKE” technique, which modifies STIR to improve verifier efficiency by applying a trick to all polynomials, reducing the number of required interpolations.
Conjectural Security of the FRI/STIR Query Protocol
@aszepieniec updated the team on the query phase of FRI and STIR protocols, noting that recent papers agree that the conjectured security at the very end of the spectrum is not as secure as hoped, suggesting a drop to provable security may incur a performance hit. While the extreme end of the conjecture is rejected, they are likely still secure at around 140 to 150 bits even when rejecting the conjecture, though this requires hard math to confirm. Our present STIR setup allows selecting between relying on unproven or conjectured security assumptions and Neptune will take a conservative path prioritizing proven security over performance.
Circulating Supply Calculation in block explorer
There was discussion about how the circulating supply is determined by explorer.neptune.cash. It presently calculates the value based on an arithmetic sum, not actual data from Neptune core or checking every block. Thus the displayed amount is a maximum value, rather than a known true value. It is possible for miners to reward themselves less than the full coinbase amount, though we have not yet checked if that has ever occurred for any block(s).
Perhaps a community member might like to perform this check and let us know?
@aszepieniec plans to implement circulating supply calculation in Neptune core using the arithmetic sum and noted we could track blocks where miners declined the full coinbase when they occur.