Neptune

FAQ

2024-12-19

This thread collects frequently asked questions (and answers).

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.

lightning replacement cycling attack.

2023-10-22

Perhaps something for us to be aware of. quote:

I think this new class of replacement cycling attacks puts lightning in a very perilous position, where only a sustainable fix can happen at the base-layer, e.g adding a memory-intensive history of all-seen transactions or some consensus upgrade.

Article: Bitcoin core developer steps back from Lightning Network over “hard dilemma”

announcing Triton VM v0.35.0

2023-10-17

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

Simpler Sponge Initialization

Up until now, the only way to initialize the Sponge for hashing input of variable length was to use instruction absorb_init. As the name suggests, this instruction not only initializes the Sponge’s state, it also absorbs the stack’s top ten elements. As of this version, this behavior is completely de-coupled: new instruction sponge_init initializes the Sponge state, (existing but renamed) instruction sponge_absorb does the absorbing.

This has immediate runtime effects for the programs that are necessary for Neptune, speeding up variable length hashing by around 16%.

Debug Symbols

As the logic of the programs written for Triton VM grows more complex, debugging options become more important. As of this version, the parser understands the break command. Normal program execution is not affected. While this debugging information is not used yet, the added support makes building a full fledged debugger a lot easier.

Full Changelog

Note: (!) indicates a breaking change.

✨ Features

Better error reporting for failing assert_vector (ee83ab6d)
Include debug information when printing Program (d11aa541)
(!) Replace instruction absorb_init with sponge_init (aca87471)
(!) Add debug instruction break (df6dc4b5)

🐛 Bug Fixes

(!) Use Copy-trait of StarkParameters (70f3d957)
Linter v1.73.0 warnings (641ed393)
Print all helper variables and Sponge state of VM state (07a54f6e)
Disallow changing argument of swap to 0 (bcf61ee6)

📝 Documentation

Adapt constraints to new instruction sponge_init (cde031f0)
Program and its new methods (5ff137dc)
Align specification to code (86a501ea)
Delete cheatsheet (e8a5b526)

🔧 Miscellaneous

(!) Rename instruction div to div_mod (c3ad923a)
Reduce number of as castings (540cf66f)
Remove unused impl Display for InstructionToken (1550f8de)
Ignore JetBrains IDE’s config files (ddf9e7ad)

♻️ Refactor

(!) Move padded_height() into AET (f88d94f3)
Store debug information address_to_label in Program (d857e838)
Improve readability of Program decoding (e3741d68)
Extract VM profiling logic into VMProfiler (97ecef8d)

✅ Testing

Lower number of test cases for some FRI tests (0159a688)
Print error of failing assert_vector (9bcdac2d)
Separate success and failure of ensure_eq (86b97993)
Improve property testing of Sponge instructions (e3d90b8e)
Edge case when last Hash Table row is sponge_init (f5f64963)
Too many returns crash VM, not VMProfiler (a109b890)

LIght nodes and wallet history

2023-10-07

I’ve been reading through some of the excellent blog posts on neptune.cash today, and have read several descriptions of light node functionality without going too deep into the details. Here’s a mile high summary of my present understanding, please correct anything wrong:

The light node Z would ask another node (full, archive, etc) for the most recent (tip) block and receive it.
Z would validate the block against known info, ie the genesis block, using magic (to me) of recursive snarks.
Z would also ask for and receive the current utxo set. (correct? I’m guessing/assuming)
Z would validate the utxo set against the merkle-mountain-range-accumulator in the tip block.
Z iterates through entire utxo set to find any that match user’s keys (addresses).
Z calculates user’s balance as sum(matching_utxo.amount). (by coin type).

This seems to get us the present balance and allow us to spend. However, I don’t see how a transaction history can be displayed without requesting additional blocks from full/archival nodes. Obviously requesting all blocks would allow us to scan everything, but by then we are effectively a full node. So how to get a transaction history without giving up privacy? Or do we just sacrifice tx history?

