Last week by the numbers
neptune-core
twenty-first
triton-vm
triton-tui
tasm-lib
Neptune Happenings
Alan at Monero Konferenco
Our very own @aszepieniec attended Monero Konferenco 5 and gave a talk about the post-quantum zero-knowledge cryptography used in neptune-cash. The talk appeared to be well received by the monero community in attendance.
We are still trying to track down a video of the talk, and will post it in a future dev update when we do so.
New Release of Supporting Crates
Each of these crates was bumped to version 0.50 and published to crates.io:
twenty-first, triton-vm, triton-tui, triton-cli, tasm-lib
Code Nearly Complete For Proposed Hard Fork
The code is mostly ready, although some unit tests need attention. The hard fork requires versioned consensus rules, and implementing those complicated the task. Further information about the hard fork will be forthcoming so community members can be informed and engage with the process.
Emoji’s for Forum Posts
We installed a discourse emoji plugin that makes it easy to react to forum posts. Only a small number are presently enabled. If you have any requests for your favorite emoji, let us know in the comments below.
Wasm Support for Wallets
@danda has begun work on a new crate that aims to provide a subset of the types in neptune-core for use by wallet software, including wallets that run in a web-browser via web-assembly (wasm).
As part of this effort a PR was merged into the twenty-first crate so that it now builds for target wasm32-unknown-unknown.
QR Code Challenges for Generation Addresses
It was discovered that Generation Addresses exceed the maximum length of a QR code. In particular the QR code standard allows up to 2953 bytes but a bech32m encoded Generation Address is around 3482 bytes – a difference of 529 bytes. This will be an issue for most any neptune wallet software.
Neptune’s Generation Addresses are so long because they are 192 bit quantum resistant public keys. Some options are:
-
Reduce them to 128 bit security level. This should fit in a QR code, but has some potential to reduce privacy. (Because privacy now takes “only” 128 bits worth of effort to break, whereas everything else in Neptune Cash offers at least 160 bits of security.)
-
Use animated QR codes. This is an emerging standard in the cryptocurrency industry for larger offlne data transfers and is already in use by some hardware wallets. Downsides vs a standard QR code is that a phone’s camera app cannot read them (though a Neptune wallet app still could) and also printed usage may be problematic.
-
Use JabCode or some other QR alternative. JabCode can handle more data because it uses colored squares. That also makes it more susceptible to errors while reading than a standard QR code and they cannot be read if printed on a b/w printer such as a standard laser printer.
We invite the neptune community to comment on on this topic. In particular:
- have you had experience with animated QR codes?
- what do you think about lowering the Generation Address to 128 bits?
- what do you think about animated QR vs JabCode?
- other suggestions?
Contributor Updates
- integrate vectorized version of Tip5 into twenty-first (PR #268)
- discuss testing of twenty-first on wasm32 target (PR #265)
- speed up Triton VM proving, in particular, hashing (1, 2)
- release twenty-first, triton-vm, triton-tui, triton-cli, tasm-lib, and raise version bump PR on neptune-core
- twenty-first PR was merged and released. (thx @jfs)
- added additional types to neptune-types:
- address → addressable_key, base_key, encrypted_utxo_notification, generation_address, hash_lock_key, receiving_address, symmetric_key
- utxo, utxo_notification, utxo_notification_payload, timestamp, time_lock, public_announcement, native_currency, lock_script, incoming_utxo
- integrated new types in neptune-wallet-gui
- prepare presentation + attend MoneroKon5
- hard fork 2
- hard fork 2
- mempool:
- Remove incentive for composer to run with small/empty mempool by no longer automatically updating out-of-date single-proof backed transactions
- Remove option of limiting mempool size by number of transactions
- fix bug where max size in number of bytes was not respected.
- Support external developers