Monero v15 hard-fork planning

[sethforprivacy]

Now that we've semi-finalized the plan for the next hard-fork of Monero, and now that it's clear Triptych is a no-go and Seraphis is still some time off, I wanted to create this issue to start finalizing our plans for the next hard-fork/network upgrade for Monero.

General info

• Release version: v0.18.0
  • https://github.com/monero-project/monero#scheduled-software-upgrades
• Release name: "Fluorine Fermi" Release name for 0.18 #623
• Hardfork version: v15
  • https://github.com/monero-project/monero#scheduled-software-upgrades

Primary features included

• Ring-size increase from 11 to 16 (Bump ring size to 16 for v15 monero#8178)
  • Increase ringsize for Monero v15 research-lab#79
• View tags by @jberman (Add view tags to outputs to reduce wallet scanning time monero#8061)
  • Reduce scan times with 1-byte-per-output 'view tag' research-lab#73
• Fee changes from @arcticmine (Fee changes from ArticMine monero#7819)
  • Reduce minimum fee variability research-lab#70
• Bulletproofs+ (Bulletproof+ by sarang, tied to consensus monero#7170)
  • https://www.getmonero.org/2020/12/24/Bulletproofs+-in-Monero.html

Potential features

• Output binning changes by @jberman (may not require HF)
  • Wallet-side "binning" PoC for decoy selection algo research-lab#88
• Multisig refactor and vulnerability fix by @UkoeHB (may not require HF)
  • Monero Multisig for HF monero#8237
• Daemon connection fixes (does not require HF)
  • connection: fix implementation monero#7760
• Optimize wallet RPC calls from 3 to 1 call (does not require HF)
  • wallet2, RPC: Optimize RPC calls for periodic refresh from 3 down to 1 call monero#8076
• Faster value conveyance to wallets (does not require HF)
  • wallet: faster value conveyance via five various velocity advances monero#8046

Suggested time-frame

Suggested Dates

• Branch/feature complete: May 16th, 2022
• Release date: June 16th, 2022
• Testnet hard-fork: May 16th, 2022
• Stagenet hard-fork: TBD
• Mainnet hard-fork: July 16th, 2022, block 2668888

Release checklist

#690

[SamsungGalaxyPlayer]

March seems extremely late for the currently-listed items.

[sethforprivacy]

March seems extremely late for the currently-listed items.

I'm all for sooner if we can get it done with proper code freeze and notifications to ecosystem participants before then.

The other consideration is "lost time" due to holidays in the US and abroad over the next 6wks or so.

[luigi1111]

I'm good with March target. What are people's thoughts on freeze date lead time?

[sethforprivacy]

I'm good with March target. What are people's thoughts on freeze date lead time?

I would say 30d like we have done in the past? But obviously open to input.

[selsta]

30d before hardfork is when we want to release binaries, ideally 60 days before a freeze.

[selsta]

I would like to add monero-project/monero#7760 to the list, it fixes a lot of the daemon issues and is well tested, bit it isn't fully reviewed yet.

[sethforprivacy]

I would like to add monero-project/monero#7760 to the list, it fixes a lot of the daemon issues and is well tested, bit it isn't fully reviewed yet.

Does this require HF, or should/could it be included in a point release prior?

[selsta]

Does not require a HF.

[sethforprivacy]

I'll add as a possible one, we can discuss further in a future meeting whether it should be done before this HF or as part of it. I know some daemon changes are better off being done in a HF to ensure everyone is running them at once.

[Rucknium]

Someone asked me on Reddit whether OSPEAD needs a hard fork. My response:

No. Right now decoy selection is not enforced by blockchain consensus in any way. A hard fork is only required for consensus changes. There are specific reasons why we may eventually want to enforce a decoy selection algorithm at the consensus level, however.

For now, wallet software does decoy selection. This, itself, can cause problems since some wallet software does it in a way that harms user privacy. Now, it is for this very reason that it could be advantageous to implement OSPEAD at the same time as a hard fork, since it can "force" an upgrade in wallets that follow the Monero reference wallet, i.e. the Monero GUI wallet.

However, the hard fork itself can be useful for gathering statistical, aggregate data on the decoy system since ring size will rise from 11 to (likely) 16. As a result, ArticMine suggested that I leverage the hard fork to help develop OSPEAD. I included this suggestion in my CCS proposal:

The upcoming hard fork, which does not yet have a fixed date, will include an increase in the ring size. The discontinuity that the hard fork creates can be leveraged to better understand how ring signatures work in pratcice on the Monero blockchain. Therefore, some of the research work will occur after the hard fork.

[BlackRock-INC]

February would be a ideal date, good luck guys.

[moneroexamples]

That's nice. Are all these changes already merged in monero's master branch? Also are these changes already on testnet?

[SChernykh]

What exactly is meant by "code freeze"? Feature freeze and the creation of v0.18 branch? Because not allowing bug fixes would be stupid. 60 days from now is January 19th, so we're already tight on schedule.

[luigi1111]

What exactly is meant by "code freeze"? Feature freeze and the creation of v0.18 branch?

Correct. I would like to propose January 15th for branch/feature complete, with target fork March 15th.

[sethforprivacy]

What exactly is meant by "code freeze"? Feature freeze and the creation of v0.18 branch?

Correct. I would like to propose January 15th for branch/feature complete, with target fork March 15th.

That time frame seems very reasonable considering the key features are already PR'd (except ring size, which is a very minor PR).

[erciccione]

Dev meeting to make it official?

[sethforprivacy]

Dev meeting to make it official?

Yes, that would be ideal and I've requested someone to run it in #monero-dev but have gotten no takers. I'll try to run it if I can, but I cannot do so during business hours and weekends are focused on family.

It would be great if someone else could schedule and facilitate a dev meeting to walk through this planning and set more firm next steps.

[sethforprivacy]

A meeting has been proposed for 17:00UTC on November 28th by monerobull in Matrix -- any objections, or would that work?

[Rucknium]

Would it make sense to seriously consider enforcement of a very basic rule for decoy selection in light of the research of isthmus / @Mitchellpkt and @neptuneresearch revealing that tens of thousands of transactions have included the same set of outputs as decoys? See the recent MRL meeting log: #632

The rule to be enforced would be something like: No rings allowed where M - 1 ring members are identical to any other ring for a transaction already on the blockchain, where M is the number of ring members. As of now M = 11 and in the next hard fork M will likely be 16.

Monero started to enforce a particular ring size for a very good privacy reason. Allowing wallets or services to construct transactions that break the above rule is a backdoor way to allowing ring size = 1, thereby allowing the true spend to be easily identified.

@ArticMine has suggested that any decoy selection enforcement occur at the node level, i.e. monerod would reject any transaction that does not conform to a rule or rules about ring member selection. Among the benefits of enforcement at the node level is that the computational burden would not be borne by people that are just downloading and verifying the blockchain. I suspect that checking for rings that are effectively duplicates across the entire blockchain or even a portion of the blockchain may be somewhat computationally burdensome.

If enforcement was done in this way, a miner could still include a rulebreaking transaction in a block, but rulebreaking transactions would generally not be transmitted to the miners in the first place since monerod would not re-broadcast them throughout the network.

See also this MRL issue: monero-project/research-lab#87

[sethforprivacy]

A dev meeting discussed the topics of this issue in-depth:

#633

Rough consensus seemed to be gained for:

• Ring size 16
• Mar 15th 2022 hard-fork, Feb 15th release, Jan 15th tag

[moneroexamples]

@sethforprivacy

Will testnet and stagenet have hf before that? If yes, are the dates known?

[selsta]

Stagenet: 1-2 weeks before
Testnet: 1.5 months before

At least that's what I think would make sense.

[sethforprivacy]

Thanks for mentioning that, @moneroexamples, I had forgotten that portion of things.

Agreed with @selsta, those are key milestones to hit and prove the transition before the main net forks.

[SChernykh]

A dev meeting discussed the topics of this issue in-depth:

#633

Rough consensus seemed to be gained for:

• Ring size 16
• Mar 15th 2022 hard-fork, Feb 15th release, Jan 15th tag

Jan 15th is tomorrow. Some important PRs like monero-project/monero#8061 are still not merged.

[sethforprivacy]

Update from the last dev meeting (thanks @carrington1859):

• There was consensus for the ringsize increase from 11 to 16. This brings better privacy to Monero transactions, and the bulkier transactions are mostly offset by Bulletproofs+.
• Bulletproofs+ (a more efficient version of Bulletproofs which help hide transaction amounts) are fully audited and considered good to go.
• View Tags, which will massively speed up blockchain scanning going forward, are ready pending some final tweaks and reviews.
• Changes to the way fees & dynamic blocksize work require more discussion. There are concerns about how fast blocks might be able to grow. You can read a good summary of the concerns here. A dedicated Monero Research Lab meeting is planned to discuss these issues.
• Fixes and improvements to multisig are awaiting a few final reviews.
• Other changes, such as improvements to networking connections, are making good progress but will probably be added in a minor release after the major update.

[moneroexamples]

@sethforprivacy

Thanks for the update. Where can read more about View Tags with possible examples of how to use them?

[selsta]

@moneroexamples monero-project/monero#8061 and monero-project/research-lab#73

[carrington1859]

@sethforprivacy could you add the ringsize PR to the main post?

monero-project/monero#8178

[moneroexamples]

When stagenet and/or testnet will for to v15?

[erciccione]

@moneroexamples It's necessary to set up a dev meeting to decide that, i would say.

[sethforprivacy]

@sethforprivacy could you add the ringsize PR to the main post?

monero-project/monero#8178

Added, thanks!

[moneroexamples]

@erciccione Thanks. Hopefully it will be well in advance of the HF on the mainnet.

[gs522084]

Please add the ability to create warehouse wallets. Thanks, I can withdraw my transaction at any time within the specified time. The warehouse wallet is only for my internal transfer, the time is 24 hours or 48 hours, and the transfer can also be cancelled at any time within 72 hours.The absolute security of the warehouse (1 million coins) must be guaranteed, and the revocation function is necessary

[selsta]

Please add monero-project/monero#8076 and monero-project/monero#8046 to the potential features and remove the binning one.

Also link to monero-project/monero#8237 instead of the multisig refactor one.

[sethforprivacy]

Please add monero-project/monero#8076 and monero-project/monero#8046 to the potential features and remove the binning one.

Also link to monero-project/monero#8237 instead of the multisig refactor one.

Done, thanks for the updates.

On another note, should I keep this open alongside the checklist, or migrate some of that info into that issue and close this one?

[selsta]

I'd keep this one open.