Dev Update 26 Aug 2025

[neptune-team]

Last week by the numbers

neptune-core

• 30 commits to master branch
• 2 issues closed
• 3 pull requests raised
• 3 pull requests merged

neptune-explorer

• 14 commits to master branch
• 1 pull requests raised
• 1 pull requests merged

triton-vm

• 1 commits to master branch

Neptune Happenings

Blog Post: Memory Hard Proof of Work

Abstract. With the launch of its rebooted network, Neptune Cash changed the proof-of-work puzzle. On the legacy network, this puzzle had consisted of a simple partial preimage search: the task is to find a nonce such that the hash of the block is less than a given target. On the rebooted network, the puzzle consists of finding not just a nonce but a Merkle root and authentication paths as well; and in addition to satisfying the hash inequality, the root and authentication paths must be valid. To efficiently guess solutions to this puzzle, guessers must possess at least 40 GB or RAM. This article motivates the change and explains in detail how the new proof-of-work mechanism works.

Memory-Hard Proof-of-Work

Mempool improvements

@sword-smith has continued plugging away at the mempool. He changed the mempool events to only pass the TransactionKernel which means the large proof is not included. This should save a lot of bandwidth once we enable a modular architecture for external wallets. He also fixed some small bugs in internal functions that ended up making the code more efficient.

Transparent Transactions Infrastructure

@aszepieniec reported completing the transparent transactions infrastructure, which included API additions for initiating and broadcasting transparent transactions, and an explorer addition for viewing them. The first disbursement from the UTXO redemption claims fund was made using this mechanism, viewable on the explorer. Existing nodes will treat these as unknown announcements, but the latest code allows them to be observed via an explorer or visualizer, primarily for UTXO redemption claims but potentially useful in the future for public state smart contracts.

Discussion About Transparent Transactions in neptune-core

Concerns have been raised about the impact of transparent transactions on privacy.
Private transactions would be the default and would be less costly than transparent transactions. However there remains a concern that exchanges might still use transparent transactions for withdrawals, which has potential to weaken receiver’s privacy in some situations. Transparent transactions could end up representing a large percentage of overall transactions and the size of the anonymity set would decrease in proportion. There is a also a general concern about crossing the line between a “pure” privacy coin and one with optional privacy. which could arguably weaken Neptune’s core value proposition. As such, we may delay release of this functionality while working through such concerns.

We invite the community to express opinions.

Contributor Updates:

@aszepieniec

• transparent transactions
• memory-hard proof-of-work article

@danda

• updated neptune-types and proton-gui crates to be compatible with neptune v0.3.0.

[danda]

I started a thread with some analysis of possible impact of sender-initiated transparent transactions. Interestingly, this is not only a neptune issue, but appears to be a novel attack vector for all privacy coins. I’m not sure if it’s really been discussed before.

Discussion of proposed Transparent Transactions

I am concerned about the proposal to add transparent transaction functionality to neptune-core. (stating my bias) In a recent discussion, it was pointed out that theoretically there is nothing to prevent a sender from making a transaction transparent on any privacy-preserving cryptocurrency, since the sender must transmit secrets to the receiver and nothing prevents the sender from publishing those secrets. I thought this an interesting observation as it would apply to monero, zcash, wownero…

It would be interesting to think about if there is some way to prevent sender initiated transparent transactions, on any blockchain.

[aszepieniec]

@danda

It would be interesting to think about if there is some way to prevent sender initiated transparent transactions, on any blockchain.

That is a juicy question.

I think there cannot be any mechanism that prevents Alice from releasing abstract information such as “I paid Bob X amount of coin Y on date Z”. However, what’s not out of the question is a mechanism that makes this proposition unprovable. More precisely, it might be possible to find a mechanism that allows Alice to publish any additional information, including her own secret keys, such that regardless of that additional information, an external observer still cannot determine whether the information that appears on the blockchain matches Alice’s description of events. The corollary of that mechanism would be that if Bob disputes the payment, maliciously claiming it was never made when in fact it was, Alice would have no recourse to cryptographic proofs to prove that he is wrong. This hypothetical mechanism throws out the baby with the bath water: the whole point of having a blockchain is to resolve disputes without going through trusted intermediaries or central authorities.

But if we take a step back and not require on-chain payments, then I think we can get very close. Alice makes a Lightning payment to Bob. Even if she releases all information related to this lightning payment, an external party has no blockchain data to verify that it really happened. If Bob contests the payment, Alice responds by initiating the channel closure. If Bob then insists that he was not paid, Alice will be credited with the delta, and she can choose to pay Bob on-chain afterwards – or not: she can also choose to punish Bob for his malicious behavior. If Bob changes his position in order to claim the balance delta, then his attempt to defraud is exposed on the blockchain. Either way, Bob is risking punishment for malicious behavior.