Dev Update: Neptune & Triton
1. Last Week by the Numbers
No GitHub pulse data available for the current period.
2. Stand-up Summary
Alan Szepieniec
- Last Week: Focused on troubleshooting the release protocol after the v0.9.0 activation failure. Managed the deployment of v0.10.0 and v0.10.1 to stabilize the network for the upcoming hard fork.
- Coming Week: Will be stepping back from active development tasks for the month of May due to external professional commitments.
Thorkil Værge
- Last Week: Improved transaction merging logic and auto-consolidation support to optimize block inclusion. Added support for “lustrations” to the official lightweight Neptune wallet. Provided DevOps support for the development of a stateless smartphone application leveraging the UTXO index.
- Coming Week: Implementing a new transaction upgrader rule specifically for merging transactions without fees. Designing a new address format based on community proposals and preparing a technical response regarding the transition back to Nakamoto consensus.
3. Technical Discussion
Hard Fork and Versioning
Critical technical issues with the release protocol necessitated the immediate release of versions 0.10.0 and 0.10.1. These updates are mandatory for all participants to ensure compatibility with the hard fork scheduled for block 38,000 (estimated in approximately one week). The update resolves issues regarding tag persistence and build-task activation failures encountered in v0.9.0.
Transaction Throughput and Merging
To increase network efficiency, improvements were made to how transaction initiators handle merging. A new “upgrader” role is being developed; this operator will focus exclusively on merging transactions to maximize throughput. By operating without charging fees, this role aims to streamline the mempool without increasing costs for users.
Consensus Rationale
The team discussed the technical shift back to Nakamoto consensus. Documentation is being prepared to explain why previous arguments for memory-hard proof-of-work are no longer considered valid in the current architectural context of Neptune Cash, specifically regarding long-term network security and stability.
4. Updates and Announcements
- Hard Fork Warning: All node operators must upgrade to v0.10.1 immediately to remain on the correct chain at block 38,000.
- New Wallet Features: Support for “lustrations” is now live in the lightweight wallet application.
5. Misc
- Policy Change: Going forward, development updates will now strictly focus on Neptune Cash development. Non-technical ecosystem or external marketing content will be filtered; as will any technical discussions relating only to forks.
3 Likes
After block 38,000 hits, is it enough to use v0.10.1 neptune-cli to transfer all my NPTs into newly generated addresses, and if I see the coins on the other side in my wallet, it means nobody used the exploit to steal my coins?
(Also if I forget the “accept lustration” flag, the v0.10.1 neptune-cli just complains, or things get messed up / coins lost somehow?)
If you don’t accept lustrations, it would be as if the transaction was never made. Nothing is lost.
1 Like
I may have found an interesting edge-case related to consolidated UTXOs and potentially future lustration barrier logic.
After consolidating coins, my wallet state became inconsistent between CLI and neptune-wallet-app.
CLI
neptune-cli list-coins
Shows:
-
available: ~5361 NPT
-
time-locked: ~5369 NPT
including one large consolidated coin:
5340.47964894 NPT
Wallet UI
However, neptune-wallet-app shows only:
So the wallet UI appears to classify the large consolidated UTXO as locked/non-available, while CLI considers it available.
This raises an important question regarding the upcoming lustration barrier work mentioned in the latest dev update:
What is currently considered the actual source-of-truth for spendability/state classification?
-
CLI?
-
dashboard/backend?
-
wallet UI?
And more importantly:
Could future lustration barrier validation interact badly with consolidated coins if components already disagree on their state?
Especially if:
become more important under future validation rules.
Would appreciate clarification from the devs. Issue raised - Wallet UI does not show consolidated coins as available/spendable · Issue #14 · Neptune-Crypto/neptune-wallet-app · GitHub .
Thanks for the reply. I believe the reason is that the Neptune wallet app doesn’t properly handle multiple addresses yet.
The source of truth is neptune-core. And from everything I’ve seen, it handles balances correctly, including consolidated UTXOs.
Thanks for quick answer, so what the action is needed from the owner of full node who consolidated many UTXOs other than upgrading to the latest version 0.10.2 to go through lustartion barier? Trying to follow all threads but not quite sure tbh. I started my node 3rd of February so is there any paricular reason to go through lustration barier?
Going through the lustration barrier is only possible after the activation of hardfork-beta, which happens at block height 38,000. Other than that, there is nothing to do if you’ve already consolidated.
Consolidating is not strictly necessary in order to go through the lustration barrier, it just makes it much easier as you can do it in one single transaction instead of having to lustrate for hundred of transactions.
Are there any risks to consolidate now? (E.g. are older utxos, that were left untouched for longer, safer from the exploit than newer consolidated utxos?)
No. There are no risks with consolidating now. In fact I encourage everyone to do it as it’ll make it easier and faster to go through the lustration barrier.
1 Like
Ok great, thanks.
What I don’t yet understand, how does consolidation improve privacy? (one would think exposing many small utxos is better for privacy, otherwise doesn’t everyone knows the big consolidated amount belongs to one party?)
Also, how does this “make it easier”? With many pre-lustration utxos, wouldn’t you just spend the entire pre-lustration amount and the wallet would select all the old utxos and spend them for you?