-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Monero v15 hard-fork planning #630
Comments
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. |
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. |
30d before hardfork is when we want to release binaries, ideally 60 days before a freeze. |
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? |
Does not require a HF. |
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. |
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:
|
February would be a ideal date, good luck guys. |
That's nice. Are all these changes already merged in monero's master branch? Also are these changes already on testnet? |
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. |
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). |
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. |
A meeting has been proposed for 17:00UTC on November 28th by monerobull in Matrix -- any objections, or would that work? |
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 |
A dev meeting discussed the topics of this issue in-depth: Rough consensus seemed to be gained for:
|
Will testnet and stagenet have hf before that? If yes, are the dates known? |
Stagenet: 1-2 weeks before At least that's what I think would make sense. |
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. |
Jan 15th is tomorrow. Some important PRs like monero-project/monero#8061 are still not merged. |
Update from the last dev meeting (thanks @carrington1859):
|
Thanks for the update. Where can read more about |
@sethforprivacy could you add the ringsize PR to the main post? |
When stagenet and/or testnet will for to v15? |
@moneroexamples It's necessary to set up a dev meeting to decide that, i would say. |
Added, thanks! |
@erciccione Thanks. Hopefully it will be well in advance of the HF on the mainnet. |
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 |
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? |
I'd keep this one open. |
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
v0.18.0
v15
Primary features included
Potential features
Suggested time-frame
Suggested Dates
Release checklist
#690
The text was updated successfully, but these errors were encountered: