23 Nov 2023 [CT] [guides]

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 incident1 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 CCS2 system first, with its flaws and fortes:

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

<CCS>
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 ideas3 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):

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

<CCSv2>
[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:

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

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:

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

System Pros Cons
CCSv2 (3RA) +easy, no 3rd party, security, privacy by default -shift in perception
Direct funding +no 3rd party, security, privacy minus viewkey -burden on proposers, backend
CCSv1 (multisig) +potential security, privacy minus intermediary -experimental, hard, custodians
Close CCS +easy, no 3rd party, security, privacy by default -shift in perception
CCSv1 (new custody) +easy, privacy minus intermediary -hard to secure, custodians
Pledge systems +potential security, privacy -burden on donors/proposers, hard

Observations

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

  1. /luigi-discloses-critical-ccs-wallet-breach/ ↩

  2. https://ccs.getmonero.org/ ↩

  3. https://paste.debian.net/1298653/ ↩

  4. /fluffypony-resigns-monero-core-team-after-decade/ ↩

  5. /tag/calendar/ ↩