CT-017: Rethinking the Monero CCS: A cypherpunk proposal

This is the 17th report in the Cypherpunk Transmission series.

WiP: contact me (escapethe3RA) to propose edits.

Motivation

The recent Monero CCS incident¹ has highlighted the real need to restructure the existing community crowdfunding system. Reaching consensus and fixing this outstanding issue sooner rather than later is important for the Monero project as a whole.

Assumptions

Any community is built upon certain ideals. Monero is powered by a cypherpunk ‘engine’: our permissionless meetings and funding systems are key as they help us reach consensus and fuel our ecosystem. Anonymity is our strength and we can leverage it to create and maintain robust projects.

1. The status quo

Let’s look at an overview of the current CCS² system first, with its flaws and fortes:

• Ideas stage: anyone can submit a proposal to do some work related to Monero.
• Consensus stage: anyone can participate in the consensus mechanism by joining regular meetings focused on discussing proposals at the ideas stage.
  • A proposal can be discussed in multiple meetings if consensus is that revisions are necessary.
  • Previous contributors and/or proposers that have already completed proposal milestones pre-funding usually attract more support from the community.
  • New, unknown proposers without any previous work or reputation usually attract more scrutiny and might be asked to complete some of their proposed milestones in advance in order to prove their skills.
  • If consensus cannot be reached, proposals will be closed eventually.
  • Proposers can decide to temporarily or permanently cancel their proposals at this stage.
  • Proposers can resubmit new/revised proposals at any time.
• Proposals move to the funding stage when consensus is reached.
  • Anyone can donate anonymously to proposals listed on the funding page.
    • Funds donated for each proposal are held in wallets that are in the custody of Core members.
    • Excess funds are either reallocated to other proposals or moved to the General Fund wallet.
  • It is very rare that proposals are not fully funded once they are listed on the funding page.
    • Core can occasionally step in to fund some ‘critical’ proposals from the General Fund wallet.
• Proposals move to the work started stage some time after fully funded.
  • Proposers can post status updates for each milestone.
  • Community reviewers discuss proposal updates in regular meetings.
  • Proposers can request funds to be released after completing milestones.
• Proposals move to the completed stage after all milestones are completed/paid.
  • If proposers do not request funds after completing proposals, funds remain in Core wallets indefinitely.

Here is how the process might look like from the perspective of all involved parties – proposers, reviewers, donors, and custodians:

Proposers:
 - Anon: Yes.
 - Receiving funds: Easy. 
 - Funding guaranteed: No.
 - Liability: Not if anon.
Reviewers/Community:
 - Anon: Yes.
 - Liability: No.
Donors: 
 - Anon: Yes.
 - Donating: Easy.
 - Delivery guaranteed: No.
 - Liability: Not if anon.
Custodians: 
 - Anon: No/Pseudo.
 - Custody: Hard.
 - Liability: Yes.

It is pretty clear why the CCS has been working ‘fine’ for years with its current architecture: anyone can participate anonymously, no need for proposers to set up and maintain funding systems, and there’s a quick and easy private donation path for everyone without the need to attend meetings – if it’s on the funding page, consensus has already been reached and the proposal was vetted by the community.

It is also obvious why the system was doomed to eventually fail: centralized 3rd party custody of funds. The CCS incident affected the public image of Monero negatively and also exposed the custodians, which are not anonymous, to further unnecessary personal risks.

2. Possible ways forward

Since the recent public disclosure, several ideas³ on the future of the CCS started floating around in the community. Unfortunately, most of them involve some kind of custody system, increased architectural complexity, and even some privacy sacrifices.

Although not full proposals, I believe it is important to briefly mention those ideas in this section and add my comments in bold:

buddy system / adopt a dev – a trusted third party will custody the funds and every proposal would have a different wallet (which is basically direct funding) [-3rd party custodians, -Extra complexity]

direct funding – advertise indivudual crowdfunding pages on the CCS funding required page (e..g kuno/btcpayserver/xmrstarter/monerofund/wishlist) [-Burden on proposers to maintain self-hosted payment systems]

multisig – 2/7 main wallet with a smaller hot wallet for convenient payouts. (hot wallet would require upwards of 600 xmr , possibly >1500xmr if payments are delayed by 2~3 months) [-MultiSig is experimental, -3rd party custodians, -Extra complexity]

