Neptune

Upgrade to v0.2.0 now!

2025-03-23

At block height 6.000 the blockchain hard forks to allow for higher transaction throughput. Be sure to upgrade to v0.2.0 immediately or risk being caught on the wrong fork, unable to rejoin the network.

New version can be found here.

Backup wallet randomness

2025-03-19

While much effort is being put into making all funds recoverable from the seed word, it’s a lot safer to backup the seed word in combination with the wallet’s incoming randomness. This incoming randomness is extra cryptographic data that is required to spend the wallet’s UTXOs.

I just added a script to the neptune-core repo that uses rsync to backup wallet files to a remote server. The script assumes that you have also stored your seed phrase, which is contained in wallet.dat.

Have a look at the script scripts/linux/backup-neptune-core-randomness.sh.

To clarify: I recommend only backing up incoming_randomness.dat and outgoing_randomness.dat like this. The seed word list (content of wallet.dat) should be backed up in another way, the same way you back up your other blockchain seed phrases.

Limit number of incoming connections on Linux

2025-03-19

Well-connected nodes that receive many incoming connections attempts can experience hanging problems. It’s a problem we should fix in the neptune-core application but until we have, you can use the following commands to let the Linux kernel do the heavy lifting for us.

sudo iptables -A INPUT -p tcp --dport 9798 -m connlimit --connlimit-above 50 -j REJECT --reject-with tcp-reset
sudo iptables -A INPUT -p tcp --dport 9798 -m limit --limit 2/sec --limit-burst 2 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 9798 -m connlimit --connlimit-above 50 -j REJECT --reject-with tcp-reset
sudo ip6tables -A INPUT -p tcp --dport 9798 -m limit --limit 2/sec --limit-burst 2 -j ACCEPT

This limits the number of incoming TCP connections to your 9798 port to 50. And prevents more than 2 new connections per second. This limit applies regardless of the IP of the machine connecting to you. The rules apply for both IPv4 and IPv6.

Verify new rules:

sudo iptables -L -v -n
sudo ip6tables -L -v -n

Persist the new rules:

sudo apt update && sudo apt install netfilter-persistent
sudo netfilter-persistent save

Port 9798 is the standard port used by neptune-core. If you have set your --peer-port value to something, adjust the above commands.

Pull request for "hard fork 1"

2025-03-17

Please weigh in on this pull request if you have opinions on it one way or another: https://github.com/Neptune-Crypto/neptune-core/pull/502

Blog post about this hard fork coming to our website neptune.cash ASAP.

triton-vm ./factorial run failed in 128G Memory Machine

2025-03-18

change the intput to PublicInput::from([bfe!(128_000u32)]); we got Padded Height is 2M . run in diff machine. 512G memmory is right but in 128G memory and 32G swap got fail thread ‘main’ panicked at triton-vm/examples/factorial.rs:96:5: assertion failed: verdict change the input to 64000. both is ok how to check this issue?

Suggestions for IRC

2025-03-16

I am wondering what the best way to use IRC would be.

I have played a bit around with weechat, but I noticed that messages do not persist. I like using linux, but am looking for software maybe that is in homebrew and would work well on a mac too. Any suggestions for what to try are appreciated. I am currently typing this all out in w3m in a terminal interface, and I would like a terminal interface for the IRC channel as well, with more robust server management for handling messages when I’m offline; I’d like to still be part of the conversation and to see the history of the chat.

Testnet is now running

2025-03-15

Testnet is a network that behaves just like main net, but where all the coins are intended to be worthless, so you can play around without bad consequences.

I started up a testnet node that I plan to keep running. For now, I’m also composing and guessing on this network. I cannot guarantee that there will always be composing and guessing happening from my machine but at least one node should always be available.

You can reach it on 51.15.139.238:19798, so by launching neptune-core --network testnet --peers 51.15.139.238:19798 --peer-port 19798 --rpc-port 19799, you can connect to it.

List of publicly available APIs

2025-03-14

The neptune-core program comes with both a CLI interface for interacting with the program, and with an RPC server. But you can also get information about the blockchain without running neptune-core.

Both available block explorers that I know of offer some services through a HTTP/JSON interface.

Documentation of the API of the internally developed block explorer can be found on the front page: https://neptunefundamentals.org/.

As an example, you can get the digest of the current tip with a GET request to https://neptunefundamentals.org/rpc/block_digest/tip.

