New Year, New Possibilities. Blue Sky suggestions welcome.

โš“ Neptune    ๐Ÿ“… 2024-01-14    ๐Ÿ‘ค danda    ๐Ÿ‘๏ธ 1240      

danda

Warning

This post was published 342 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

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.
3

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.
4

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.
5

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.
6

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$.
7

danda    2024-01-30 ๐Ÿ‘ 1 ๐Ÿ‘Ž [op]

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

8

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.
9

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.
12

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

14

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.

16

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.

17

i2pZ7812HTZV69    2024-05-09 ๐Ÿ‘ ๐Ÿ‘Ž

i can be more convinced if btc ever get hard fork it will be for confidential transaction at base layer and/or for removing ECDSA public-private key pair with post quantum public-private key pair

19

danda    2024-10-03 ๐Ÿ‘ ๐Ÿ‘Ž [op]

Miner Block Header Signing (to prevent mining pools)

wownero in 2021 made a hard-fork that requires miners to sign each block-header (with nonce) before hashing. When starting wownerod, miners must supply a signing-key. As I understand it, this strongly disincentivizes mining pools because the only way to pool resources would be for the pool to combine secret keys of all participants but individual miners donโ€™t trust the pool enough to do that. I might have details wrong, but anyway, it seems to be working as wownero pool mining ended in 2021 and hasnโ€™t yet returned.

It was proposed that miners would have to:

  • Select a nonce value.
  • Sign the block header using the secret spend key from the coinbase transaction.
  • Append the signature to the block header.
  • Calculate a RandomX hash of the long block header.
  • Check if the hash is below the target. If not, go back to step 1.

The final algo may be a bit different. I didnโ€™t read through the code.

I couldnโ€™t find very much info about it, but hereโ€™s some relevant links:

Blog: Wownero - No more pool mining! https://www.cryptunit.com/newsid/179-wownero-no-more-pool-mining

Miner block header signing pull-request: https://git.wownero.com/wownero/wownero/pulls/369

โ€œMega-pool Cockblocking Strategiesโ€ https://git.wownero.com/wownero/meta/issues/28

Wownero Junkie Jeff v0.10.0.0 release announcement https://git.wownero.com/wownero/wownero/releases/tag/v0.10.0.0

20