many multisig wallets – using RINO for convenience, multisig wallets can be cycled once their balance reaches a certain amount so we never have 2600 xmr in one pot (if we ignore 9000~ sitting in the general fund) [-MultiSig is experimental, -3rd party custodians, -Extra complexity]

same setup as before but better – the main wallet is offline / never hot. file transfer method being the main attack vector, so optical data transfer is preferred e.g. via animated QR codes but we need to know if the implementation is secure. the “hot wallet” used for convenient payouts is now a hardware wallet. – [-MultiSig is experimental, -3rd party custody, -Extra complexity]

security through obscurity to protect against physical attacks – an unknown contributor(s) will custody the funds to reduce the threats on the individual and/or exact details of the security are kept hidden and certified “better than what we where doing before” [-3rd party custodians]

pledges systems [-Burden on donors and potentially on proposers, -Extra complexity]

keep status quo but w/ ‘better’ custodian setups (OPSEC/MS) [-3rd party custodians, -MultiSig is experimental]

These are just ideas, incomplete thoughts, and without further details and perhaps some systematic proposals, it is unclear if they would work in real life and how long it would realistically take to implement them.

3. A cypherpunk proposal

Note that this is a draft and feedback is encouraged.

A single alteration in how we view the system could push us forward in a cypherpunk direction: make proposers the ‘custodians’ without forcing them to self-host any payment systems.

Here’s how the new CCS would look like (changes in bold/strike):

• Ideas stage: anyone can submit a proposal to do some work related to Monero.
• Consensus stage: anyone can participate in the consensus mechanism by joining regular meetings focused on discussing proposals at the ideas stage.
  • A proposal can be discussed in multiple meetings if consensus is that revisions are necessary.
  • Previous contributors and/or proposers that have already completed proposal milestones pre-funding usually attract more support from the community.
  • New, unknown proposers without any previous work or reputation usually attract more scrutiny and might be asked to complete some of their proposed milestones in advance in order to prove their skills.
  • If consensus cannot be reached, proposals will be closed eventually.
  • Proposers can decide to temporarily or permanently cancel their proposals at this stage.
  • Proposers can resubmit new/revised proposals at any time.
• Proposals move to the funding stage when consensus is reached.
  • Anyone can donate to proposals listed on the funding page.
    • Funds donated for each proposal are held in wallets that are in the custody of Core members.
    • Funds donated for each proposal are sent directly to the wallets of the proposers.
    • Excess funds are either reallocated to other proposals or moved to the General Fund wallet.
    • Excess funds are considered a bonus for the already underpaid proposers.
  • It is very rare that proposals are not fully funded once they are listed on the funding page.
    • Proposals remain on the funding page only for a preset number of days [~14/consensus] before being moved to the work started stage.
    • Proposers have the option to ask for a relisting on the funding page within a preset number of days after being moved to work started stage if they are not fully funded. This can be verified by the community using the viewkey provided by proposers.
    • Core can occasionally step in to fund some ‘critical’ proposals from the General Fund wallet.
• Proposals move to the work started stage after the preset number of days [~14 days/consensus].
  • Proposers can post status updates for each milestone.
  • Community reviewers discuss proposal updates in regular meetings.
  • Proposers can request funds to be released after completing milestones.
• Proposals move to the completed stage after all milestones are completed.
  • If proposers do not request funds after completing proposals, funds remain in Core wallets indefinitely.

Just by removing intermediaries, the attack surface has contracted considerably:

[NEW]
Proposers = Custodians:
 - Anon: Yes. (proposers are custodians)
 - Liability: Not if anon. (no extra burdens)
 - Custody: Easy. (decentralized)
 - Funding guaranteed: No. (same as before)
 - Receiving funds: Easy. (same as before)
[UNCHANGED]
Reviewers/Community:
 - Anon: Yes. (same as before)
 - Liability: No. (same as before)
Donors: 
 - Anon: Yes. (same as before)
 - Donating: Easy. (same as before)
 - Delivery guaranteed: No. (same as before)
 - Liability: Not if anon. (same as before)

Here are some of the pros of this version of the CCS:

• easy, fast implementation due to a simplified architecture – proposers just need to include an XMR address in their proposals, backend changes should be minimal to the existing CCS (no reliance on experimental multisig, no reputation systems, no viewkey scans, no need to build complex platforms/features)
• no 3rd party custodians, no centralization of funds – not adding any extra attack vectors by holding most funds in a single wallet, or recruiting extra people and exposing them to personal risks
• no extra burden of any type on donors or proposers – everyone can easily work and donate anonymously without worrying about anything really (management, legal, etc)
• no centralized security worries for the project – everyone is responsible for securing their own wallets, like in real life, which most of us are already doing anyway
• no forced privacy loss – everyone is private by default, but proposers can opt to share their viewkey in order to prove their proposals were not fully funded during the first round (fits perfectly with how Monero works: private by default, optionally transparent)