curl -s https://neptunefundamentals.org/rpc/block_digest/tip
"6081b4799f46350ba33405f81c57647c971327b24e6c0241e89b91c64b6ea18d9274020000000000"

The block explorer developed by an external team has their API documented here. You can, for example, get an overview of the network state through

curl 'https://neptune.vxb.ai/api/overview'
{"message":"","overview":{"average_block_time":581.71326,"block_hash":"6081b4799f46350ba33405f81c57647c971327b24e6c0241e89b91c64b6ea18d9274020000000000","cumulative_proof_of_work":"116021393513180138","day_reward":"19072000000000000000000000000000000","height":4611,"network_speed":"93543182191","proof_target":"59422205698320","timestamp":"Fri, 14 Mar 2025 17:05:27 +0800","total_fee":"567518114400000011349411601848991744","total_reward":"1421696000000000000000000000000000000","utxo_count":19172},"success":false}

List of block explorers for Neptune

2025-03-14

This post is intended to give readers an overview of block explorers for the Neptune Cash blockchain.

I know of three URLs that host block explorers:

The source code of the two former block explorers can be found here on GitHub.

Please add more links in the responses as more block explorers become available :)

FAQ

2024-12-19

This thread collects frequently asked questions (and answers).

External guessers

2025-03-12

A user on Telegram asked me for pointers on how to run guessers in other programs than the neptune-core blockchain client.

For this purpose, we have added three endpoints to the RPC server: pow_puzzle_external_key, pow_puzzle_internal_key, and provide_pow_solution. The data structure ProofOfWorkPuzzle contains the data necessary to do proof-of-work hashing, and the fastest way that I know of to do that on a CPU is through the function fast_kernel_mast_hash which is defined in mine_loop.rs.

For those who haven’t been following this project for long, mining consists of two parts: composing and guessing. The network only needs a few extremely high performing machines to do composition. So if you want to mine Neptune coins but you don’t own an AMD Threadripper 7995wx or an even more powerful machine, guessing is what you should go for.

Happy to answer any questions you may have.

New block explorer! And public API!!

2025-03-12

I was recently informed that there’s a new and much prettier block explorer than the one we (the team behind Neptune) made. Check it out: neptune.vxb.ai

It’s of course limited what you can show on a privacy-preserving blockchain like Neptune. But it’s still possible to see with what frequency the blocks are coming in, how the mining rewards are distributed (between guesser and composer), and how many UTXO inputs and outputs each block contains.

I especially like the graphs on this new block explorer. It’s nice to see the changing difficulty visualized like this.

how run TritonVM profiler log?

2025-03-06

https://github.com/TritonVM/triton-vm/blob/master/triton-vm/Cargo.toml#L63 has a profile features. Do you know how to turn on this flags?

What can we do for mining pool operators?

2025-02-28

A popular request is the ability to mine Neptune Cash through a mining pool.

The current situation is that you need to run the neptune-core program to do what we call “guessing” but is traditionally called “mining”: the attempt to solve the PoW-puzzle by finding a nonce that makes the block hash fall below the threshold defined by the consensus mechanism. However, a more modern approach is to outsource the guessing to external programs like GPU binaries and mining pool servers.

To allow for external programs and mining pools to do the guessing, I’ve added two endpoints to the RPC client: pow_challenge to get the cryptographic information required to start guessing and pow_solution to provide a solution that meets the threshold. These two endpoints, at the time of writing, only live on the thv/external-guessers branch in the neptune-core repository.

Would this suffice to run a mining pool for Neptune? Are the data models adequate. Happy to hear feedback.

Another feature that we have in our pipeline is the ability to define callback programs (shell scripts?) that are run everytime the client experiences an event, such as a new block, a new block proposal (relevant for mining pools), or a new transaction.

Please note that the endpoint names and return types are still in flux; they might change prior to the next release.

how to run Tip5::hash_pair In GPU with Futhark

2025-02-27

I Found https://github.com/Sword-Smith/ruthark repo，but it need git clone private git repo in readme.md Clone this repo: $ git clone ssh://git@neptune.builders:2222/ulrik-dk/gpu-accelerator.git

Estimate own hash rate

2025-02-26

