Neptune <p>All things Neptune.</p> 2024-05-04T17:42:16+00:00 Neptune Team & Community need a Matrix and SimpleX group channel i2pZ7812HTZV69 2024-05-04 2024-05-04 18 <p>Its more efficient to have a modern, refine, private &amp; encrypted communication channel or groups</p> <p>Matrix &amp; SimpleX (and even Sessions) is a good options since many privacy communities are already there and even many privacy developer/researcher are present there.</p> <p>Its will be a good platform for collaboration with others.</p> New Year, New Possibilities. Blue Sky suggestions welcome. danda 2024-01-14 2024-01-14 13 <p>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.</p> <p>This is <a href="" rel="noopener noreferrer">BlueSky Thinking</a>, so for purposes of this <a href="" rel="noopener noreferrer">brainstorming exercise</a>, 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. :-)</p> <p>My own personal wishlist for Neptune software/architecture, in no particular order, are:</p> <ul> <li> <p><strong>Seperate wallet from server</strong>. So a single neptune-core instance could serve multiple neptune-wallet-rpc servers. Monero does this, and it makes for a clean architecture and <a href="" rel="noopener noreferrer">smaller code/attack surface</a> for the core server and wallet. Also more suitable for use by exchanges, block explorers, etc that do not need wallet functionality.</p> </li> <li> <p><strong>multi-wallet support</strong>. 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 <a href="" rel="noopener noreferrer">new_account API</a>, so again that’s a possible model.</p> </li> <li> <p><strong>strong ASIC resistance</strong>, in the form of <a href="" rel="noopener noreferrer">randomX POW algo</a>. 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.</p> </li> <li> <p><strong>SDK</strong>. 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).</p> </li> <li> <p><strong>jsonrpc interface</strong>. (already discussed)</p> </li> <li> <p><strong>EVM compatibility layer</strong>. 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.</p> </li> <li> <p><strong>bip39 mnemonic support</strong>.</p> </li> <li> <p><strong>light mode support</strong> in neptune-core. (already planned, i think?)</p> </li> <li> <p><strong>immutable/frozen consensus layer</strong>. already discussed in another thread.</p> </li> <li> <p><strong>mine tiny amounts on any device</strong>. eg mobile phone. So anyone can mine/participate. even though they might receive eg fractional satoshi equiv rewards. <em>Ideally</em> 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 <em>regular</em> to keep people participating. Also, <a href="" rel="noopener noreferrer">the long tail</a> is key for decentralization and ossification.</p> </li> <li> <p><strong>integrate p2pool by default</strong>. 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.</p> </li> <li> <p><strong>consensus: require proof that miner (hasher) is validating</strong>. make it impossible (or too slow) to mine a block without full, local blockchain. In bitcoin miners choose centralized pools because it is <em>easy</em> and they don’t have to setup a full node. But they are not <em>validating</em> and double-checking eachother. They are only <em>hashing</em>. 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.</p> </li> </ul> <p>So what do you think of the ideas on my wishlist? And what are your ideas?</p> <p>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.</p> announcing Triton VM v0.37.0 jfs 2024-02-15 2024-02-15 16 <p><a href="" rel="noopener noreferrer">Triton VM v0.37.0</a> 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. 🙂</p> <h1>Full Changelog</h1> <h3>✨ Features</h3> <ul> <li>Provide more <code>BFieldCodec</code>-related info for <code>ProofItem</code>s (<a href="" rel="noopener noreferrer">483d9c0d</a>)</li> <li><em>(tui)</em> Enable scrolling in memory widget (<a href="" rel="noopener noreferrer">96e2eaca</a>)</li> <li>Provide Fiat-Shamir heuristic related info <code>ProofItemVariant</code>s (<a href="" rel="noopener noreferrer">02de19ff</a>)</li> <li>Simplify parsing of proof item’s payload type (<a href="" rel="noopener noreferrer">5baeeaeb</a>)</li> <li><em>(lint)</em> Warn if underscore bindings are being used (<a href="" rel="noopener noreferrer">8ab457a6</a>)</li> <li>(!) Return <code>Err(_)</code>, don’t <code>panic!</code>, on unsupported root of unity (<a href="" rel="noopener noreferrer">60289eb5</a>)</li> <li>Simplify constructing <code>Claim</code>s (<a href="" rel="noopener noreferrer">31694222</a>)</li> </ul> <h3>🐛 Bug Fixes</h3> <ul> <li><em>(test)</em> Remove failure-triggering &amp; superfluous <code>as</code> cast (<a href="" rel="noopener noreferrer">d8b34e01</a>)</li> <li><em>(tui)</em> Send key, mouse, and paste events only to active component (<a href="" rel="noopener noreferrer">74e42d35</a>)</li> </ul> <h3>📚 Documentation</h3> <ul> <li>Exemplify usage of Triton VM in <code>examples</code> directory (<a href="" rel="noopener noreferrer">6e4f8f0e</a>)</li> <li>Update readme to point at examples folder (<a href="" rel="noopener noreferrer">2c989b3a</a>)</li> <li>Update readme of constraint evaluation generator (<a href="" rel="noopener noreferrer">fa987f38</a>)</li> </ul> <h3>⚙️ Miscellaneous</h3> <ul> <li><em>(test)</em> Use iterator transform instead of explicit loop (<a href="" rel="noopener noreferrer">fc8b9d20</a>)</li> <li>In CI, check documentation builds free of warnings (<a href="" rel="noopener noreferrer">bf540685</a>)</li> <li>Run <em>all</em> tests in CI (<a href="" rel="noopener noreferrer">d6e99ccc</a>)</li> <li>Use <code>From</code> (not <code>as</code>) for lossless conversion (<a href="" rel="noopener noreferrer">4e8b28b7</a>)</li> <li>Enable additional lints (<a href="" rel="noopener noreferrer">c309d759</a>)</li> <li>Don’t call <code>Default::default()</code> (<a href="" rel="noopener noreferrer">cb73d220</a>)</li> <li>Avoid explicit <code>.(into_)iter</code> for loops (<a href="" rel="noopener noreferrer">02018af5</a>)</li> <li>Name all <code>clone()</code>s explicitly (<a href="" rel="noopener noreferrer">cd2e503e</a>)</li> <li>Favor <code>String::new()</code> over <code>"".into()</code> (<a href="" rel="noopener noreferrer">4650087b</a>)</li> <li>Deprecate aliases <code>StarkHasher</code>, <code>MTMaker</code> (<a href="" rel="noopener noreferrer">f9f0e288</a>)</li> <li>Avoid manually set inclusive range bounds (<a href="" rel="noopener noreferrer">d7b5f2c6</a>)</li> <li>Simplify construction of some circuits (<a href="" rel="noopener noreferrer">56d1bf0e</a>)</li> <li>Update dependency <code>twenty-first</code> (<a href="" rel="noopener noreferrer">49b23419</a>)</li> </ul> <h3>♻️ Refactor</h3> <ul> <li><em>(test)</em> More rigorously use <code>proptest</code> framework (<a href="" rel="noopener noreferrer">a27ca6d4</a>)</li> <li>(!) Communicate possible FRI setup failures with <code>Result</code> (<a href="" rel="noopener noreferrer">3fe35ad1</a>)</li> <li>(!) Communicate possible STARK proving failures with <code>Result</code> (<a href="" rel="noopener noreferrer">5613f194</a>)</li> <li>(!) Expose public (re-)exports via <code>triton_vm::prelude::*</code> (<a href="" rel="noopener noreferrer">0bb30d84</a>)</li> <li>Simplify <code>use</code>s through prelude of dependency <code>twenty-first</code> (<a href="" rel="noopener noreferrer">75da9a17</a>)</li> <li>De-duplicate code for <code>ProofItem</code> (<a href="" rel="noopener noreferrer">a227131c</a>)</li> <li>Simplify TUI layout construction with new <code>ratatui</code> features (<a href="" rel="noopener noreferrer">0054597d</a>)</li> <li>(!) Make lengths of master tables’ rows compile-time known (<a href="" rel="noopener noreferrer">e52f4cf0</a>)</li> <li>(!) Integrate <code>StarkParameters</code> into <code>Stark</code> (<a href="" rel="noopener noreferrer">0c5edc73</a>)</li> <li><em>(test)</em> Improve test names (<a href="" rel="noopener noreferrer">6caa0e1a</a>)</li> <li>(!) Make <code>VMState</code>’s <code>sponge</code> a <code>Tip5</code> (<a href="" rel="noopener noreferrer">d7b8a3f7</a>)</li> </ul> Considerations regarding RandomX aszepieniec 2024-01-23 2024-01-23 15 <p>In <a href="" rel="noopener noreferrer">another thread</a>, <a href="" rel="noopener noreferrer">danda</a> suggested using <a href="" rel="noopener noreferrer">RandomX</a>, the proof-of-work hash function used by Monero:</p> <blockquote> <p>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.</p> </blockquote> <p>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. <a href="" rel="noopener noreferrer">1</a></p> <p>Up until now the design for proof-of-work in Neptune is as follows:</p> <ul> <li>Mining consists of two steps.</li> <li>In the first step you produce a <a href="" rel="noopener noreferrer">TritonVM</a> STARK proof of the correctness of the previous block.</li> <li>In the second step you guess a nonce, which is a field in the header, such that the block’s <a href="" rel="noopener noreferrer">Tip5</a> hash digest is less than a target threshold.</li> <li>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.</li> </ul> <p>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.</p> <p><strong>ASIC-resistance democratizes mining.</strong> 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.</p> <p><strong>ASIC-resistant hash functions are not STARK-friendly.</strong> 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.</p> <p><strong>ASICs stabilize the mining ecosystem.</strong> Manufacturers and users of mining ASICs make a capital commitment to mining a particular coin and they cannot use those ASICs for other purposes. </p> <p><strong>ASIC-resistant hash functions benefit large CPUs with plenty of memory.</strong> 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.</p> Alphanet version 5 sword_smith 2024-01-15 2024-01-15 14 <p>The next version of our testnet is up and running</p> <p>The most notable UI changes are:</p> <ul> <li>Support for seed-phrase backup of wallet seed, BIP39</li> <li>Much faster responses to request needed for the dashboard</li> <li>Faster proof generation from upgrade to Triton-VM v0.36</li> <li>New wallet format, meaning you need a new <code>wallet.dat</code></li> </ul> <p>Migrating on Linux: To migrate on Linux, please stop your current node:</p> <ul> <li>Get the latest version of <code>neptune-core</code> by e.g. running <code>git pull</code></li> <li>Run <code>./scripts/linux/alphanet-restart</code> to clear blockchain data</li> <li>Run <code>cargo install --path .</code> </li> </ul> <p>For this particular update, you should also move your <code>wallet.dat</code> file, as the software needs to generate a new one, as the format has changed.</p> <p>On Windows the application defaults to storing its data in <code>C:\Users\&lt;user&gt;\AppData\Roaming\neptune\neptune\</code>.</p> <p>Internally this version enables faster proof generation due to the <a href="" rel="noopener noreferrer">new version of Triton VM</a>, and a change from a Rust implementation of leveldb to the C++ implementation that the Bitcoin Core client also uses.</p> <p>Full changelog can be found <a href="" rel="noopener noreferrer">here</a>.</p> announcing Triton VM v0.36.0 jfs 2023-12-22 2023-12-22 12 <p><a href="" rel="noopener noreferrer">Triton VM v0.36.0</a> is now live. The main highlights are:</p> <h1>More Ergonomic and Faster Instructions</h1> <p>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 <code>xxadd</code> now remove both operands from the stack, leaving only the result.</p> <p>These are just a some examples. The updated instruction set architecture can be found in the <a href="" rel="noopener noreferrer">specification</a>.</p> <h1>Triton TUI</h1> <p><a href="" rel="noopener noreferrer">Triton TUI</a> 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 <code>cargo install triton-tui</code>, then check out the <a href="" rel="noopener noreferrer">example program</a>.</p> <p>The main features of Triton TUI are:</p> <ul> <li>visualization of the state Triton VM is currently in</li> <li>step debugging similar to <code>gdb</code> – continue to the next breakpoint, step forward one instruction, step out of current function, etc.</li> <li>annotations – assign names and types to stack and memory elements and have them tracked as Triton VM runs</li> <li>RAM inspection – navigate freely through all of memory</li> <li>hot reload &amp; reset – change your program on disk and reload it in the same session of Triton TUI</li> <li>adaptive interface – you choose which information to show</li> </ul> <h1>Improved Error Reporting</h1> <p>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.</p> <h1>Full Changelog</h1> <h3>✨ Features</h3> <ul> <li>Add benchmark for execution tracing (<a href="" rel="noopener noreferrer">11b360d6</a>)</li> <li>Record opstack underflow read/write in AET (<a href="" rel="noopener noreferrer">a57ef7c3</a>)</li> <li>Make Op Stack Table variable length (<a href="" rel="noopener noreferrer">b606dc60</a>)</li> <li>(!) Instruction <code>hash</code> only puts digest on stack (<a href="" rel="noopener noreferrer">2e37fb2f</a>)</li> <li>(!) Make instruction <code>pop</code> take an argument in range 1..=5 (<a href="" rel="noopener noreferrer">81248b90</a>)</li> <li>(!) Make instruction <code>divine</code> take an argument in range 1..=5 (<a href="" rel="noopener noreferrer">5bf3541a</a>)</li> <li>(!) Instruction <code>divine_sibling</code> pushes divined digest onto stack (<a href="" rel="noopener noreferrer">4602fad8</a>)</li> <li>Sponge instructions change stack size (<a href="" rel="noopener noreferrer">0fac3fc8</a>)</li> <li>Extension field instructions change stack size (<a href="" rel="noopener noreferrer">f0b3ab8f</a>)</li> <li>(!) Make instruction <code>read_io</code> take an argument in range 1..=5 (<a href="" rel="noopener noreferrer">e138f0a0</a>)</li> <li>(!) Make instruction <code>write_io</code> take an argument in range 1..=5 (<a href="" rel="noopener noreferrer">b8e5f978</a>)</li> <li>Instruction <code>assert_vector</code> shrinks stack by 5 elements (<a href="" rel="noopener noreferrer">6a0e19cc</a>)</li> <li>(!) Make memory instructions take an argument in range 1..=5 (<a href="" rel="noopener noreferrer">8ef132af</a>)</li> <li>Add benchmark just executing a Triton VM program (<a href="" rel="noopener noreferrer">8301d5db</a>)</li> <li>(!) Improve error reporting (<a href="" rel="noopener noreferrer">48ee1099</a>)</li> <li>Only change VM state if instruction execution will work (<a href="" rel="noopener noreferrer">d7fbb3fd</a>)</li> <li>Add <code>triton-tui</code>, a TUI for debugging programs in Triton assembly (<a href="" rel="noopener noreferrer">d0d79bce</a>)</li> <li>Allow installing triton-tui as a binary (<a href="" rel="noopener noreferrer">047bed9b</a>)</li> <li>(de)serialize <code>VMState</code> (<a href="" rel="noopener noreferrer">8df0723c</a>)</li> </ul> <h3>🐛 Bug Fixes</h3> <ul> <li>Crash VM when executing <code>swap 0</code> (<a href="" rel="noopener noreferrer">215f2ede</a>)</li> <li>Overflowing subtractions when accessing op stack underflow (<a href="" rel="noopener noreferrer">2aa72e77</a>)</li> <li><em>(doc)</em> Correct explanations for previous designs (<a href="" rel="noopener noreferrer">4bbc2d2a</a>)</li> <li>Account for op stack table length dominating the AET (<a href="" rel="noopener noreferrer">f465f756</a>)</li> <li>Correct calculation of total available memory in Triton VM (<a href="" rel="noopener noreferrer">18af2b40</a>)</li> <li>Fail Sponge instructions if Sponge state is uninitialized (<a href="" rel="noopener noreferrer">881b6c0d</a>)</li> </ul> <h3>⚡️ Performance</h3> <ul> <li>Remove redundant constraint preventing op stack underflow (<a href="" rel="noopener noreferrer">6215c108</a>)</li> <li>Use instruction’s fast-fail for error reporting, not cloning (<a href="" rel="noopener noreferrer">08bbc41f</a>)</li> </ul> <h3>📚 Documentation</h3> <ul> <li>Add TIP-0008 “Continuations” (<a href="" rel="noopener noreferrer">4b38d01b</a>)</li> <li>Consistently use a space in “op stack” and “jump stack” (<a href="" rel="noopener noreferrer">eb8dc840</a>)</li> <li>Delete out-of-date cheat sheet (<a href="" rel="noopener noreferrer">69aac2dc</a>)</li> <li>Prose and example for Op Stack Table behavior (<a href="" rel="noopener noreferrer">db01232f</a>)</li> <li>Update AET relations diagram (<a href="" rel="noopener noreferrer">f177d658</a>)</li> <li>Op Stack Table padding (<a href="" rel="noopener noreferrer">ad09b8d2</a>)</li> <li>Update Op Stack Table’s AIR (<a href="" rel="noopener noreferrer">3fb003b6</a>)</li> <li>Update Processor Table’s AET and AIR (<a href="" rel="noopener noreferrer">e59eedeb</a>)</li> <li>Reflect changes to instructions, constraints, and mechanics (<a href="" rel="noopener noreferrer">ccf123b8</a>)</li> <li>Exemplify error handling (<a href="" rel="noopener noreferrer">90151d6c</a>)</li> <li>Add changelog (<a href="" rel="noopener noreferrer">4d1fc2c0</a>)</li> </ul> <h3>⚙️ Miscellaneous</h3> <ul> <li>Simplify <code>use</code>s (<a href="" rel="noopener noreferrer">51878fae</a>)</li> <li><em>(test)</em> Remove unnecessary paths (<a href="" rel="noopener noreferrer">4323b202</a>)</li> <li><code>read_mem</code> starts reading at current address (<a href="" rel="noopener noreferrer">7faad183</a>)</li> <li>(!) Rename &amp; change debugging methods of <code>Program</code> (<a href="" rel="noopener noreferrer">abd17904</a>)</li> <li>Fix spelling of <code>collinear</code> (not <code>colinear</code>) (<a href="" rel="noopener noreferrer">2e9ebd7c</a>)</li> <li>Improve changelog generation configuration (<a href="" rel="noopener noreferrer">9e3432f3</a>)</li> <li>(!) Remove <code>Default</code> derivation from <code>Program</code> (<a href="" rel="noopener noreferrer">868f49d9</a>)</li> <li>Allow tracing program execution from a given starting state (<a href="" rel="noopener noreferrer">5f702d47</a>)</li> <li>Upgrade dependency <code>cargo-tarpaulin</code> (<a href="" rel="noopener noreferrer">560f2555</a>)</li> </ul> <h3>♻️ Refactor</h3> <ul> <li><em>(examples)</em> Return program, not instructions (<a href="" rel="noopener noreferrer">55c731ed</a>)</li> <li>Improve API of <code>VMProfiler</code> (<a href="" rel="noopener noreferrer">202cb74b</a>)</li> <li><em>(vm)</em> Rename <code>ramp</code> to <code>ram_pointer</code> (<a href="" rel="noopener noreferrer">612714d0</a>)</li> <li><em>(processor_table)</em> Remove never-triggered panics (<a href="" rel="noopener noreferrer">6ced006a</a>)</li> <li><em>(processor_table)</em> Remove unused struct <code>ExtProcessorTraceRow</code> (<a href="" rel="noopener noreferrer">d39230f2</a>)</li> <li><em>(test)</em> Use crate <code>test-strategy</code> (<a href="" rel="noopener noreferrer">01e5e229</a>)</li> <li><em>(test)</em> Improve testing instruction’s transition constraints (<a href="" rel="noopener noreferrer">77948e1a</a>)</li> <li><em>(op_stack)</em> Simplify recording of op stack underflow I/O calls (<a href="" rel="noopener noreferrer">f3803676</a>)</li> <li>Turn python script for computing opcodes into a rust test (<a href="" rel="noopener noreferrer">ddb220f2</a>)</li> <li><em>(test)</em> Also test transition constraints on extension table (<a href="" rel="noopener noreferrer">4bd9cf16</a>)</li> <li><em>(test)</em> Split test program enumeration into individual tests (<a href="" rel="noopener noreferrer">cc79cfad</a>)</li> <li>Abstract over legal argument range for various instructions (<a href="" rel="noopener noreferrer">a76097e9</a>)</li> <li>(!) On success, <code>Stark::verify</code> returns <code>Ok(())</code>, not <code>Ok(true)</code> (<a href="" rel="noopener noreferrer">9d3a7065</a>)</li> <li>(!) Remove <code>terminal_state</code>, allow running a VM state instead (<a href="" rel="noopener noreferrer">fbd58f1c</a>)</li> <li>Simplify indexing into <code>OpStack</code> (<a href="" rel="noopener noreferrer">4b31b2fe</a>)</li> </ul> <h3>✅ Testing</h3> <ul> <li>Op stack table row sorting (<a href="" rel="noopener noreferrer">7418502b</a>)</li> <li>Factor for running product with Op Stack Table never panics (<a href="" rel="noopener noreferrer">224e7923</a>)</li> <li>Turn extension field instruction tests into property tests (<a href="" rel="noopener noreferrer">067d0053</a>)</li> <li>Turn <code>get_colinear_y</code> into a property test (<a href="" rel="noopener noreferrer">39bd4668</a>)</li> <li>Use <code>proptest</code>, not ad-hoc prop tests, for program parsing tests (<a href="" rel="noopener noreferrer">d2acbbf8</a>)</li> <li>Delete some ignored, obsolete tests (<a href="" rel="noopener noreferrer">8deb268a</a>)</li> <li>Instructions fail before they modify the state (<a href="" rel="noopener noreferrer">c680fab2</a>)</li> </ul> Neptune should get rid of any form of dev tax or pre-mine to pass the Howey test i2pZ7812HTZV69 2023-11-08 2023-11-08 11 <p>We all know why Monero worked so well.</p> <p>Whether its any pre-mine coin or any dev tax we all know how the free market and regulators will respond.</p> lightning replacement cycling attack. danda 2023-10-22 2023-10-22 10 <p>Perhaps something for us to be aware of. quote:</p> <blockquote> <p>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.</p> </blockquote> <p>Article: <a href="" rel="noopener noreferrer">Bitcoin core developer steps back from Lightning Network over “hard dilemma”</a></p> announcing Triton VM v0.35.0 jfs 2023-10-17 2023-10-17 9 <p><a href="" rel="noopener noreferrer">Triton VM v0.35.0</a> is now live. The main highlights are:</p> <h1>Simpler Sponge Initialization</h1> <p>Up until now, the only way to initialize the Sponge for hashing input of variable length was to use instruction <code>absorb_init</code>. 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 <code>sponge_init</code> initializes the Sponge state, (existing but renamed) instruction <code>sponge_absorb</code> does the absorbing.</p> <p>This has immediate runtime effects for the programs that are necessary for Neptune, speeding up variable length hashing by around 16%.</p> <h1>Debug Symbols</h1> <p>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 <code>break</code> 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.</p> <h1>Full Changelog</h1> <p>Note: (!) indicates a breaking change.</p> <h2>✨ Features</h2> <ul> <li>Better error reporting for failing <code>assert_vector</code> (ee83ab6d)</li> <li>Include debug information when printing <code>Program</code> (d11aa541)</li> <li>(!) Replace instruction <code>absorb_init</code> with <code>sponge_init</code> (aca87471)</li> <li>(!) Add debug instruction <code>break</code> (df6dc4b5)</li> </ul> <h2>🐛 Bug Fixes</h2> <ul> <li>(!) Use <code>Copy</code>-trait of <code>StarkParameters</code> (70f3d957)</li> <li>Linter v1.73.0 warnings (641ed393)</li> <li>Print all helper variables and Sponge state of VM state (07a54f6e)</li> <li>Disallow changing argument of <code>swap</code> to 0 (bcf61ee6)</li> </ul> <h2>📝 Documentation</h2> <ul> <li>Adapt constraints to new instruction <code>sponge_init</code> (cde031f0)</li> <li><code>Program</code> and its new methods (5ff137dc)</li> <li>Align specification to code (86a501ea)</li> <li>Delete cheatsheet (e8a5b526)</li> </ul> <h2>🔧 Miscellaneous</h2> <ul> <li>(!) Rename instruction <code>div</code> to <code>div_mod</code> (c3ad923a)</li> <li>Reduce number of <code>as</code> castings (540cf66f)</li> <li>Remove unused <code>impl Display for InstructionToken</code> (1550f8de)</li> <li>Ignore JetBrains IDE’s config files (ddf9e7ad)</li> </ul> <h2>♻️ Refactor</h2> <ul> <li>(!) Move <code>padded_height()</code> into <code>AET</code> (f88d94f3)</li> <li>Store debug information <code>address_to_label</code> in <code>Program</code> (d857e838)</li> <li>Improve readability of <code>Program</code> decoding (e3741d68)</li> <li>Extract VM profiling logic into <code>VMProfiler</code> (97ecef8d)</li> </ul> <h2>✅ Testing</h2> <ul> <li>Lower number of test cases for some FRI tests (0159a688)</li> <li>Print error of failing <code>assert_vector</code> (9bcdac2d)</li> <li>Separate success and failure of <code>ensure_eq</code> (86b97993)</li> <li>Improve property testing of Sponge instructions (e3d90b8e)</li> <li>Edge case when last Hash Table row is <code>sponge_init</code> (f5f64963)</li> <li>Too many returns crash VM, not <code>VMProfiler</code> (a109b890)</li> </ul> LIght nodes and wallet history danda 2023-10-07 2023-10-07 8 <p>I’ve been reading through some of the excellent blog posts on 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:</p> <ul> <li>The light node Z would ask another node (full, archive, etc) for the most recent (tip) block and receive it.</li> <li>Z would validate the block against known info, ie the genesis block, using magic (to me) of recursive snarks.</li> <li>Z would also ask for and receive the current utxo set. (correct? I’m guessing/assuming)</li> <li>Z would validate the utxo set against the merkle-mountain-range-accumulator in the tip block.</li> <li>Z iterates through entire utxo set to find any that match user’s keys (addresses).</li> <li>Z calculates user’s balance as sum(matching_utxo.amount). (by coin type).</li> </ul> <p>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?</p> Ossify and let the market decide. danda 2023-10-06 2023-10-06 6 <p>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.</p> <p>I was just reading the very excellent post <a href="" rel="noopener noreferrer">On the Valuation of Cryptocurrencies</a> and this line caught my attention with respect to governance:</p> <blockquote> <p>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.</p> </blockquote> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Something to think about anyway.</p> <p>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.</p> <p>But is there any alternative?</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Now I hear you saying, but what about upgrades and fixes for like, really serious bugs?!!!</p> <p>I will address this in two ways:</p> <p>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.</p> <p>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.</p> <p>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. </p> <p>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.</p> <p>We leave Gibraltar code unchanged. Nodes can continue running forever, conducting transactions.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>So wrapping up and bring this back to Neptune Cash.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> Receiving paper wallet funds. danda 2023-10-06 2023-10-06 7 <p>I was just reading about <a href="" rel="noopener noreferrer">Paper Wallets</a> in Neptune. It states:</p> <blockquote> <p>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.</p> </blockquote> <p>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.</p> <p>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.</p> <p>&lt;rant&gt; 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. &lt;/rant&gt;</p> <p>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.</p> <p>I’d be happy to work on such a feature at some point, if its agreed to be a good idea.</p> How to avoid losing funds sword_smith 2023-08-09 2023-08-09 3 <p>We’ve all heard the stories about people losing or throwing away their Bitcoin. Let’s at least attempt to avoid this with Neptune!!</p> <p>Neptune Core stores cryptographic data in two files: <code>wallet.dat</code> and <code>incoming_randomness.dat</code>.</p> <p>The short version is that you need to back up your <code>wallet.dat</code> only once, and the <code>incoming_randomness.dat</code> each time you receive a transaction. Both these files are located in your data directory, which can be found in <code>~/.local/share/neptune/&lt;network&gt;/wallet/</code> 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 <code>neptune-core</code>.</p> <p>The <code>wallet.dat</code> file never changes, but the <code>incoming_randomness.dat</code> gets a new line every time you receive or mine a transaction!</p> <p>So to be safe, you need to back up <code>wallet.dat</code> <em>and</em> you need to back up <code>incoming_randomness.dat</code> with each transaction that you receive. Provided these two files are backed up correctly, you will not lose any funds. <code>wallet.dat</code> should be backed up to a media that’s not connected to the internet, and <code>incoming_randomness.dat</code> should be backed up with a solution that can sync the file over a secure network. </p> <p><strong>For each transaction you receive, you need to update your backup of <code>incoming_randomness.dat</code>.</strong></p> <p>To elaborate a bit on this, <code>wallet.dat</code> 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.</p> <p><code>incoming_randomness.dat</code> contains the <a href="" rel="noopener noreferrer"><code>sender_randomness</code></a> which is a component that keeps your transactions private. The <code>sender_randomness</code> is a component of the <code>canonical_commitment</code> which constitute the leafs of the append-only commitment list that is a part of the “mutator set” data structure.</p> <p>Rule of thumb for Neptune security</p> <ol> <li>If someone sees your <code>wallet.dat</code> they take your coins</li> <li>If someone sees your <code>incoming_randomness.dat</code> they can identify your transactions</li> <li>If you lose your <code>wallet.dat</code>, you lose your coins</li> <li>If you lose your <code>incoming_randomness.dat</code>, you lose your coins.</li> </ol> When does the ICO start? Neptuneum 2023-09-13 2023-09-13 5 <p>When does the ICO start? When does the ICO start? When does the ICO start? </p> alphanet-v3 sword_smith 2023-08-09 2023-08-09 2 <p>Alphanet v3 has been pushed to GitHub and is up and running.</p> <p>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 <code>BFieldCodec</code>.</p> <p>Since alphanet coins are worthless and alphanet-v3 is a restart of the blockchain from genesis, you can simply reset you node by running <code>rm -rf ~/.local/share/neptune/</code> 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:</p> <p>So, to update, the following commands should do it:</p> <ul> <li>First navigate to the directory, where you have the <code>neptune-core</code> git repo stored. Then:</li> </ul> <pre style="background-color:#ffffff;"><span style="color:#323232;">rm </span><span style="font-weight:bold;color:#a71d5d;">-</span><span style="color:#323232;">rf </span><span style="font-weight:bold;color:#a71d5d;">~/</span><span style="color:#323232;">.local</span><span style="font-weight:bold;color:#a71d5d;">/</span><span style="color:#323232;">share</span><span style="font-weight:bold;color:#a71d5d;">/</span><span style="color:#323232;">neptune</span><span style="font-weight:bold;color:#a71d5d;">/ </span><span style="color:#323232;">git pull </span><span style="color:#323232;">cargo install </span><span style="font-weight:bold;color:#a71d5d;">--</span><span style="color:#323232;">path . </span><span style="color:#0086b3;">RUST_BACKTRACE</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#0086b3;">1 RUST_LOG</span><span style="font-weight:bold;color:#a71d5d;">='info</span><span style="color:#323232;">,tarpc</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#323232;">warn</span><span style="font-weight:bold;color:#a71d5d;">'</span><span style="color:#323232;"> neptune</span><span style="font-weight:bold;color:#a71d5d;">-</span><span style="color:#323232;">core </span><span style="font-weight:bold;color:#a71d5d;">--</span><span style="color:#323232;">mine </span><span style="font-weight:bold;color:#a71d5d;">--</span><span style="color:#323232;">throttled</span><span style="font-weight:bold;color:#a71d5d;">-</span><span style="color:#323232;">mining </span><span style="font-weight:bold;color:#a71d5d;">--</span><span style="color:#323232;">peers </span><span style="color:#0086b3;">51.15</span><span style="color:#323232;">.</span><span style="color:#0086b3;">139.238</span><span style="color:#323232;">:</span><span style="color:#0086b3;">9798 </span><span style="font-weight:bold;color:#a71d5d;">--</span><span style="color:#323232;">peers </span><span style="color:#0086b3;">139.162</span><span style="color:#323232;">.</span><span style="color:#0086b3;">193.206</span><span style="color:#323232;">:</span><span style="color:#0086b3;">9798 </span></pre> <p>Please note that you normally do <strong>not</strong> want to delete your <code>wallet.dat</code>, <code>incoming_randomness.dat</code>, and <code>outgoing_randomness.dat</code> files. Basically, you should <strong>normally</strong> never delete anything in your <code>wallet</code> directory.</p> How to use this forum aszepieniec 2023-08-07 2023-08-07 1 <h2>Software</h2> <p>This forum is running an instance of <a href="" rel="noopener noreferrer">freedit</a>, which is a lightweight forum based on rust and Javascript-free. The setup is similar to reddit, with inns (subreddits) and feeds, and upvoting.</p> <h2>Getting Started</h2> <p>To get started, you might want to subscribe to:</p> <ul> <li><a href="" rel="noopener noreferrer">Neptune</a></li> <li><a href="" rel="noopener noreferrer">Triton VM</a></li> </ul> <h2>Formatting</h2> <p>Freedit supports both <a href="" rel="noopener noreferrer">Markdown</a> and LaTeX, although the second one requires a special syntax to active:</p> <ul> <li>inline math with by writing the familiar dollar signs inside of an inline code snippet using backticks: </li> </ul> <pre style="background-color:#ffffff;"><span style="color:#323232;">`</span><span style="font-weight:bold;color:#a71d5d;">$</span><span style="color:#323232;">\sum_{i</span><span style="font-weight:bold;color:#a71d5d;">=</span><span style="color:#0086b3;">0</span><span style="color:#323232;">}</span><span style="font-weight:bold;color:#a71d5d;">^</span><span style="color:#323232;">\infty \frac{</span><span style="color:#0086b3;">1</span><span style="color:#323232;">}{i</span><span style="font-weight:bold;color:#a71d5d;">^</span><span style="color:#0086b3;">2</span><span style="color:#323232;">}</span><span style="font-weight:bold;color:#a71d5d;">$</span><span style="color:#323232;">` </span></pre> <p>gives <math><munderover><mo>∑</mo><mrow><mi>i</mi><mo>=</mo><mn>0</mn></mrow><mi>∞</mi></munderover><mfrac><mn>1</mn><msup><mi>i</mi><mn>2</mn></msup></mfrac></math></p> <ul> <li>to write newline math, embed the LaTeX code into a code snippet with triple-backticks, and mark the language as “math”, e.g.</li> </ul> <pre style="background-color:#ffffff;"><span style="color:#323232;">```math </span></pre>