And here are some of the potential (perceived) cons:

• proposers could ‘run with the funds’ before completing proposals
• there is no donation progress bar on the funding required page

The first point does not really apply to known contributrs and could be easily solved for new/unknown proposers by adding slightly more scrutiny to their proposals at the consensus stage. Totally anonymous new proposers without any previous work and street cred could easily prove themselves by completing one or more of their project milestones in advance. Even if they do decide to disappear after funded, the community still gets something in return.

Assuming a simple scenario:

• Proposer A (anonymous, new, no previous work) submits proposal to develop X functionality in 3 milestones for 150 XMR (50×3).

• Community could ask for milestone 1/3 to be completed first (before funding).

• Proposer A agrees and completes milestone 1.

• Community reviews work and greenlights the proposal for funding but only for milestone 2 (50 XMR).

• Proposer A edits minimum funding required (only for milestone 2).

  Sponsored

• Proposal is moved to funding required stage for [~14 days/consensus] and then to work started stage.

• Proposer does not ask for extra funding within [~7 days/consensus] and community considers proposal fully funded.

• Proposer A completes milestone 2.

• Community reviews work and greenlights the proposal for funding for the final milestone 3 (50 XMR). [..]

• Proposer A returns with a new similar proposal after some time, but is now considered a ‘known contributor’ due to previous work that was completed successfully.

• Community could agree to greenlight this second proposal for funding for 1 milestone (or more). [..]

Note that the proposer can only run with a maximum 1/3 of funds at any point, which is 50 XMR. However, the community still gets >50 XMR worth of work: if proposer quits before shipping M2, community gets to keep M1 work (50 XMR worth); if proposer quits before delivering M3, community gets to keep M1+M2 work (100 XMR worth).

The second point is really only a change in perspective and should not influence the process any. All donors contribute mainly because they want to help Monero and if they see 100 XMR minimum funding goal, they might donate once or more than once, the full amount, or less. It’s up to them. Some bigger donors might ask themselves why the project was not yet moved to the work started stage after they donated 100% of the goal. A simple explainer sentence and a timer [Proposal will be moved to Work Started in X days] replacing the progress bar should suffice.

The fact that any extra funds would go to the original proposers could also help solve our ongoing ‘starving devs’ situation and potentially encourage others to start contributing.

The proposal essentially removes the necessity for big centralized wallets which are primary targets to protect, fixes our ‘unclaimed funds’ issue, all without requiring the whole bureaucracy that other ideas demand by introducing unnecessary extra cogs and third parties into the system.

This revised CCSv2 could fit perfectly in the middle of our existing systems, somewhere between fully decentralized self-hosted funding systems and KYC/fiat/legal foundations a la MAGIC Monero Fund. As before, this can not be the perfect fit for all, but it’s an option which should at least be tested for a period of time. More choices is usually a good thing. Let’s not push the CCS on either extreme ends of the spectrum.

4. Comparison table

Note: this is sorted from ‘best’ to ‘worst’ options in my view (3RA).

Observations

• credits to: plowsof for compiling and sharing the list of ideas floating around in the community for the past few weeks, everyone for suggesting/discussing them on various channels, and the anons for encouraging me to publish this report
• luigi has more than once publicly expressed his desire to move away from Core responsibilities
• fluffypony recently resigned⁴ from Core after several threats of physical harm, underlining the importance of having anonymous contributors
• bF has repeatedly asked the community to put forward ideas, plans and proposals for solving issues related to the existence of Core (centralization of funds, liabilities legal and otherwise), hinting at the permissionless nature of the project
• note that this is just a draft proposal and I expect edits, suggestions, feedback, counterproposals, and for this to be discussed in future community meetings⁵

Onward.

Feedback

Let me know if you find this helpful and, depending on interest, I will do my best to create more Cypherpunk Transmission reports in the future.

Questions, edits and suggestions are always appreciated @ /about/.

-3RA

PS: apologies for not making this report more compact and for any potential errors – did not have time to quadruple check as I usually do, but considered that the timing is important in this case (please send edits).