Multiple people have requested a way to estimate your machine’s hash rate to evaluate if guessing is worth it or not. In case you’re not up to speed with Neptune’s mining lingo, guessing is the calculation of block hashes to find a hash digest that is lower than the threshold value. This is done by feeding the Tip5 hash function the block along with a nonce and then calculating the resulting hash. If the hash value is below the threshold dictated by the protocol, you win the block race and get to collect the guesser fee.

The higher your “guess rate” AKA hash rate, the more tickets you get in the proof-of-work lottery.

There’s not yet a way to inspect your guess rate through the dashboard or CLI, but I just added a benchmark to help with this.

You can run the benchmark fast_kernel_mast_hash found in the neptune-core repository through the command cargo bench fast_kernel_mast_hash to get your guess rate. It will report the time it takes your machine to calculate 1,000,000 guesses. If this takes 1 seconds, your guess rate is 1 million.

To get an estimate of your chance of finding the next block, you can (roughly) multiply this number by 400, since the average guessing time is about 400 seconds (200 seconds is used for composition, and block target interval is ~600 seconds) and then divide the result by the current tip’s difficulty. So with 1 million guesses per second, you should expect to find 40 % of all blocks, if the difficulty is 1bn. With a difficulty of 1 trillion, your win-rate would be 0.04 %, or 4 blocks out of 10,000.

The benchmark was added in this commit

Brainstorming: Neptune, exchanges, price discovery.

2024-12-29

Exchange listings are generally necessary for price-discovery of a cryptocurrency. Or at least they are a shortcut to price-discovery.

In recent years centralized exchanges (CEX) have been delisting “privacy coins” left and right. Even monero, the largest privacy coin by usage, has been delisted from most CEX.

I may be wrong, but I believe Neptune will face an uphill, costly fight if efforts are made to get listed on CEX. It may be better to not even attempt that path, but rather focus efforts on the Decentralized Exchange (DEX) path from the start. DEX makes a critical component of the neptune ecosystem more resilient to attacks. Further if DEX is part of neptune’s “core DNA” from the start, then the community that forms around it will value that model and pass it on to newcomers, strengthening the entire ecosystem and ethos.

Broadly speaking, there are a few types of DEX:

CryptoCurrency <—> Fiat.

The best known example is Bisq, a DEX that enables bitcoin <–> fiat trades, and bitcoin <–> altcoin trades. It is bitcoin centric, and it includes its own token (BSQ) and a Decentralized Autonomous Organization (DAO) proposal/voting mechanism for change management and rewarding contributors.

The Monero community has created a fork of Bisq called Haveno that enables monero <–> fiat trades and monero <–> altcoin trades. It is monero centric. It does NOT include its own token or a DAO. It is just an exchange, as Bisq was in its early days.

Both Bisq and Haveno are written in Java, although a bare-bones rust prototype of Bisq called Risq was created approx 5 years ago.

Tokens/Erc-20.

These are typically smart contracts operating on a blockchain such as Ethereum that provides some kind of “wrapped” token for each supported cryptocurrency, and for fiat as well, and bidirectional bridges. These require trust in the bridge operators, the wrapped token mechanism, the underlying blockchain, and the fiat stablecoin operators.

“Local” or Face-2-Face (F2F) websites.

In the past there was localbitcoins, localmonero, agora desk, etc.

For F2F trades, all that is needed is a website for people to post a city, contact details, typically via an anon messaging system, and some basic info about the types of trades they perform (buys or sells, price/percentage, limits).

Sites such as localbitcoins and localmonero provided an escrow service and tried to force users into it, ostensibly for security, but mostly so the website could take a cut. Despite the “local” in their names, both sites mostly concentrated on online payments and kind of neglected the F2F experience, again because it leads away from escrow or any reliance on the website after the first trade/introduction.

Making the website a middleman in each transaction is also a liability for the website operator as it potentially introduces a legal responsibility to ensure there is no criminal activity happening, etc, which then may legally require KYC, etc. I believe this is why most of these types of websites have ceased operations in recent years.

It is my contention that a website that focuses on providing a first class F2F matching/introduction service would be a useful thing, and has never really been done right, to date. Such a site would be simple to build and cheap to operate. Once created it could subsist on community donations. The source code and database could both be open, so that if any one instance is attacked or taken down, another can pop-up. The website is never a middleman in any transaction and takes no fees, so there should not be any legal obligation (ianal) to perform KYC or other checks.

Everything else.