Ossify and let the market decide.

2023-10-06

This is sort of a blue sky post, out of left field. Not to advocate per se, but just to maybe spark some conversation and weigh pros/cons. gauge interest, or lack thereof.

I was just reading the very excellent post On the Valuation of Cryptocurrencies and this line caught my attention with respect to governance:

One option is for the protocol to ossify, in which case the answer is no-one. This option is risky though because it might happen that a change is necessary for survival, and in this case the ossified protocol will die.

This is actually something I’ve thought about many times with respect to cryptocurrencies. If the goal is to be a “hard” incorruptible money then it should be extremely resistant to change. Consider gold: no one can change its fundamental properties and that’s a very good thing.

So I think that many in this space would agree that someday, eventually we will end up with a cryptocurrency that is so widely used that the consensus rules will fully ossify and be essentially unchangeable, much like tcp/ip v4.

But most would also say that we are not there yet, and it would be foolish to ossify the consensus rules for a brand new cryptocurrency right out of the gate. Even Bitcoin is still (slowly) making changes with so-called soft-forks. And Monero has adopted a policy of hard-forking once (or twice?) a year on a schedule. In this way, upgrades and bug-fixes can occur.

Such upgrades are generally fine…. so long as you, as a hodler, agree with the changes. But if you do not agree, then it feels very much as if you bought into something under a set of promises that are now being reneg’ed upon. rug pull! Perhaps the best-known instance of this was the eth and eth-classic split. But really, most fork events have one or more unhappy parties. Consider the segwit debate and subsequent forks. An observer should thus ask the question: Is it morally right to issue tokens knowing that people will buy them under a given set of rules and then later those rules will be changed without 100% consensus or formal agreement? Or is that a form of fraud? a bait and switch? an ethical dilemma.

Something to think about anyway.

And there is the practical and very worrisome consideration that the more a community is “trained” to accept consensus rule changes, the easier it would be to slip in something “bad” at some point.

But is there any alternative?

I have long thought it would be an interesting experiment to create a (privacy) cryptocurrency that puts immutability (consensus rule change resistance) as its top priority.

The developers would publicly pledge to never change the consensus rules and would write a nice white paper “manifesto” laying out the reasons/philosophy. The early community that forms around this new currency would understand and appreciate this value and would educate later adopters. Ultimately any software in theory can be changed, so it is important to have a community that is hostile to such changes, such that any rule change proposals would be instantly shut-down.

We have seen that the Bitcoin community is fairly resistant to consensus rule change. But its just one value of many, and has been diluted. I’m talking about elevating immutability to the core principle/value of the currency, with “manifesto” statements such as “if the consensus rules ever change, at all this currency should be considered a failed experiment, and utterly worthless”. etc, etc.

Now I hear you saying, but what about upgrades and fixes for like, really serious bugs?!!!

I will address this in two ways:

First, I don’t believe it makes sense to ossify a brand new implementation such as Neptune Cash right out of the gate. For the first few years, perhaps a Monero type hard-fork strategy is best, until the kinks are worked out. But still, statements could be made that the plan is to ossify the consensus rules once a given set of criteria have been reached, perhaps in terms of privacy, stability, security, scalability.

It would also make sense to take an existing mature cryptocurrency, fork the code, and start a new genesis block with the immutability principles and start a community around it. At one point, I had even considered attempting this with ZCash or Monero, but ultimately decided they are not quite ready for primetime.

Second, let’s say we already have our mature, ossified cryptocurrency and community. Let’s call our crypto “Gibraltar”, like the big rock. Now one of two things happens: 1) a serious consensus bug is discovered, or 2) a new technology is discovered that would be a clear and significantly improvement, eg in the areas of privacy, scalability, or censorship resistance.

Can we, as a community, fix the bug or adopt the new technology without changing the consensus rules? yes, I believe so. We let the market decide.

