New Year, New Possibilities. Blue Sky suggestions welcome.

⚓ Neptune 📅 2024-01-14 👤 danda 👁️ 594

Warning

This post was published 112 days ago. The infomation described in this article may have changed.

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.

🏷️ bluesky, architecture, asic, evm, bip39, lightmode

👍 󠁮󠁮󠁮󠁮 2 👎 󠁮󠁮󠁮󠁮

aszepieniec 2024-01-21 👍 2 👎

bip39 mnemonic support.

✓

aszepieniec 2024-01-23 👍 👎

plugin interface. Neptune was designed to support smart contract protocols via opt-in overlay protocols that do not affect users that do not opt in. To opt in, users should install third-party app software that runs on the same machine as neptune-core but communicates with it through a RPC interface.

aszepieniec 2024-01-24 👍 2 👎

block/tx explorer. An HTTP server that plugs into neptune-core and displays information like block height, block digest, # addition records, # removal records, variable network parameters such as difficulty, node address (?). On top of that it allows the user to lookup blocks and transactions.

aszepieniec 2024-01-24 👍 👎

authenticated peers. Give a presentation somewhere. Close the slide deck with a QR code that contains your node’s address and public key hash. Or put the QR code on your business card. Folks who connect to this address+pubkey know that they are connected to the right network. Also, connections to this peer can be encrypted without fear of man-in-the-middle.

aszepieniec 2024-01-24 👍 1 👎

Tor. Consisting of two parts: (a) Tor (onion) addresses which work well with authenticated peers to ensure that new entrants are connecting to the right network. (b) Nodes should have the option of routing all of their peer-to-peer traffic over Tor.

aszepieniec 2024-01-27 👍 👎

Block fingerprints. An often recurring task is finding out whether block A is a descendant of block B, or whether they live on different forks. There is an expensive but robust way to do this: walk back and compare predecessor. Here is a probabilistic way that is much cheaper and has small false positive rate and zero false negative rate. Every block is stored along with $k$ u64s called its fingerprint, which is reminiscent of a Bloom filter. Relative to its predecessor, every element in this array differs by either 0 or 1. The locations that are incremented depend on the block’s hash. In order to compare two blocks we subtract their filters as vectors. If the difference contains a negative number, then for certain B is not a descendant of A. If not, then it probably is. The exact probability depends on the length of this vector, $k$.

danda 2024-01-30 👍 1 👎 [op]

i2p. Bitcoin and monero both support connecting via i2p now. Makes a nice alternative for Tor.

aszepieniec 2024-01-31 👍 👎

minisketch. Minisketch is a set reconciliation protocol. Two peers each hold an a priori distinct set of data records, but they both want to know the union of their respective sets. How do they find out, using the least amount of bandwidth, which records they need to send and which the counterparty already has? Minisketch solves this problem. In a blockchain context, records could be blocks, or transactions, or even something else.

i2pZ7812HTZV69 2024-02-18 👍 👎

this is the correct way to go for this project

danda 2024-02-22 👍 👎 [op]

minisketch-rs is a rust wrapper crate for the minisketch c/c++ library.

aszepieniec 2024-02-23 👍 👎

space-efficient mempools. Add a consensus rule allowing mempool operators to throw away all transaction validity proofs in exchange for one mempool validity proof. Specifically, add rule (e) to the following list of criteria for transaction validity. A transaction is valid if (any criterion suffices):
- a) it has a valid witness (including spending keys and mutator set membership proofs) (note that a (transaction, valid witness) pair cannot be broadcasted because that would undermine both soundness and privacy)
- b) it has valid proofs for each subprogram (subprograms establish things like the owners consent to this transaction, there is no inflation, etc.)
- c) it has a single valid proof that merges all of the above proofs into one
- d) it has a single valid proof that the transaction originates from merging two valid transactions
- e) it has a single valid proof that the transaction belongs to an integral mempool, i.e., one to which only valid transactions were added.

danda 2024-03-03 👍 👎 [op]

veilid seems to be an improvement on tor (and i2p) for hiding IPs with app-configurable number of hops, and is written in rust, so integration should be clean and easy.

https://veilid.com/docs/private-routing/

i2pZ7812HTZV69 2024-04-01 👍 👎

yea both tor with its rust implementation Arti along with i2p devs want to introduce a rust client and now veilid entirely created in rust all 3 options will be great for Neptune

i2pZ7812HTZV69 2024-04-01 👍 👎

while we are at it why not add dandelion++ and noise protocol with post quantum crypto for node protection and privacy

danda 2024-05-03 👍 👎 [op]

I will throw out a wild idea.

It was recently suggested on reddit for someone to hard fork bitcoin by adding real privacy features to it. This was just a one-off comment, not a serious proposal, but it got me thinking/wondering.

Instead of adding features to bitcoin, could we flip this idea on its head?

Would it be possible to launch neptune (or a fork) by somehow importing all of bitcoin’s utxos up to a certain point/snapshot?

If this could be done, it essentially makes the neptune codebase a bitcoin hard-fork. There are a lot of bitcoiners that want better privacy and the quantum resistance and scalability features are desirable as well. So I think that such a hard-fork could have a real shot at success where others have failed.

For the neptune project, it would mean that there is instantly huge worldwide distribution and that anyone who holds bitcoin also becomes a neptune stakeholder, incentivized to try out neptune. Many would immediately sell their newfound wealth, but eventually that stabilizes and then bitcoiners are left with a blockchain where they can transact their pre-existing holdings privately. Those holdings would be worth much less on the new blockchain, so it’s kind of a privacy playground for bitcoiners.

The consensus rules would not necessarily have to be the same as btc. For example, the supply cap could be a bit larger than bitcoin’s to allow for neptune development obligations. Some people would not like that, but so long as everything is clear, many would accept it as fair tradeoff for real privacy and improved scalability.

For now I’m totally hand-waving how this might be done. But if it can be done, I imagine someone probably will do it eventually. Whether its the neptune project or a 3rd party.

danda 2024-05-03 👍 👎 [op]

clafification: in the above comment, I meant to be suggesting to import a snapshot of btc utxo’s at a certain point (time of neptune launch), with a digest of the snapshot embedded in neptune’s genesis block. I did not mean to imply importing the entire btc blockchain somehow.

i2pZ7812HTZV69 2024-05-04 👍 👎

i can be more convinced by the fact that if a hard fork ever happen in btc it will be for confidential transaction at base layer and post-quantum public-privacy key pair replacement for ECDSA public-private keys.