There are some other systems out there such as ThorChain. I’m not sure how applicable they could be for Neptune. Happy to hear of suggestions, more details….

What makes sense for Neptune?

Many possibilities exist. Here are some:

Attempt to get neptune listed on Bisq or Haveno. Encourage people to trade fiat –> bitcoin –> neptune on Bisq, or fiat –> monero –> neptune on Haveno. This is a slow process, with possible slippage at each step. note also that it may be next to impossible to get listed on Bisq until Bisq v2 is ready.
Fork Bisq or Haveno or Risq and make a Neptune-centric version of it. This would be a lot of work, but long-term may have a nice payoff.
create a neptune bridge and wrapped token on ethereum and possibly other blockchains or layer-2s. Then people could easily trade stablecoins and other tokens for a neptune token, and eventually bridge it back out to real neptune. This tends to keep most economic trading activity on the host blockchain however.
create something like erc-20 and an exchange smart-contract on neptune itself. There would probably need to be a token/wrapper and bridge for at least 1 stablecoin. and emulate enough APIs for clients like metamask to interact. This is potentially a lot of work, but eventually it seems it must happen in some manner, if neptune is to flourish.
Local trading website. A basic website, without escrow or fees, and focusing on F2F only could probably be built in a couple of weeks and provide a lot of utility for early neptune users to connect with eachother for trades.

Summary:

(1) and (3) may be relatively fast to setup but have significant drawbacks.

(2) and (4) are likely better long term solutions, but may take considerable development effort, resources, time.

(5) is relatively simplest to build, and should be done first, imho, as the lowest hanging fruit. If there is interest, I can describe the vision/concept in greater detail.

Note that both Bisq and Monero have mechanisms in place for developers to make proposals and the community to fund those proposals. Likely Neptune will need such a system, but that’s for another post…

question about FRI?

2025-01-01

I am wondering about the necessary of FRI to test the low degree of boundary quotient. (boundary_quotient_codewords).

As for https://neptune.cash/learn/stark-anatomy/stark/ In the verify side, the last check of verify procedure has ensured the link between boundary quotient and transition quotient. “Verify the link between boundary quotients and transition quotient. To do this”

According to the stark_anatomy source code, the verify functions check the following equation: verifier_accepts = verifier_accepts and (combination == values[i])

So does this check include the correctness of boundary quotient ? I think boundary quotient should be correct if the above check is successful.

Thanks.

question about STARK transition constraints? thanks.

2024-12-22

I was wondering about the transition polynomials when reading the stark-anatomy source code.

To get dense trace polynomial , subtract the boundary interpolant from the trace polynomial, then divide boundary zerofiers and give rise to boundary quotient.

But for transition polynomial, the transition_quotients are generated by only dividing by transition_zerofiers without subtracting interpolants? So this divding ensure the

Why does the difference exists?

symbolically evaluate transition constraints

    point = [Polynomial([self.field.zero(), self.field.one()])] + trace_polynomials + [tp.scale(self.omicron) for tp in trace_polynomials]
    print("begin symbolic eva:point len=",len(point),",transition_constraints len=",len(transition_constraints))
    transition_polynomials = [a.evaluate_symbolic(point) for a in transition_constraints]
    print("end symbolic eva")

    # divide out zerofier
    transition_quotients = [tp / self.transition_zerofier() for tp in transition_polynomials]

question about STARK boundary constraints? thanks.

2024-12-14

Hi all,

I’m wondering why the boundary constraints doesn’t include the input element which is included in the trace when I read the source code of stark-anatomy:https://github.com/aszepieniec/stark-anatomy/blob/master/code/rescue_prime.py

def boundary_constraints( self, output_element ):
    constraints = []

    # at start, capacity is zero
    constraints += [(0, 1, self.field.zero())]

    # at end, rate part is the given output element
    constraints += [(self.N, 0, output_element)]

    return constraints

how to solve running sync problem?

2024-12-10

Hi all,

I just launched the Neptune-core for the first time, and it shows the following msgs, I’m not sure whether it is normal or error?

Established outgoing TCP connection with 151.115.78.81:9798 Outgoing connection accepted by 51.15.139.238:9798 Entering synchronization mode due to peer 51.15.139.238:9798 indicating tip height 2808; pow family: ProofOfWork([1763900518, 197, 0, 0, 0, 0]) Running sync Creating new sync request Sending block batch request to 151.115.78.81:9798 requesting blocks descending from 08216218079960280509,12846237429271989926,03698217512493722044,05661204014965294855,17508843091365388130