We leave Gibraltar code unchanged. Nodes can continue running forever, conducting transactions.

We fix the bug, or implement the new feature. Maybe we wait until there are a bunch of new features ready we’ve been wanting a long time. Then we create a new genesis block and release a new Cryptocurrency “Gibraltar Prime”. We make it clear that the Gibraltar devs are now supporting and maintaining Gibrlatar Prime. Then we just let the market decide if it wants to stay with Gibraltar or move to partially or fully to Gibraltar Prime. Ideally there would be an easy-to-use atomic-swap mechanism between the old and new chain to reduce migration friction.

The beauty of this mechanism is that each individual holder of Gibraltar can make their own real decision, for him or herself, at a time that is convenient for them. And both the old and new system can coincide for as long as both are useful. The transition can be gradual or fast, as the market decides. This is not like bitcoin’s miner signalling where a handful of mining pools decide for the entire ecosystem (over-simplified). It is not like Monero where the majority can dictate to the minority.

Now obviously starting with a new genesis block leaves a lot of people behind initially. So it is not a step to take lightly. It may be worth doing if there are really compelling reasons. But if the reasons are not compelling enough, then the majority of the market may simply stay with the old rules. And that’s OK! That means we have reached a ruleset that is “good enough” for this society at this point in time.

So wrapping up and bring this back to Neptune Cash.

From what I can tell reading the whitepaper and other posts, Neptune Cash has the main properties I’ve been waiting for in one package: real privacy (unlinkability), scalability, contracts, p.o.w., decentralization. That’s super exciting. To me, this has potential to overtake Bitcoin and everything else, and leave them in the dust.

I would think then that Neptune Cash, as a technology, would form a very solid basis for this type of immutable, ossified cryptocurrency I’m talking about. Perhaps not for the first few years. But maybe in 3, 5 or 10. Or sooner if everything goes just right.

If the Neptune Cash team decided to pursue the ossified path, then it would make sense to make promises before launch with a whitepaper/manifesto about the topic. With a formal specification of the consensus rules at launch, and specific criteria as to when/how the consensus rules will become ossified in the future. It might be best to treat the first few years as a sort of “beta” period, with a clear plan that a new genesis block and trade symbol will be created once the first “ossified” ruleset is determined.

If the Neptune Cash team is not interested in such a path, then it would still be very possible for a third party to fork the code and create such a cryptocurrency/community. Again, a solid codebase is super important, but a solid founding community formed around ideas/principles is equally as important.

Receiving paper wallet funds.

2023-10-06

I was just reading about Paper Wallets in Neptune. It states:

There is no privacy from the sender; he can tell if the receiver spent the coins. After all, the sender possesses knows the UTXO and can derive the decommitment information. However, since the sender does not have the secret key (a,b) he cannot satisfy the lock_script and therefore he cannot spend the UTXO himself.

If I understand correctly, this can easily be mitigated by first receiving funds from 3rd party into a regular software wallet and then sending to your paper wallet. Since you are both sender and receiver of the 2nd tx, privacy is maintained.

Perhaps it might be worth adding this caveat to the post, since in practice the issue can be easily worked around, and custodial wallet software could facilitate it.

<rant> Additionally, in my view, paper wallets have been the abandoned step-child in the bitcoin world. Ever since bip32 support was added into bitcoin-core it would have been so easy to add a “generate paper wallet” feature that is easy and basically foolproof for users with the seed never stored on disk and memory wiped after use. I even offered to work on said feature, but was told it wasn’t wanted. Instead it seems they prefer to recommend hardware wallet honeypots like Ledger that collect customer’s home addresses and then manage to get hacked. </rant>

So yeah, I’d love to see Neptune do better and offer a simple paper wallet generator in the official client(s). The UI would warn users only to fund their paper wallet from your own neptune software wallet, and might offer a “create and fund” single step feature/wizard.

