Brainstorming: how the community can help

[aszepieniec]

@LostInTranslation

Would also appreciate input from Alan

Seems like you have a lot of things that might come to mind covered already, and besides @danda’s suggestions there is very little left to add. Here are some items if I may be bold enough to suggest:

• video tutorials
• animated explainers
• plug-ins: into BTCPayServer and alternatives, umbrel, browsers
• plug-ins into neptune-core: IRC, games, smart contracts
• reproducible builds
• installers

@LostInTranslation

Monero community has successfully used crowdfunding for many years. Supporters can contribute to a general fund, and community members are also able to propose specific pieces of work with a pre-agreed funding goal. This model has helped ensure that development remains community-driven, transparent, and sustainable.

The more I read about Monero’s CCS, the more I love it. I think this should be the guiding template for transitioning Neptune Cash towards a community-driven and community-funded project. And I will do what I can to support that transition.

@danda

NeptuneCash addresses presently do not implement true multi-sig. There is samir secret sharing in neptune-cli for distributing pieces of an existing key, but that requires that all parties trust whoever first generates the key. Perhaps a CCS system could be implemented as a type of smart-contract where funds are pooled and only released on certain conditions. That is outside my area though, @aszepieniec do you see anything preventing this at present or have thoughts about it?

Nothing is blocking such a system presently besides the engineering workload. Let me put some words to how you might design a fund managed transparently by an anonymous rotating committee with t-out-of-n multisig.

The way I see this work is through an overlay protocol. The fund managers must run a node with a plugin for managing that fund, say neptune-foundation which is a separate process from but in communication with neptune-core. The plugin is responsible for establishing connections to other fund managers; disseminating information related to transactions before and after they are initiated, and presenting individual managers with an interface.

The treasury lives in a UTXO whose lock script allows anyone to spend. Besides a NativeCurrency type script (or really, any currency type script) there are other type scripts:

• One type script enforces that whenever the UTXO is spent, the transaction produces at least one output UTXO, called the successor, that has the same set of type scripts (or a superset) and the same lock script.
• One type script enforces that whenever the UTXO is spent, the transaction comes with an announcement exposing the successor’s type scripts, states, lock script hash, sender randomness, and receiver preimage. This exposure serves the dual purpose of transparency (since anyone can inspect the UTXO) and notifying the fund managers of the new UTXO data.
• One type script enforces that if the successor holds fewer funds than the current UTXO, then there exist signatures on the transaction kernel MAST hash that are valid under at least t out of n public keys. The public keys’ hashes are stored as the state for this type script, and can therefore be modified when the UTXO is spent and re-generated. Also, if this list of public keys changes, then there are also t valid signatures.

This type of overlay protocol / smart contract can be used for more than just managing a community fund transparently. It can also be used for a bridge to another cryptocurrency, at least until a fully trustless version can displace it.