the following msgs repeated for long time ,almost 1 hours till now: Running sync Waiting for last sync to complete.

also with the following msgs sometimes: Connecting to peer [2606:c700:4020:25:b62e:99ff:fef8:af3e]:9798 with distance 2 2024-12-10T03:20:35.605626109Z WARN ThreadId(01) neptune_cash: executed run()::select::peer_discovery_timer in 0.001815681 secs. exceeds slow fn threshold of 0.001 secs. location: /home/pan/neptune/neptune-core/src/main_loop.rs:1415:21 2024-12-10T03:20:35.605726851Z WARN ThreadId(21) neptune_cash::connect_to_peers: Failed to establish connection: Network is unreachable (os error 101) 2024-12-10T03:20:35.605792563Z INFO ThreadId(21) neptune_cash::connect_to_peers: Connection closing

Hello,as a miner,what contributions can I make？

2024-10-19

Hello everyone, scientists, developers, and members of the Neptune community!

I’m new here and eager to learn more. I’d like to know when I can start participating in the mining of this project. Additionally, as a miner, what contributions can I make, such as participating in testnet nodes? Thank you!

Question about Arithmetic Intermediate Representation (AIR)?

2024-12-09

Hi all,

I’m reading alanszepieniec’blog about START implementation https://neptune.cash/learn/stark-anatomy/stark/

I’m wondering why it should subtract boundary interpolants from trace polynomials?

“Instead, the prover interpolates the boundary points and subtracts the resulting interpolants from the trace polynomials. This procedure produces the dense trace polynomials, for lack of a better name”

Thank you very much.

Neptune Team & Community need a Matrix and SimpleX group channel

2024-05-04

Its more efficient to have a modern, refine, private & encrypted communication channel or groups

Matrix & SimpleX (and even Sessions) is a good options since many privacy communities are already there and even many privacy developer/researcher are present there.

Its will be a good platform for collaboration with others.

New Year, New Possibilities. Blue Sky suggestions welcome.

2024-01-14

I’m making this thread for anyone to throw out ideas for Neptune. Basically, anything we would like to see exist or occur: software/features, architecture, community building, economy, mining, game-theory, etc.

This is BlueSky Thinking, so for purposes of this brainstorming exercise, it is the idea that matters. Artificial constraints such as deadlines, budgets, mvp, and spent-cost efforts do not exist. Practicality and present feasability are only minor obstacles. :-)

My own personal wishlist for Neptune software/architecture, in no particular order, are:

Seperate wallet from server. So a single neptune-core instance could serve multiple neptune-wallet-rpc servers. Monero does this, and it makes for a clean architecture and smaller code/attack surface for the core server and wallet. Also more suitable for use by exchanges, block explorers, etc that do not need wallet functionality.
multi-wallet support. Some of my fav bitcoin wallets support multiple wallets and make it easy to create new wallets. Either with a new seed for each, or sharing same seed, but with a different bip32/44 path identifier. monero-wallet-rpc supports shared seed wallets with the new_account API, so again that’s a possible model.
strong ASIC resistance, in the form of randomX POW algo. again, from Monero. Or possibly equivalent dynamic programs running in triton-vm would be even cooler (tritonX?). This should also help prevent 51% attacks by existing ASIC or GPU capacity, something common to lower market-cap coins.
SDK. let’s make neptune-core into a proper library/crate, with neptune-core executable just an app/user with very little code. (darkfi does this).
jsonrpc interface. (already discussed)
EVM compatibility layer. There’s a lot of EVM contracts out there and GUI apps built around them. (Infrastructure) It seems some layer1 chains don’t seem to gain traction until they provide EVM compatibility, and most do provide it.
bip39 mnemonic support.
light mode support in neptune-core. (already planned, i think?)
immutable/frozen consensus layer. already discussed in another thread.
mine tiny amounts on any device. eg mobile phone. So anyone can mine/participate. even though they might receive eg fractional satoshi equiv rewards. Ideally if my hash contribution is 1/100 billionth of the worldwide hashpower, then I should receive 1/100 billionth of each block reward that I mine on. The key is that the tiny rewards be regular to keep people participating. Also, the long tail is key for decentralization and ossification.
integrate p2pool by default. or something similar for decentralized mining pool/shares. This should weaken centralized pools and their capacity for 51% and potentially huge influence re eg soft-forks.
consensus: require proof that miner (hasher) is validating. make it impossible (or too slow) to mine a block without full, local blockchain. In bitcoin miners choose centralized pools because it is easy and they don’t have to setup a full node. But they are not validating and double-checking eachother. They are only hashing. This greatly harms decentralization. Take away this option, and they will be happier to use something like p2pool. edit: yes this is in conflict with tiny amounts on any device, but that probably won’t happen anyway, heh. edit again: if a neptune light-mode miner can fully validate given only the current tip block + new block, then it seems this will not be a problem the way it is on bitcoin, so we just need to ensure they are actually doing that, and not able to delegate validation to pool.