I’d be happy to work on such a feature at some point, if its agreed to be a good idea.

How to avoid losing funds

2023-08-09

We’ve all heard the stories about people losing or throwing away their Bitcoin. Let’s at least attempt to avoid this with Neptune!!

Neptune Core stores cryptographic data in two files: wallet.dat and incoming_randomness.dat.

The short version is that you need to back up your wallet.dat only once, and the incoming_randomness.dat each time you receive a transaction. Both these files are located in your data directory, which can be found in ~/.local/share/neptune/<network>/wallet/ if you use the default settings on a Linux machine. If you’re unsure what you data directory is, it’s value is in the 1st line that is printed when you start neptune-core.

The wallet.dat file never changes, but the incoming_randomness.dat gets a new line every time you receive or mine a transaction!

So to be safe, you need to back up wallet.dat and you need to back up incoming_randomness.dat with each transaction that you receive. Provided these two files are backed up correctly, you will not lose any funds. wallet.dat should be backed up to a media that’s not connected to the internet, and incoming_randomness.dat should be backed up with a solution that can sync the file over a secure network.

For each transaction you receive, you need to update your backup of incoming_randomness.dat.

To elaborate a bit on this, wallet.dat contains the secret key that is used to unlock the lock script that allows you to spend your UTXO. This secret key is provided as the “secret input” when executing the Triton VM whose STARK engine generates a cryptographic proof that you are allowed to spend this UTXO.

incoming_randomness.dat contains the sender_randomness which is a component that keeps your transactions private. The sender_randomness is a component of the canonical_commitment which constitute the leafs of the append-only commitment list that is a part of the “mutator set” data structure.

Rule of thumb for Neptune security

If someone sees your wallet.dat they take your coins
If someone sees your incoming_randomness.dat they can identify your transactions
If you lose your wallet.dat, you lose your coins
If you lose your incoming_randomness.dat, you lose your coins.

When does the ICO start?

2023-09-13

When does the ICO start? When does the ICO start? When does the ICO start?

alphanet-v3

2023-08-09

Alphanet v3 has been pushed to GitHub and is up and running.

Alphanet v3 is a hardfork, so all previous blockchain data must be discarded. This is a hardfork due to an update to the serialization implementation BFieldCodec.

Since alphanet coins are worthless and alphanet-v3 is a restart of the blockchain from genesis, you can simply reset you node by running rm -rf ~/.local/share/neptune/ assuming default configurations. If you want to be a bit more finegrained in what you delete and you want to keep your receiving address see this guide: https://github.com/Neptune-Crypto/neptune-core/#restarting-node-from-the-genesis-block

So, to update, the following commands should do it:

First navigate to the directory, where you have the neptune-core git repo stored. Then:

rm -rf ~/.local/share/neptune/
git pull
cargo install --path .
RUST_BACKTRACE=1 RUST_LOG='info,tarpc=warn' neptune-core --mine --throttled-mining --peers 51.15.139.238:9798 --peers 139.162.193.206:9798

Please note that you normally do not want to delete your wallet.dat, incoming_randomness.dat, and outgoing_randomness.dat files. Basically, you should normally never delete anything in your wallet directory.

How to use this forum

2023-08-07

Software

This forum is running an instance of freedit, which is a lightweight forum based on rust and Javascript-free. The setup is similar to reddit, with inns (subreddits) and feeds, and upvoting.

Getting Started

To get started, you might want to subscribe to:

Formatting

Freedit supports both Markdown and LaTeX, although the second one requires a special syntax to active:

inline math with by writing the familiar dollar signs inside of an inline code snippet using backticks:

`$\sum_{i=0}^\infty \frac{1}{i^2}$`

gives $\sum_{i = 0}^{\infty} \frac{1}{i^{2}}$

to write newline math, embed the LaTeX code into a code snippet with triple-backticks, and mark the language as “math”, e.g.

```math