From 5c195d66f6febf68f15a3e1b876cffe17800568d Mon Sep 17 00:00:00 2001 From: el00ruobuob Date: Mon, 9 Sep 2019 10:06:00 +0200 Subject: [PATCH] Dev meeting logs from 2019-09-08 --- ...-for-the-dev-meeting-held-on-2019-09-08.md | 152 ++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 _posts/2019-09-08-logs-for-the-dev-meeting-held-on-2019-09-08.md diff --git a/_posts/2019-09-08-logs-for-the-dev-meeting-held-on-2019-09-08.md b/_posts/2019-09-08-logs-for-the-dev-meeting-held-on-2019-09-08.md new file mode 100644 index 00000000..635e94af --- /dev/null +++ b/_posts/2019-09-08-logs-for-the-dev-meeting-held-on-2019-09-08.md @@ -0,0 +1,152 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2019-09-08 +summary: Development status, Code & ticket discussion, 0.15 release discussion, and miscellaneous +tags: [dev diaries, core, crypto] +author: el00ruobuob / moneromooo / rehrar +--- + +# Logs + +**\** Looks like meeting will start in a few minutes. Stay tuned. +**\** time? +**\** who's already here? +**\** Well, it can start now. Who wants to say anything ? +**\** present +**\** hola +**\** Hi +**\** I've been working on a "sync pruned blocks" patch, it's proving annoying to test but it's almost ready. +**\** Asking around until get the full block? +**\** I'm reworking the randomx integration patch, it has gotten ugly with the added tweaks over the past few months +**\** I do not understand that question. +**\** and currently the daemon mining support is broken +**\** I mean what means "sync pruned blocks" +**\** You asked for pruned blocks when you can, rather than full blocks that you'd then prune. +**\** hyc: Could you define ugly? +**\** Ah, ok. Thans +**\** Thanks +**\** dEBRUYNE: two different code paths for main blocks vs altchain blocks +**\** hello, apologies for tardiness +**\** ought to be able to consolidate it back into 1 +**\** but need to step back and rethink the overall structure +**\** (it's to save network bandwidth btw, it doesn't save more db size) +**\** How does reworking of RandomX PR look in regard to the calendar? +**\** well, it always takes 2-3 days to test and verify that the network is behaving +**\** fwiw hyc, current state of pr seems to be working now +**\** It's September, do we have a hard fork date? +**\** jtgrassie: we haven't crossed a nother epoch boundary yet, I don't think +**\** ^ good point +**\** No fork date yet. +**\** We were thinking Octoberish though, no? +**\** We were. +**\** I would assume mid-October +**\** we ought to be nailing that date down +**\** so in theory there is a hypothetical freeze coming mid September? :D +**\** Though the randomx code being still changed makes me nervous about mid october. +**\** hyc: for testing, you could shorten the epoch to 128 blocks, then you can test it in 2 hours +**\** fluffypony luigi1111 ArticMine smooth binaryFate ? +**\** tevador: we did that when the PR was originally written. for some reason the current problems never showed up then. +**\** hyc, tevador: The recent change were made after audit recommendations or? +**\** successfully mined millions of blocks with epoch=128 +**\** Recent changes to RandomX +**\** that was with a private testnet perhaps? +**\** dEBRUYNE: changes to RandomX itself are independent of the randomx integration patch +**\** tevador: true +**\** dEBRUYNE: most changes were made based on audit recommendations +**\** I see. I guess if we need more time we can always push it back to end of October, but most people and services are expecting a fork in October +**\** dEBRUYNE: are they though? +**\** Nobody expects a monero fork. +**\** we could always release with daemon mining disabled, and fix it up in a point release if we need to +**\** since xmrig is already available +**\** I realize we don't have to go Verge vaporware extreme where we push back indefinitely, but I think people are used to some "delays" if it means code that works from the get go (hopefully) +**\** especially if it's just a couple of weeks +**\** but I'm pretty sure I can get a new patch ready in the next couple days +**\** hyc: I think you could change the testnet epoch to 128 blocks even for public testing +**\** No mining in daemon would make me nervous, I have to admit +**\** tevador: yeah I guess we can try that. +**\** hello all +**\** dsc\_ or selsta here also? +**\** speeding up test verification to 2 hours would certainly help +**\** i may be in and out +**\** yes +**\** Would also be a minor PR defeat, so to say, after telling everyboding about restoring everybody's capacity to mine +**\** my cat just died +**\** :( +**\** ^ joke +**\** o +**\** I think launching with daemon mining is pretty crucial. Shows we are prepared and not reliant on just one software for it, no? +**\** hyc: Oh, then we should still have plenty of time +**\** There's like 6 weeks left until mid october +**\** ok then should be no problem +**\** rbrunner: Yes I tend to agree. I'd prefer to release v0.15.0.0 with full functionality +**\** selsta: what's the state of the GUI as we march toward this fork? +**\** yeah, we should make sure daemon mining is working, especially since there is not much difference in hashrate between xmrig and monerod +**\** With respect to branching, I guess we just keep merging stuff into master until the RandomX pull request is ready? +**\** There's certainly more stuff to be merged atm. +**\** Pragmatic approach :) +**\** xiphon added simple mode public node discovery without a centralized service, I did some redesigned the balance card, dsc is working on i2p +**\** makes sense +**\** we shouldn't release a pow change and it being reliant on some third party miner +**\** also small things +**\** moneromooo: hyc i just got it +**\** lol +**\** it seems like this is shaping up to be a standard Moenro fork :P +**\** we'll have our standard debriefing afterward with our similar standard complaints +**\** anything else currently being worked on? +**\** how long was the code freeze last time? +**\** oh well. the integration PR was pushed in May. if more people had been testing it since then we could've found this earlier +**\** Last time was quite rushed because of the "ASIC emergency" +**\** as it is, we found the problems on testnet, so that at least served its purpose +**\** Are the Wownero people running smoothly then? If yes, why? +**\** they aren't using daemon mining +**\** Oh +**\** amuses me how the problem exists in loki and wow +**\** does anyone take Wownero seriously as a testing bed? Serious question. +**\** This problem is likely will not be detected unless someone mined 3 long altchains with epoch boundary in the middle privately and exposed them to hyc\`s testnet +**\** \*would not be +**\** yes, mining issue only happens when there are long altchains across epoch boundary +**\** I had another initial attempt when did that +**\** "long" means that one block on each side would not be enough to trigger ? +**\** not necessarily long, I guess they need to have different seed hashes +**\** RandomX was released for wow will only daemon mining, tthere were no 3rd party miners at first +**\** must be at least 64 blocks I think +**\** so 64 blocks is enough if split block is chosen carefully +**\** I suppose enough but noone tried to expose them before daemon miner even started to mine epoch boundary block +**\** OK. I'll see if I can add tests for this. +**\** There was a race +**\** That sounds like an awfully special situation +**\** yes +**\** yes, but one which any attacker can construct +**\** And noone claims that he tested all possible special situations +**\** other than that, it works +**\** But it's better test all of them +**\** Mining ahead 64 mainnet blocks? Good luck for that attacker :) +**\** But I understand of course. +**\** rbrunner, you're wrong +**\** technically, you don't need 64 valid blocks to do it +**\** mine 2 blocks before mainnet and expose them immediately +**\** just 64 blocks to trigged node to verify them +**\** and boom +**\** it's broken +**\** anyway we don't need to occupy the rest of the meeting with this +**\** discussion in -pow +**\** kinda fascinating though +**\** are there any questions about specific issues or PRs? +**\** Remember when PoW algorithms were easy and simple ... +**\** no core team seems to be here though :/ +**\** rbrunner: I suppose we'd have similar problems with any PoW scheme that references previous blocks +**\** this problem exist due to complex dependencies in monerod and lack of people to know all of them to write correct code but not local small changes +**\** \*that know all of them +**\** tewinget: if you're still working on loki: ^ +**\** is vtnerd here? +**\** I think he said in one of the previous meetings that his networking stuff will probably not be ready in time, correct? +**\** \ so in theory there is a hypothetical freeze coming mid September? :D \<= I guess branching is technically a freeze right? Because typically only fixes go into the branch +**\** though it doesn't need a hard fork for his stuff so it doesn't matter +**\** rehrar: Yeah I think he said the dandellion++ stuff would not be ready in time +**\** vtnerd\_\_: can you take a look please https://paste.debian.net/hidden/bccdc3a2/ +**\** His white noise PR has been merged though +**\** That's a MacOS depends build with Clang 3.7.1 +**\** was there anything else that needed discussing? +**\** alright, so it looks like we can call it here for the meeting +**\** discussion can obviously continue afterwards on various topics +**\** I'll try to ping core team peeps to be present for next meeting since we're drawing very close to a fork