So what do you think of the ideas on my wishlist? And what are your ideas?

note: Several of these ideas are from exposure to the monero ecosystem. I don’t wish to turn neptune into monero by any means, but I do think they’ve had some nice, comparatively little-known architectural improvements over the btc ecosystem, for example.

announcing Triton VM v0.37.0

2024-02-15

Triton VM v0.37.0 is now live. This release is focused on improving code maintainability, library stability, and the API. As such, there are no big ’n shiny changes to highlight this time around. 🙂

Full Changelog

✨ Features

Provide more BFieldCodec-related info for ProofItems (483d9c0d)
(tui) Enable scrolling in memory widget (96e2eaca)
Provide Fiat-Shamir heuristic related info ProofItemVariants (02de19ff)
Simplify parsing of proof item’s payload type (5baeeaeb)
(lint) Warn if underscore bindings are being used (8ab457a6)
(!) Return Err(_), don’t panic!, on unsupported root of unity (60289eb5)
Simplify constructing Claims (31694222)

🐛 Bug Fixes

(test) Remove failure-triggering & superfluous as cast (d8b34e01)
(tui) Send key, mouse, and paste events only to active component (74e42d35)

📚 Documentation

Exemplify usage of Triton VM in examples directory (6e4f8f0e)
Update readme to point at examples folder (2c989b3a)
Update readme of constraint evaluation generator (fa987f38)

⚙️ Miscellaneous

(test) Use iterator transform instead of explicit loop (fc8b9d20)
In CI, check documentation builds free of warnings (bf540685)
Run all tests in CI (d6e99ccc)
Use From (not as) for lossless conversion (4e8b28b7)
Enable additional lints (c309d759)
Don’t call Default::default() (cb73d220)
Avoid explicit .(into_)iter for loops (02018af5)
Name all clone()s explicitly (cd2e503e)
Favor String::new() over "".into() (4650087b)
Deprecate aliases StarkHasher, MTMaker (f9f0e288)
Avoid manually set inclusive range bounds (d7b5f2c6)
Simplify construction of some circuits (56d1bf0e)
Update dependency twenty-first (49b23419)

♻️ Refactor

(test) More rigorously use proptest framework (a27ca6d4)
(!) Communicate possible FRI setup failures with Result (3fe35ad1)
(!) Communicate possible STARK proving failures with Result (5613f194)
(!) Expose public (re-)exports via triton_vm::prelude::* (0bb30d84)
Simplify uses through prelude of dependency twenty-first (75da9a17)
De-duplicate code for ProofItem (a227131c)
Simplify TUI layout construction with new ratatui features (0054597d)
(!) Make lengths of master tables’ rows compile-time known (e52f4cf0)
(!) Integrate StarkParameters into Stark (0c5edc73)
(test) Improve test names (6caa0e1a)
(!) Make VMState’s sponge a Tip5 (d7b8a3f7)

Considerations regarding RandomX

2024-01-23

In another thread, danda suggested using RandomX, the proof-of-work hash function used by Monero:

strong ASIC resistance, in the form of randomX POW algo. again, from Monero. Or possibly equivalent dynamic programs running in triton-vm would be even cooler (tritonX?). This should also help prevent 51% attacks by existing ASIC or GPU capacity, something common to lower market-cap coins.

One of the main selling points for RandomX is its ASIC-resistance. Bitmain offers RandomX mining devices. Some speculate that these devices are ASICs, but others speculate that they are really just clusters of CPUs. Either way: an interesting development. 1

Up until now the design for proof-of-work in Neptune is as follows:

Mining consists of two steps.
In the first step you produce a TritonVM STARK proof of the correctness of the previous block.
In the second step you guess a nonce, which is a field in the header, such that the block’s Tip5 hash digest is less than a target threshold.
Mining pools should be feasible in which the operator produces the proof of the first step and in which the subscribers contribute hashing power of the second step. By subscribing to a mining pool, users of low-end devices can make every last joule of energy count.

We are not necessarily revising that architecture. I just want to have all the arguments articulated and laid out. Or even arguments and idle thoughts that are neither pro nor con but supply useful context. Feel free to contribute.

ASIC-resistance democratizes mining. By “democratize” I mean make accessible to a wide range of people. This benefits the project because it puts coins into the hands of individuals who don’t necessarily (a) have a mining rig or (b) want to get them from an exchange.

ASIC-resistant hash functions are not STARK-friendly. In order to mine the next block, you need to prove that whatever hash puzzle was solved for the last block. If that hash puzzle involves RandomX, the overhead of proving its correct evaluation is significant. This dynamic benefits whoever has the more powerful proving hardware. If it is a STARK-friendly hash function, then it does not have the profile of an ASIC-resistant one.

ASICs stabilize the mining ecosystem. Manufacturers and users of mining ASICs make a capital commitment to mining a particular coin and they cannot use those ASICs for other purposes.

ASIC-resistant hash functions benefit large CPUs with plenty of memory. In particular, the issue is that the hardware that computes the function faster has a systematic advantage over hardware that computes is slower. This is always true, but especially exacerbated by hash functions using random code and lots of memory. Ideally, the hash function treats large CPUs the same as small ones and only the number of joules consumed counts.

Alphanet version 5

2024-01-15

The next version of our testnet is up and running

The most notable UI changes are:

Support for seed-phrase backup of wallet seed, BIP39
Much faster responses to request needed for the dashboard
Faster proof generation from upgrade to Triton-VM v0.36
New wallet format, meaning you need a new wallet.dat

Migrating on Linux: To migrate on Linux, please stop your current node:

Get the latest version of neptune-core by e.g. running git pull
Run ./scripts/linux/alphanet-restart to clear blockchain data
Run cargo install --path .

For this particular update, you should also move your wallet.dat file, as the software needs to generate a new one, as the format has changed.

On Windows the application defaults to storing its data in C:\Users\<user>\AppData\Roaming\neptune\neptune\.

Internally this version enables faster proof generation due to the new version of Triton VM, and a change from a Rust implementation of leveldb to the C++ implementation that the Bitcoin Core client also uses.

Full changelog can be found here.

announcing Triton VM v0.36.0

2023-12-22

Triton VM v0.36.0 is now live. The main highlights are:

More Ergonomic and Faster Instructions

Previously, Triton VM’s stack could grow or shrink by at most one element per instruction. As of this version, this limitation is lifted. Many instructions can now change the stack size by up to five elements at once. This greatly improves speed: for example, all input / output instructions, whether for memory or one of the standard streams, can now process batches of size up to five. It also increases ergonomics: instructions operating on multiple extension field elements such as xxadd now remove both operands from the stack, leaving only the result.

These are just a some examples. The updated instruction set architecture can be found in the specification.

Triton TUI

Triton TUI is a Terminal User Interface for Triton VM. It greatly simplifies running programs written in Triton assembly, and helps with debugging those programs. To get started, install it via cargo install triton-tui, then check out the example program.

The main features of Triton TUI are:

visualization of the state Triton VM is currently in
step debugging similar to gdb – continue to the next breakpoint, step forward one instruction, step out of current function, etc.
annotations – assign names and types to stack and memory elements and have them tracked as Triton VM runs
RAM inspection – navigate freely through all of memory
hot reload & reset – change your program on disk and reload it in the same session of Triton TUI
adaptive interface – you choose which information to show

Improved Error Reporting

Triton VM now reports any failure through custom errors. This allows better error handling downstream. Examples of such errors are failing asserts of the program executed by Triton VM, or the attempt to divide by 0, among many others. Whenever applicable, Triton VM now also returns the state it was in when a crash happened.

Full Changelog

✨ Features

Add benchmark for execution tracing (11b360d6)
Record opstack underflow read/write in AET (a57ef7c3)
Make Op Stack Table variable length (b606dc60)
(!) Instruction hash only puts digest on stack (2e37fb2f)
(!) Make instruction pop take an argument in range 1..=5 (81248b90)
(!) Make instruction divine take an argument in range 1..=5 (5bf3541a)
(!) Instruction divine_sibling pushes divined digest onto stack (4602fad8)
Sponge instructions change stack size (0fac3fc8)
Extension field instructions change stack size (f0b3ab8f)
(!) Make instruction read_io take an argument in range 1..=5 (e138f0a0)
(!) Make instruction write_io take an argument in range 1..=5 (b8e5f978)
Instruction assert_vector shrinks stack by 5 elements (6a0e19cc)
(!) Make memory instructions take an argument in range 1..=5 (8ef132af)
Add benchmark just executing a Triton VM program (8301d5db)
(!) Improve error reporting (48ee1099)
Only change VM state if instruction execution will work (d7fbb3fd)
Add triton-tui, a TUI for debugging programs in Triton assembly (d0d79bce)
Allow installing triton-tui as a binary (047bed9b)
(de)serialize VMState (8df0723c)

🐛 Bug Fixes

Crash VM when executing swap 0 (215f2ede)
Overflowing subtractions when accessing op stack underflow (2aa72e77)
(doc) Correct explanations for previous designs (4bbc2d2a)
Account for op stack table length dominating the AET (f465f756)
Correct calculation of total available memory in Triton VM (18af2b40)
Fail Sponge instructions if Sponge state is uninitialized (881b6c0d)

⚡️ Performance

Remove redundant constraint preventing op stack underflow (6215c108)
Use instruction’s fast-fail for error reporting, not cloning (08bbc41f)

📚 Documentation

Add TIP-0008 “Continuations” (4b38d01b)
Consistently use a space in “op stack” and “jump stack” (eb8dc840)
Delete out-of-date cheat sheet (69aac2dc)
Prose and example for Op Stack Table behavior (db01232f)
Update AET relations diagram (f177d658)
Op Stack Table padding (ad09b8d2)
Update Op Stack Table’s AIR (3fb003b6)
Update Processor Table’s AET and AIR (e59eedeb)
Reflect changes to instructions, constraints, and mechanics (ccf123b8)
Exemplify error handling (90151d6c)
Add changelog (4d1fc2c0)

⚙️ Miscellaneous

Simplify uses (51878fae)
(test) Remove unnecessary paths (4323b202)
read_mem starts reading at current address (7faad183)
(!) Rename & change debugging methods of Program (abd17904)
Fix spelling of collinear (not colinear) (2e9ebd7c)
Improve changelog generation configuration (9e3432f3)
(!) Remove Default derivation from Program (868f49d9)
Allow tracing program execution from a given starting state (5f702d47)
Upgrade dependency cargo-tarpaulin (560f2555)

♻️ Refactor

(examples) Return program, not instructions (55c731ed)
Improve API of VMProfiler (202cb74b)
(vm) Rename ramp to ram_pointer (612714d0)
(processor_table) Remove never-triggered panics (6ced006a)
(processor_table) Remove unused struct ExtProcessorTraceRow (d39230f2)
(test) Use crate test-strategy (01e5e229)
(test) Improve testing instruction’s transition constraints (77948e1a)
(op_stack) Simplify recording of op stack underflow I/O calls (f3803676)
Turn python script for computing opcodes into a rust test (ddb220f2)
(test) Also test transition constraints on extension table (4bd9cf16)
(test) Split test program enumeration into individual tests (cc79cfad)
Abstract over legal argument range for various instructions (a76097e9)
(!) On success, Stark::verify returns Ok(()), not Ok(true) (9d3a7065)
(!) Remove terminal_state, allow running a VM state instead (fbd58f1c)
Simplify indexing into OpStack (4b31b2fe)

✅ Testing

Op stack table row sorting (7418502b)
Factor for running product with Op Stack Table never panics (224e7923)
Turn extension field instruction tests into property tests (067d0053)
Turn get_colinear_y into a property test (39bd4668)
Use proptest, not ad-hoc prop tests, for program parsing tests (d2acbbf8)
Delete some ignored, obsolete tests (8deb268a)
Instructions fail before they modify the state (c680fab2)

Neptune should get rid of any form of dev tax or pre-mine to pass the Howey test

2023-11-08

We all know why Monero worked so well.

Whether its any pre-mine coin or any dev tax we all know how the free market and regulators will respond.